qf/quakeforge
0
0
Fork 0
mirror of https://git.code.sf.net/p/quake/quakeforge synced 2024-11-11 07:42:18 +00:00
Code Issues Projects Releases Packages Wiki Activity
quakeforge/tools/qwaq/qwaq-curses.c

612 lines
15 KiB
C
Raw Normal View History

Start working on a qwaq console tool The intention is it will hopefully become a debugger. It will certainly help with development of the progs engine.
2020-02-26 13:10:59 +00:00
/*
#FILENAME#
#DESCRIPTION#
Copyright (C) 2001 #AUTHOR#
Author: #AUTHOR#
Date: #DATE#
This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License
as published by the Free Software Foundation; either version 2
of the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
See the GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to:
Free Software Foundation, Inc.
59 Temple Place - Suite 330
Boston, MA 02111-1307, USA
*/
#ifdef HAVE_CONFIG_H
# include "config.h"
#endif
Create a basic hello world And it has begun. It has some problems, but worse, it seems I broke qfprogs and maybe pr_debug.c.
2020-02-26 16:18:38 +00:00
#include <curses.h>
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
#include <panel.h>
Create a basic hello world And it has begun. It has some problems, but worse, it seems I broke qfprogs and maybe pr_debug.c.
2020-02-26 16:18:38 +00:00
#include <stdlib.h>
#include <string.h>
[qwaq] Read mouse movements Many thanks to https://gist.github.com/sylt/93d3f7b77e7f3a881603 for the necessary escape sequence to get xterm reporting mouse movement events.
2020-02-27 12:22:10 +00:00
#include <unistd.h>
Create a basic hello world And it has begun. It has some problems, but worse, it seems I broke qfprogs and maybe pr_debug.c.
2020-02-26 16:18:38 +00:00
#include "QF/dstring.h"
Start working on a qwaq console tool The intention is it will hopefully become a debugger. It will certainly help with development of the progs engine.
2020-02-26 13:10:59 +00:00
#include "QF/progs.h"
#include "QF/sys.h"
#include "qwaq.h"
[qwaq] Implement an event queue It seems to have an issue with a bogus clearing of the screen, but the basics seem to be working.
2020-02-27 12:01:09 +00:00
#include "event.h"
Start working on a qwaq console tool The intention is it will hopefully become a debugger. It will certainly help with development of the progs engine.
2020-02-26 13:10:59 +00:00
Create a basic hello world And it has begun. It has some problems, but worse, it seems I broke qfprogs and maybe pr_debug.c.
2020-02-26 16:18:38 +00:00
#define always_inline inline __attribute__((__always_inline__))
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
#define QUEUE_SIZE 16
[qwaq] Read mouse movements Many thanks to https://gist.github.com/sylt/93d3f7b77e7f3a881603 for the necessary escape sequence to get xterm reporting mouse movement events.
2020-02-27 12:22:10 +00:00
#define MOUSE_MOVES "\033[?1003h" // Make the terminal report mouse movements
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
#define STRING_ID_QUEUE_SIZE 8 // must be > 1
#define COMMAND_QUEUE_SIZE 128
#define CMD_SIZE(x) sizeof(x)/sizeof(x[0])
typedef enum qwaq_commands_e {
[qwaq] Rename the internal function names Now they reflect the curses functions they wrap. The externally visible builtin names are not changed because the parameters are in x, y order rather than curses' y, x order.
2020-02-29 03:46:25 +00:00
qwaq_cmd_newwin,
qwaq_cmd_delwin,
qwaq_cmd_new_panel,
qwaq_cmd_del_panel,
qwaq_cmd_mvwaddstr,
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
} qwaq_commands;
Create a basic hello world And it has begun. It has some problems, but worse, it seems I broke qfprogs and maybe pr_debug.c.
2020-02-26 16:18:38 +00:00
[qwaq] Create some ring-buffer macros I expect I will need several messaging buffers, and ring buffers tend to be quite robust. Replacing the event buffer code with the macros made testing easy.
2020-02-28 13:27:29 +00:00
#define RING_BUFFER(type, size) \
struct { \
type buffer[size]; \
unsigned head; \
unsigned tail; \
}
#define RB_buffer_size(ring_buffer) \
({ __auto_type rb = (ring_buffer); \
sizeof (rb->buffer) / sizeof (rb->buffer[0]); \
})
#define RB_SPACE_AVAILABLE(ring_buffer) \
({ __auto_type rb = &(ring_buffer); \
(rb->tail + RB_buffer_size(rb) - rb->head - 1) % RB_buffer_size(rb);\
})
#define RB_DATA_AVAILABLE(ring_buffer) \
({ __auto_type rb = &(ring_buffer); \
(rb->head + RB_buffer_size (rb) - rb->tail) % RB_buffer_size (rb); \
})
#define RB_WRITE_DATA(ring_buffer, data, count) \
({ __auto_type rb = &(ring_buffer); \
typeof (&rb->buffer[0]) d = (data); \
unsigned c = (count); \
unsigned h = rb->head; \
rb->head = (h + c) % RB_buffer_size (rb); \
if (c > RB_buffer_size (rb) - h) { \
memcpy (rb->buffer + h, d, \
(RB_buffer_size (rb) - h) * sizeof (rb->buffer[0])); \
c -= RB_buffer_size (rb) - h; \
d += RB_buffer_size (rb) - h; \
h = 0; \
} \
memcpy (rb->buffer + h, d, c * sizeof (rb->buffer[0])); \
})
#define RB_READ_DATA(ring_buffer, data, count) \
({ __auto_type rb = &(ring_buffer); \
typeof (&rb->buffer[0]) d = (data); \
unsigned c = (count); \
unsigned oc = c; \
unsigned t = rb->tail; \
if (c > RB_buffer_size (rb) - t) { \
memcpy (d, rb->buffer + t, \
(RB_buffer_size (rb) - t) * sizeof (rb->buffer[0])); \
c -= RB_buffer_size (rb) - t; \
d += RB_buffer_size (rb) - t; \
t = 0; \
} \
memcpy (d, rb->buffer + t, c * sizeof (rb->buffer[0])); \
rb->tail = (t + oc) % RB_buffer_size (rb); \
})
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
#define RB_DROP_DATA(ring_buffer, count) \
({ __auto_type rb = &(ring_buffer); \
unsigned c = (count); \
unsigned t = rb->tail; \
rb->tail = (t + c) % RB_buffer_size (rb); \
})
#define RB_PEEK_DATA(ring_buffer, ahead) \
({ __auto_type rb = &(ring_buffer); \
rb->buffer[(rb->tail + ahead) % RB_buffer_size (rb)]; \
})
Create a basic hello world And it has begun. It has some problems, but worse, it seems I broke qfprogs and maybe pr_debug.c.
2020-02-26 16:18:38 +00:00
typedef struct window_s {
WINDOW *win;
} window_t;
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
typedef struct panel_s {
PANEL *panel;
} panel_t;
Create a basic hello world And it has begun. It has some problems, but worse, it seems I broke qfprogs and maybe pr_debug.c.
2020-02-26 16:18:38 +00:00
typedef struct qwaq_resources_s {
progs_t *pr;
int initialized;
PR_RESMAP (window_t) window_map;
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
PR_RESMAP (panel_t) panel_map;
[qwaq] Create some ring-buffer macros I expect I will need several messaging buffers, and ring buffers tend to be quite robust. Replacing the event buffer code with the macros made testing easy.
2020-02-28 13:27:29 +00:00
RING_BUFFER (qwaq_event_t, QUEUE_SIZE) event_queue;
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
RING_BUFFER (int, COMMAND_QUEUE_SIZE) command_queue;
RING_BUFFER (int, COMMAND_QUEUE_SIZE) results;
RING_BUFFER (int, STRING_ID_QUEUE_SIZE) string_ids;
dstring_t strings[STRING_ID_QUEUE_SIZE - 1];
Create a basic hello world And it has begun. It has some problems, but worse, it seems I broke qfprogs and maybe pr_debug.c.
2020-02-26 16:18:38 +00:00
} qwaq_resources_t;
static window_t *
window_new (qwaq_resources_t *res)
{
PR_RESNEW (window_t, res->window_map);
}
static void
window_free (qwaq_resources_t *res, window_t *win)
{
PR_RESFREE (window_t, res->window_map, win);
}
Start working on a qwaq console tool The intention is it will hopefully become a debugger. It will certainly help with development of the progs engine.
2020-02-26 13:10:59 +00:00
Create a basic hello world And it has begun. It has some problems, but worse, it seems I broke qfprogs and maybe pr_debug.c.
2020-02-26 16:18:38 +00:00
static void
window_reset (qwaq_resources_t *res)
{
PR_RESRESET (window_t, res->window_map);
}
static inline window_t *
window_get (qwaq_resources_t *res, unsigned index)
{
PR_RESGET(res->window_map, index);
}
static inline int
window_index (qwaq_resources_t *res, window_t *win)
{
PR_RESINDEX (res->window_map, win);
}
[qwaq] Create some ring-buffer macros I expect I will need several messaging buffers, and ring buffers tend to be quite robust. Replacing the event buffer code with the macros made testing easy.
2020-02-28 13:27:29 +00:00
static always_inline window_t * __attribute__((pure))
Create a basic hello world And it has begun. It has some problems, but worse, it seems I broke qfprogs and maybe pr_debug.c.
2020-02-26 16:18:38 +00:00
get_window (qwaq_resources_t *res, const char *name, int handle)
{
window_t *window = window_get (res, handle);
if (!window || !window->win) {
PR_RunError (res->pr, "invalid window passed to %s", name + 3);
}
return window;
}
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
static panel_t *
panel_new (qwaq_resources_t *res)
{
PR_RESNEW (panel_t, res->panel_map);
}
Start working on a qwaq console tool The intention is it will hopefully become a debugger. It will certainly help with development of the progs engine.
2020-02-26 13:10:59 +00:00
static void
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
panel_free (qwaq_resources_t *res, panel_t *win)
Start working on a qwaq console tool The intention is it will hopefully become a debugger. It will certainly help with development of the progs engine.
2020-02-26 13:10:59 +00:00
{
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
PR_RESFREE (panel_t, res->panel_map, win);
Start working on a qwaq console tool The intention is it will hopefully become a debugger. It will certainly help with development of the progs engine.
2020-02-26 13:10:59 +00:00
}
Create a basic hello world And it has begun. It has some problems, but worse, it seems I broke qfprogs and maybe pr_debug.c.
2020-02-26 16:18:38 +00:00
static void
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
panel_reset (qwaq_resources_t *res)
Create a basic hello world And it has begun. It has some problems, but worse, it seems I broke qfprogs and maybe pr_debug.c.
2020-02-26 16:18:38 +00:00
{
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
PR_RESRESET (panel_t, res->panel_map);
}
Create a basic hello world And it has begun. It has some problems, but worse, it seems I broke qfprogs and maybe pr_debug.c.
2020-02-26 16:18:38 +00:00
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
static inline panel_t *
panel_get (qwaq_resources_t *res, unsigned index)
{
PR_RESGET(res->panel_map, index);
Create a basic hello world And it has begun. It has some problems, but worse, it seems I broke qfprogs and maybe pr_debug.c.
2020-02-26 16:18:38 +00:00
}
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
static inline int
panel_index (qwaq_resources_t *res, panel_t *win)
Create a basic hello world And it has begun. It has some problems, but worse, it seems I broke qfprogs and maybe pr_debug.c.
2020-02-26 16:18:38 +00:00
{
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
PR_RESINDEX (res->panel_map, win);
}
static always_inline panel_t * __attribute__((pure))
get_panel (qwaq_resources_t *res, const char *name, int handle)
{
panel_t *panel = panel_get (res, handle);
if (!panel || !panel->panel) {
PR_RunError (res->pr, "invalid panel passed to %s", name + 3);
}
return panel;
}
static int
acquire_string (qwaq_resources_t *res)
{
int string_id = -1;
// XXX add locking and loop for available
if (RB_DATA_AVAILABLE (res->string_ids)) {
RB_READ_DATA (res->string_ids, &string_id, 1);
}
// XXX unlock and end of loop
return string_id;
Create a basic hello world And it has begun. It has some problems, but worse, it seems I broke qfprogs and maybe pr_debug.c.
2020-02-26 16:18:38 +00:00
}
static void
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
release_string (qwaq_resources_t *res, int string_id)
Create a basic hello world And it has begun. It has some problems, but worse, it seems I broke qfprogs and maybe pr_debug.c.
2020-02-26 16:18:38 +00:00
{
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
// locking shouldn't be necessary as there should be only one writer
// but if it becomes such that there is more than one writer, locks as per
// acquire
if (RB_SPACE_AVAILABLE (res->string_ids)) {
RB_WRITE_DATA (res->string_ids, &string_id, 1);
}
Create a basic hello world And it has begun. It has some problems, but worse, it seems I broke qfprogs and maybe pr_debug.c.
2020-02-26 16:18:38 +00:00
}
static void
[qwaq] Rename the internal function names Now they reflect the curses functions they wrap. The externally visible builtin names are not changed because the parameters are in x, y order rather than curses' y, x order.
2020-02-29 03:46:25 +00:00
cmd_newwin (qwaq_resources_t *res)
Create a basic hello world And it has begun. It has some problems, but worse, it seems I broke qfprogs and maybe pr_debug.c.
2020-02-26 16:18:38 +00:00
{
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
int xpos = RB_PEEK_DATA (res->command_queue, 2);
int ypos = RB_PEEK_DATA (res->command_queue, 3);
int xlen = RB_PEEK_DATA (res->command_queue, 4);
int ylen = RB_PEEK_DATA (res->command_queue, 5);
Create a basic hello world And it has begun. It has some problems, but worse, it seems I broke qfprogs and maybe pr_debug.c.
2020-02-26 16:18:38 +00:00
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
window_t *window = window_new (res);
window->win = newwin (ylen, xlen, ypos, xpos);
keypad (window->win, TRUE);
int window_id = window_index (res, window);
[qwaq] Rename the internal function names Now they reflect the curses functions they wrap. The externally visible builtin names are not changed because the parameters are in x, y order rather than curses' y, x order.
2020-02-29 03:46:25 +00:00
int cmd_result[] = { qwaq_cmd_newwin, window_id };
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
// loop
if (RB_SPACE_AVAILABLE (res->results) >= CMD_SIZE (cmd_result)) {
RB_WRITE_DATA (res->results, cmd_result, CMD_SIZE (cmd_result));
}
Create a basic hello world And it has begun. It has some problems, but worse, it seems I broke qfprogs and maybe pr_debug.c.
2020-02-26 16:18:38 +00:00
}
[qwaq] Convert remaining functions to command queue Now that the initial prototype seems to be working well, it's time to implement more commands. I might have to do some wrappers for actual command writing (and result reading) as it looks like there will be a lot of nearly identical code.
2020-02-29 02:44:43 +00:00
static void
[qwaq] Rename the internal function names Now they reflect the curses functions they wrap. The externally visible builtin names are not changed because the parameters are in x, y order rather than curses' y, x order.
2020-02-29 03:46:25 +00:00
cmd_delwin (qwaq_resources_t *res)
[qwaq] Convert remaining functions to command queue Now that the initial prototype seems to be working well, it's time to implement more commands. I might have to do some wrappers for actual command writing (and result reading) as it looks like there will be a lot of nearly identical code.
2020-02-29 02:44:43 +00:00
{
int window_id = RB_PEEK_DATA (res->command_queue, 2);
window_t *window = get_window (res, __FUNCTION__, window_id);
delwin (window->win);
window_free (res, window);
}
static void
[qwaq] Rename the internal function names Now they reflect the curses functions they wrap. The externally visible builtin names are not changed because the parameters are in x, y order rather than curses' y, x order.
2020-02-29 03:46:25 +00:00
cmd_new_panel (qwaq_resources_t *res)
[qwaq] Convert remaining functions to command queue Now that the initial prototype seems to be working well, it's time to implement more commands. I might have to do some wrappers for actual command writing (and result reading) as it looks like there will be a lot of nearly identical code.
2020-02-29 02:44:43 +00:00
{
int window_id = RB_PEEK_DATA (res->command_queue, 2);
window_t *window = get_window (res, __FUNCTION__, window_id);
panel_t *panel = panel_new (res);
panel->panel = new_panel (window->win);
int panel_id = panel_index (res, panel);
[qwaq] Rename the internal function names Now they reflect the curses functions they wrap. The externally visible builtin names are not changed because the parameters are in x, y order rather than curses' y, x order.
2020-02-29 03:46:25 +00:00
int cmd_result[] = { qwaq_cmd_new_panel, panel_id };
[qwaq] Convert remaining functions to command queue Now that the initial prototype seems to be working well, it's time to implement more commands. I might have to do some wrappers for actual command writing (and result reading) as it looks like there will be a lot of nearly identical code.
2020-02-29 02:44:43 +00:00
// loop
if (RB_SPACE_AVAILABLE (res->results) >= CMD_SIZE (cmd_result)) {
RB_WRITE_DATA (res->results, cmd_result, CMD_SIZE (cmd_result));
}
}
static void
[qwaq] Rename the internal function names Now they reflect the curses functions they wrap. The externally visible builtin names are not changed because the parameters are in x, y order rather than curses' y, x order.
2020-02-29 03:46:25 +00:00
cmd_del_panel (qwaq_resources_t *res)
[qwaq] Convert remaining functions to command queue Now that the initial prototype seems to be working well, it's time to implement more commands. I might have to do some wrappers for actual command writing (and result reading) as it looks like there will be a lot of nearly identical code.
2020-02-29 02:44:43 +00:00
{
int panel_id = RB_PEEK_DATA (res->command_queue, 2);
panel_t *panel = get_panel (res, __FUNCTION__, panel_id);
del_panel (panel->panel);
panel_free (res, panel);
}
[qwaq] Read mouse movements Many thanks to https://gist.github.com/sylt/93d3f7b77e7f3a881603 for the necessary escape sequence to get xterm reporting mouse movement events.
2020-02-27 12:22:10 +00:00
static void
[qwaq] Rename the internal function names Now they reflect the curses functions they wrap. The externally visible builtin names are not changed because the parameters are in x, y order rather than curses' y, x order.
2020-02-29 03:46:25 +00:00
cmd_mvwaddstr (qwaq_resources_t *res)
[qwaq] Read mouse movements Many thanks to https://gist.github.com/sylt/93d3f7b77e7f3a881603 for the necessary escape sequence to get xterm reporting mouse movement events.
2020-02-27 12:22:10 +00:00
{
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
int window_id = RB_PEEK_DATA (res->command_queue, 2);
int x = RB_PEEK_DATA (res->command_queue, 3);
int y = RB_PEEK_DATA (res->command_queue, 4);
int string_id = RB_PEEK_DATA (res->command_queue, 5);
window_t *window = get_window (res, __FUNCTION__, window_id);
mvwaddstr (window->win, y, x, res->strings[string_id].str);
release_string (res, string_id);
[qwaq] Read mouse movements Many thanks to https://gist.github.com/sylt/93d3f7b77e7f3a881603 for the necessary escape sequence to get xterm reporting mouse movement events.
2020-02-27 12:22:10 +00:00
wrefresh (window->win);
}
Create a basic hello world And it has begun. It has some problems, but worse, it seems I broke qfprogs and maybe pr_debug.c.
2020-02-26 16:18:38 +00:00
static void
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
process_commands (qwaq_resources_t *res)
Create a basic hello world And it has begun. It has some problems, but worse, it seems I broke qfprogs and maybe pr_debug.c.
2020-02-26 16:18:38 +00:00
{
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
while (RB_DATA_AVAILABLE (res->command_queue) > 2) {
switch ((qwaq_commands) RB_PEEK_DATA (res->command_queue, 0)) {
[qwaq] Rename the internal function names Now they reflect the curses functions they wrap. The externally visible builtin names are not changed because the parameters are in x, y order rather than curses' y, x order.
2020-02-29 03:46:25 +00:00
case qwaq_cmd_newwin:
cmd_newwin (res);
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
break;
[qwaq] Rename the internal function names Now they reflect the curses functions they wrap. The externally visible builtin names are not changed because the parameters are in x, y order rather than curses' y, x order.
2020-02-29 03:46:25 +00:00
case qwaq_cmd_delwin:
cmd_delwin (res);
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
break;
[qwaq] Rename the internal function names Now they reflect the curses functions they wrap. The externally visible builtin names are not changed because the parameters are in x, y order rather than curses' y, x order.
2020-02-29 03:46:25 +00:00
case qwaq_cmd_new_panel:
cmd_new_panel (res);
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
break;
[qwaq] Rename the internal function names Now they reflect the curses functions they wrap. The externally visible builtin names are not changed because the parameters are in x, y order rather than curses' y, x order.
2020-02-29 03:46:25 +00:00
case qwaq_cmd_del_panel:
cmd_del_panel (res);
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
break;
[qwaq] Rename the internal function names Now they reflect the curses functions they wrap. The externally visible builtin names are not changed because the parameters are in x, y order rather than curses' y, x order.
2020-02-29 03:46:25 +00:00
case qwaq_cmd_mvwaddstr:
cmd_mvwaddstr (res);
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
break;
}
RB_DROP_DATA (res->command_queue, RB_PEEK_DATA (res->command_queue, 1));
}
Create a basic hello world And it has begun. It has some problems, but worse, it seems I broke qfprogs and maybe pr_debug.c.
2020-02-26 16:18:38 +00:00
}
[qwaq] Implement an event queue It seems to have an issue with a bogus clearing of the screen, but the basics seem to be working.
2020-02-27 12:01:09 +00:00
static void
add_event (qwaq_resources_t *res, qwaq_event_t *event)
{
[qwaq] Create some ring-buffer macros I expect I will need several messaging buffers, and ring buffers tend to be quite robust. Replacing the event buffer code with the macros made testing easy.
2020-02-28 13:27:29 +00:00
if (RB_SPACE_AVAILABLE (res->event_queue) >= 1) {
RB_WRITE_DATA (res->event_queue, event, 1);
[qwaq] Implement an event queue It seems to have an issue with a bogus clearing of the screen, but the basics seem to be working.
2020-02-27 12:01:09 +00:00
}
}
static int
get_event (qwaq_resources_t *res, qwaq_event_t *event)
{
[qwaq] Create some ring-buffer macros I expect I will need several messaging buffers, and ring buffers tend to be quite robust. Replacing the event buffer code with the macros made testing easy.
2020-02-28 13:27:29 +00:00
if (RB_DATA_AVAILABLE (res->event_queue) >= 1) {
[qwaq] Implement an event queue It seems to have an issue with a bogus clearing of the screen, but the basics seem to be working.
2020-02-27 12:01:09 +00:00
if (event) {
[qwaq] Create some ring-buffer macros I expect I will need several messaging buffers, and ring buffers tend to be quite robust. Replacing the event buffer code with the macros made testing easy.
2020-02-28 13:27:29 +00:00
RB_READ_DATA (res->event_queue, event, 1);
[qwaq] Implement an event queue It seems to have an issue with a bogus clearing of the screen, but the basics seem to be working.
2020-02-27 12:01:09 +00:00
}
return 1;
}
return 0;
}
static void
mouse_event (qwaq_resources_t *res, MEVENT *mevent)
{
qwaq_event_t event = {};
event.event_type = qe_mouse;
event.e.mouse.x = mevent->x;
event.e.mouse.y = mevent->y;
event.e.mouse.buttons = mevent->bstate;
add_event (res, &event);
}
static void
key_event (qwaq_resources_t *res, int key)
{
qwaq_event_t event = {};
event.event_type = qe_key;
event.e.key = key;
add_event (res, &event);
}
static void
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
process_input (qwaq_resources_t *res)
[qwaq] Implement an event queue It seems to have an issue with a bogus clearing of the screen, but the basics seem to be working.
2020-02-27 12:01:09 +00:00
{
if (Sys_CheckInput (1, -1)) {
int ch;
while ((ch = getch ()) != ERR && ch) {
fflush (stderr);
if (ch == KEY_MOUSE) {
MEVENT mevent;
getmouse (&mevent);
mouse_event (res, &mevent);
} else {
key_event (res, ch);
}
}
}
}
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
static int need_endwin;
static void
bi_shutdown (void)
{
if (need_endwin) {
endwin ();
}
}
static void
[qwaq] Rename the internal function names Now they reflect the curses functions they wrap. The externally visible builtin names are not changed because the parameters are in x, y order rather than curses' y, x order.
2020-02-29 03:46:25 +00:00
bi_newwin (progs_t *pr)
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
{
qwaq_resources_t *res = PR_Resources_Find (pr, "qwaq");
int xpos = P_INT (pr, 0);
int ypos = P_INT (pr, 1);
int xlen = P_INT (pr, 2);
int ylen = P_INT (pr, 3);
int command[] = {
[qwaq] Rename the internal function names Now they reflect the curses functions they wrap. The externally visible builtin names are not changed because the parameters are in x, y order rather than curses' y, x order.
2020-02-29 03:46:25 +00:00
qwaq_cmd_newwin, 0,
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
xpos, ypos, xlen, ylen,
};
command[1] = CMD_SIZE(command);
if (RB_SPACE_AVAILABLE (res->command_queue) >= CMD_SIZE(command)) {
RB_WRITE_DATA (res->command_queue, command, CMD_SIZE(command));
}
// XXX should just wait on the mutex
process_commands (res);
process_input (res);
// locking and loop until id is correct
if (RB_DATA_AVAILABLE (res->results)
[qwaq] Rename the internal function names Now they reflect the curses functions they wrap. The externally visible builtin names are not changed because the parameters are in x, y order rather than curses' y, x order.
2020-02-29 03:46:25 +00:00
&& RB_PEEK_DATA (res->results, 0) == qwaq_cmd_newwin) {
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
int cmd_result[2]; // should results have a size?
RB_READ_DATA (res->results, cmd_result, CMD_SIZE (cmd_result));
R_INT (pr) = cmd_result[1];
}
}
static void
[qwaq] Rename the internal function names Now they reflect the curses functions they wrap. The externally visible builtin names are not changed because the parameters are in x, y order rather than curses' y, x order.
2020-02-29 03:46:25 +00:00
bi_delwin (progs_t *pr)
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
{
qwaq_resources_t *res = PR_Resources_Find (pr, "qwaq");
[qwaq] Convert remaining functions to command queue Now that the initial prototype seems to be working well, it's time to implement more commands. I might have to do some wrappers for actual command writing (and result reading) as it looks like there will be a lot of nearly identical code.
2020-02-29 02:44:43 +00:00
int window_id = P_INT (pr, 0);
if (get_window (res, __FUNCTION__, window_id)) {
[qwaq] Rename the internal function names Now they reflect the curses functions they wrap. The externally visible builtin names are not changed because the parameters are in x, y order rather than curses' y, x order.
2020-02-29 03:46:25 +00:00
int command[] = { qwaq_cmd_delwin, 0, window_id, };
[qwaq] Validate window before acquiring string If the window is invalid and recovery is done, string ids will leak if acquired before validation. Afterwards, make the rest of the builtin wrappers consistent: extract parameters, validate, [acquire resources], generate command.
2020-02-29 03:33:45 +00:00
[qwaq] Convert remaining functions to command queue Now that the initial prototype seems to be working well, it's time to implement more commands. I might have to do some wrappers for actual command writing (and result reading) as it looks like there will be a lot of nearly identical code.
2020-02-29 02:44:43 +00:00
command[1] = CMD_SIZE(command);
if (RB_SPACE_AVAILABLE (res->command_queue) >= CMD_SIZE(command)) {
RB_WRITE_DATA (res->command_queue, command, CMD_SIZE(command));
}
}
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
}
static void
[qwaq] Rename the internal function names Now they reflect the curses functions they wrap. The externally visible builtin names are not changed because the parameters are in x, y order rather than curses' y, x order.
2020-02-29 03:46:25 +00:00
bi_new_panel (progs_t *pr)
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
{
qwaq_resources_t *res = PR_Resources_Find (pr, "qwaq");
[qwaq] Convert remaining functions to command queue Now that the initial prototype seems to be working well, it's time to implement more commands. I might have to do some wrappers for actual command writing (and result reading) as it looks like there will be a lot of nearly identical code.
2020-02-29 02:44:43 +00:00
int window_id = P_INT (pr, 0);
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
[qwaq] Convert remaining functions to command queue Now that the initial prototype seems to be working well, it's time to implement more commands. I might have to do some wrappers for actual command writing (and result reading) as it looks like there will be a lot of nearly identical code.
2020-02-29 02:44:43 +00:00
if (get_window (res, __FUNCTION__, window_id)) {
[qwaq] Rename the internal function names Now they reflect the curses functions they wrap. The externally visible builtin names are not changed because the parameters are in x, y order rather than curses' y, x order.
2020-02-29 03:46:25 +00:00
int command[] = { qwaq_cmd_new_panel, 0, window_id, };
[qwaq] Validate window before acquiring string If the window is invalid and recovery is done, string ids will leak if acquired before validation. Afterwards, make the rest of the builtin wrappers consistent: extract parameters, validate, [acquire resources], generate command.
2020-02-29 03:33:45 +00:00
[qwaq] Convert remaining functions to command queue Now that the initial prototype seems to be working well, it's time to implement more commands. I might have to do some wrappers for actual command writing (and result reading) as it looks like there will be a lot of nearly identical code.
2020-02-29 02:44:43 +00:00
command[1] = CMD_SIZE(command);
if (RB_SPACE_AVAILABLE (res->command_queue) >= CMD_SIZE(command)) {
RB_WRITE_DATA (res->command_queue, command, CMD_SIZE(command));
}
// locking and loop until id is correct
if (RB_DATA_AVAILABLE (res->results)
[qwaq] Rename the internal function names Now they reflect the curses functions they wrap. The externally visible builtin names are not changed because the parameters are in x, y order rather than curses' y, x order.
2020-02-29 03:46:25 +00:00
&& RB_PEEK_DATA (res->results, 0) == qwaq_cmd_new_panel) {
[qwaq] Convert remaining functions to command queue Now that the initial prototype seems to be working well, it's time to implement more commands. I might have to do some wrappers for actual command writing (and result reading) as it looks like there will be a lot of nearly identical code.
2020-02-29 02:44:43 +00:00
int cmd_result[2]; // should results have a size?
RB_READ_DATA (res->results, cmd_result, CMD_SIZE (cmd_result));
R_INT (pr) = cmd_result[1];
}
}
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
}
static void
[qwaq] Rename the internal function names Now they reflect the curses functions they wrap. The externally visible builtin names are not changed because the parameters are in x, y order rather than curses' y, x order.
2020-02-29 03:46:25 +00:00
bi_del_panel (progs_t *pr)
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
{
qwaq_resources_t *res = PR_Resources_Find (pr, "qwaq");
[qwaq] Convert remaining functions to command queue Now that the initial prototype seems to be working well, it's time to implement more commands. I might have to do some wrappers for actual command writing (and result reading) as it looks like there will be a lot of nearly identical code.
2020-02-29 02:44:43 +00:00
int panel_id = P_INT (pr, 0);
[qwaq] Rename the internal function names Now they reflect the curses functions they wrap. The externally visible builtin names are not changed because the parameters are in x, y order rather than curses' y, x order.
2020-02-29 03:46:25 +00:00
int command[] = { qwaq_cmd_del_panel, 0, panel_id, };
[qwaq] Convert remaining functions to command queue Now that the initial prototype seems to be working well, it's time to implement more commands. I might have to do some wrappers for actual command writing (and result reading) as it looks like there will be a lot of nearly identical code.
2020-02-29 02:44:43 +00:00
if (get_panel (res, __FUNCTION__, panel_id)) {
command[1] = CMD_SIZE(command);
if (RB_SPACE_AVAILABLE (res->command_queue) >= CMD_SIZE(command)) {
RB_WRITE_DATA (res->command_queue, command, CMD_SIZE(command));
}
}
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
}
static void
bi_mvwprintf (progs_t *pr)
{
qwaq_resources_t *res = PR_Resources_Find (pr, "qwaq");
int window_id = P_INT (pr, 0);
int x = P_INT (pr, 1);
int y = P_INT (pr, 2);
const char *fmt = P_GSTRING (pr, 3);
int count = pr->pr_argc - 4;
pr_type_t **args = pr->pr_params + 4;
if (get_window (res, __FUNCTION__, window_id)) {
[qwaq] Validate window before acquiring string If the window is invalid and recovery is done, string ids will leak if acquired before validation. Afterwards, make the rest of the builtin wrappers consistent: extract parameters, validate, [acquire resources], generate command.
2020-02-29 03:33:45 +00:00
int string_id = acquire_string (res);
dstring_t *print_buffer = res->strings + string_id;
int command[] = {
[qwaq] Rename the internal function names Now they reflect the curses functions they wrap. The externally visible builtin names are not changed because the parameters are in x, y order rather than curses' y, x order.
2020-02-29 03:46:25 +00:00
qwaq_cmd_mvwaddstr, 0,
[qwaq] Validate window before acquiring string If the window is invalid and recovery is done, string ids will leak if acquired before validation. Afterwards, make the rest of the builtin wrappers consistent: extract parameters, validate, [acquire resources], generate command.
2020-02-29 03:33:45 +00:00
window_id, x, y, string_id
};
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
command[1] = CMD_SIZE(command);
dstring_clearstr (print_buffer);
[qwaq] Rename the internal function names Now they reflect the curses functions they wrap. The externally visible builtin names are not changed because the parameters are in x, y order rather than curses' y, x order.
2020-02-29 03:46:25 +00:00
PR_Sprintf (pr, print_buffer, "mvwaddstr", fmt, count, args);
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
if (RB_SPACE_AVAILABLE (res->command_queue) >= CMD_SIZE(command)) {
RB_WRITE_DATA (res->command_queue, command, CMD_SIZE(command));
}
}
}
[qwaq] Implement an event queue It seems to have an issue with a bogus clearing of the screen, but the basics seem to be working.
2020-02-27 12:01:09 +00:00
static void
bi_get_event (progs_t *pr)
{
qwaq_resources_t *res = PR_Resources_Find (pr, "qwaq");
qwaq_event_t *event = &G_STRUCT (pr, qwaq_event_t, P_INT (pr, 0));
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
process_commands (res);
process_input (res);
[qwaq] Implement an event queue It seems to have an issue with a bogus clearing of the screen, but the basics seem to be working.
2020-02-27 12:01:09 +00:00
R_INT (pr) = get_event (res, event);
}
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
static void
bi_initialize (progs_t *pr)
{
qwaq_resources_t *res = PR_Resources_Find (pr, "qwaq");
initscr ();
need_endwin = 1;
res->initialized = 1;
raw ();
keypad (stdscr, TRUE);
noecho ();
nonl ();
nodelay (stdscr, TRUE);
mousemask(ALL_MOUSE_EVENTS | REPORT_MOUSE_POSITION, NULL);
write(1, MOUSE_MOVES, sizeof (MOUSE_MOVES) - 1);
refresh();
}
Create a basic hello world And it has begun. It has some problems, but worse, it seems I broke qfprogs and maybe pr_debug.c.
2020-02-26 16:18:38 +00:00
static void
bi_qwaq_clear (progs_t *pr, void *data)
{
__auto_type res = (qwaq_resources_t *) data;
if (res->initialized) {
endwin ();
}
need_endwin = 0;
window_reset (res);
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
panel_reset (res);
Create a basic hello world And it has begun. It has some problems, but worse, it seems I broke qfprogs and maybe pr_debug.c.
2020-02-26 16:18:38 +00:00
}
static builtin_t builtins[] = {
{"initialize", bi_initialize, -1},
[qwaq] Rename the internal function names Now they reflect the curses functions they wrap. The externally visible builtin names are not changed because the parameters are in x, y order rather than curses' y, x order.
2020-02-29 03:46:25 +00:00
{"create_window", bi_newwin, -1},
{"destroy_window", bi_delwin, -1},
{"create_panel", bi_new_panel, -1},
{"destroy_panel", bi_del_panel, -1},
[qwaq] Read mouse movements Many thanks to https://gist.github.com/sylt/93d3f7b77e7f3a881603 for the necessary escape sequence to get xterm reporting mouse movement events.
2020-02-27 12:22:10 +00:00
{"mvwprintf", bi_mvwprintf, -1},
[qwaq] Implement an event queue It seems to have an issue with a bogus clearing of the screen, but the basics seem to be working.
2020-02-27 12:01:09 +00:00
{"get_event", bi_get_event, -1},
Create a basic hello world And it has begun. It has some problems, but worse, it seems I broke qfprogs and maybe pr_debug.c.
2020-02-26 16:18:38 +00:00
{0}
};
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
static __attribute__((format(printf, 1, 0))) void
qwaq_print (const char *fmt, va_list args)
{
vfprintf (stderr, fmt, args);
fflush (stderr);
}
Start working on a qwaq console tool The intention is it will hopefully become a debugger. It will certainly help with development of the progs engine.
2020-02-26 13:10:59 +00:00
void
BI_Init (progs_t *pr)
{
Create a basic hello world And it has begun. It has some problems, but worse, it seems I broke qfprogs and maybe pr_debug.c.
2020-02-26 16:18:38 +00:00
qwaq_resources_t *res = calloc (sizeof (*res), 1);
res->pr = pr;
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
for (int i = 0; i < STRING_ID_QUEUE_SIZE - 1; i++) {
RB_WRITE_DATA (res->string_ids, &i, 1);
res->strings[i].mem = &dstring_default_mem;
}
Start working on a qwaq console tool The intention is it will hopefully become a debugger. It will certainly help with development of the progs engine.
2020-02-26 13:10:59 +00:00
Create a basic hello world And it has begun. It has some problems, but worse, it seems I broke qfprogs and maybe pr_debug.c.
2020-02-26 16:18:38 +00:00
PR_Resources_Register (pr, "qwaq", res, bi_qwaq_clear);
PR_RegisterBuiltins (pr, builtins);
Start working on a qwaq console tool The intention is it will hopefully become a debugger. It will certainly help with development of the progs engine.
2020-02-26 13:10:59 +00:00
Sys_RegisterShutdown (bi_shutdown);
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
Sys_SetStdPrintf (qwaq_print);
Start working on a qwaq console tool The intention is it will hopefully become a debugger. It will certainly help with development of the progs engine.
2020-02-26 13:10:59 +00:00
}
Reference in a new issue Copy permalink