As per this, I think it is not possible to create GArray using python bindings. To overcome this, I am writing a small library that will return a GArray. This library utilizes gobject introspection and exposes a method create_codec_array.
/**
* webrtc_interface_create_codec_array:
* #interface: a #WebrtcInterface
*
* creates codecs_array.
*
* Returns: (element-type GstStructure) (transfer full): a #GArray of #GstStructure
*/
GArray *
webrtc_interface_create_codec_array (WebrtcInterface * interface)
{
WebrtcInterfacePrivate *priv ;
g_return_if_fail (interface != NULL);
priv = WEBRTC_INTERFACE_GET_PRIVATE (interface);
gchar * codecs[] = {priv->codec, NULL};
GArray *a = g_array_new (FALSE, TRUE, sizeof (GValue));
int i;
for (i=0; i < g_strv_length (codecs); i++) {
GValue v = G_VALUE_INIT;
GstStructure *s;
g_value_init (&v, GST_TYPE_STRUCTURE);
s = gst_structure_new (codecs[i], NULL, NULL);
gst_value_set_structure (&v, s);
gst_structure_free (s);
g_array_append_val (a, v);
}
return a;
}
When I run g-ir-scanner, I get the following error:
webrtc_interface.c:149: Warning: Webrtc: webrtc_interface_create_codec_array:
Unknown type: 'GstStructure'
This function is returning a GArray of GstStructure elements, which I am not able to introspect. What should be the element-type annotation in this case?
Many thanks!
GstStructure is an introspectable type — it’s defined in Gst-1.0.gir. Are you passing --include Gst-1.0 to g-ir-scanner when you run it to build your GIR?
If you’re using the GIR autotools integration (highly recommended if you’re using autotools), you can do this by adding Gst-1.0 to the *_INCLUDES variable for your GIR module.
Related
I want to mount a filesystem on Linux using Lua, but I haven't found any capability in the lua 5.4 manual or the LuaFileSytem library. Is there some way to mount a filesystem in Lua or with an existing library?
Like most platform-dependent syscall, Lua won't provide such mapping out of the box.
So you'll need some C-API module that does the trick.
Looks like https://github.com/justincormack/ljsyscall is generic "but" focused on LuaJIT and https://luaposix.github.io/luaposix/ doesn't provide mount.
I recently had similar needs, and I ended doing the C module:
static int l_mount(lua_State* L)
{
int res = 0;
// TODO add more checks on args!
const char *source = luaL_checkstring(L, 1);
const char *target = luaL_checkstring(L, 2);
const char *type = luaL_checkstring(L, 3);
lua_Integer flags = luaL_checkinteger(L, 4);
const char *data = luaL_checkstring(L, 5);
res = mount(source, target, type, flags, data);
if ( res != 0)
{
int err = errno;
lua_pushnil(L);
lua_pushfstring(L, "mount failed: errno[%s]", strerror(err));
return 2;
}
else
{
lua_pushfstring(L, "ok");
return 1;
}
}
#define register_constant(s)\
lua_pushinteger(L, s);\
lua_setfield(L, -2, #s);
// Module functions
static const luaL_Reg R[] =
{
{ "mount", l_mount },
{ NULL, NULL }
};
int luaopen_sysutils(lua_State* L)
{
luaL_newlib(L, R);
// do more mount defines mapping, maybe in some table.
register_constant(MS_RDONLY);
//...
return 1;
}
Compile this as a C Lua module, and don't forget that you need CAP_SYS_ADMIN to call mount syscall.
The documentation says:
void g_ptr_array_insert (GPtrArray *array,
gint index_,
gpointer data);
Inserts an element into the pointer array at the given index. The
array will grow in size automatically if necessary.
Same question for g_ptr_array_add().
Documentation is silent about thread safety of these functions. The following functions are described expressly to be thread-safe:
g_ptr_array_free ()
g_ptr_array_ref()
g_ptr_array_unref ()
What if multiple-threads execute g_ptr_array_insert() at the same time on the same array of pointers? Do I have to provide thread safety myself?
No, it's not thread-safe (just as almost all GLib data types; source, see “you must coordinate accesses…”). Chances are that
two threads enter marked line simultaneously.
static void
g_ptr_array_maybe_expand (GRealPtrArray *array,
gint len)
{
if ((array->len + len) > array->alloc)
{
guint old_alloc = array->alloc;
array->alloc = g_nearest_pow (array->len + len);
array->alloc = MAX (array->alloc, MIN_ARRAY_SIZE);
array->pdata = g_realloc (array->pdata, sizeof (gpointer) * array->alloc); // here
if (G_UNLIKELY (g_mem_gc_friendly))
for ( ; old_alloc < array->alloc; old_alloc++)
array->pdata [old_alloc] = NULL;
}
}
void
g_ptr_array_add (GPtrArray *array,
gpointer data)
{
GRealPtrArray *rarray = (GRealPtrArray *)array;
g_return_if_fail (rarray);
g_ptr_array_maybe_expand (rarray, 1);
rarray->pdata[rarray->len++] = data;
}
Provide your own locking using, for example, GMutex.
I just want to use GNOME glib functions to simply write and read a file. I think my syntaxes are wrong in calling the functions. I tried to open a file with g_fopen("filenam.txt", "w"); but it didnt create any file. I also used g_file_set_contents and I am trying to save my Gstring s into a file file.txt with code as
static void events_handler(const uint8_t *pdu, uint16_t len, gpointer user_data)
{
uint8_t *opdu;
uint16_t handle, i, olen;
size_t plen;
//GString *s;
const gchar *s;
gssize length;
length = 100;
handle = get_le16(&pdu[1]);
switch (pdu[0]) {
case ATT_OP_HANDLE_NOTIFY:
s = g_string_new(NULL);
//g_string_printf(s, "Movement data = 0x%04x value: ",handle);
g_file_set_contents("file.txt", s, 100, NULL);
break;
case ATT_OP_HANDLE_IND:
s = g_string_new(NULL);
g_string_printf(s, "Indication handle = 0x%04x value: ",handle);
break;
default:
error("Invalid opcode\n");
return;
}
for (i = 3; i < len; i++)
g_string_append_printf(s, "%02x ", pdu[i]);
rl_printf("%s\n", s->str);
g_string_free(s, TRUE);
if (pdu[0] == ATT_OP_HANDLE_NOTIFY)
return;
opdu = g_attrib_get_buffer(attrib, &plen);
olen = enc_confirmation(opdu, plen);
if (olen > 0)
g_attrib_send(attrib, 0, opdu, olen, NULL, NULL, NULL);
}
You're conflating GString* and gchar*. The g_string_*() functions expect a GString*, and g_file_set_contents() expects gchar*. If you want the raw data, use the str field.
Also, I suggest turning on some more warnings on your compiler, since it really should be complaining during development if you try to do this. Passing -Wall should do the trick…
I am writing a plugins subsystem and one of the ideas is to iterate through a dylib (or at least current global scope) exported functions. I know there are other ways, just really want to give this one a try.
What I am wondering, is there a way to get a list of functions exported by a dylib or available in global scope through OS X and iOS API?
Thanks in advance!
You can use a command 'nm' for getting an information from a dynamic library.
See additionally system manual for this command on Mac.
If you are looking to do that from code, you could use this method.
std::vector<std::string> load_mach_o(std::string file_name)
{
/*
Parse the Mach-O structure to find all the exported symbols
Mach-O structure:
mach_header_64
cmd
...
cmd
data
...
data
*/
std::vector<std::string> methods;
off_t offset = sizeof(struct mach_header_64);
BYTE * bytes = load_bytes(file_name.c_str());
if (bytes == NULL)
{
return methods;
}
struct mach_header_64 *header = (struct mach_header_64 *)bytes;
//Get the load commands
struct load_command *cmd = (struct load_command *)(bytes + offset);
for (uint32_t i = 0U; i < header->ncmds; i++)
{
if (cmd->cmd == LC_SYMTAB)
{
struct symtab_command * symtab = (struct symtab_command *)cmd;
off_t string_start = 0;
const char* strings = (const char *)(bytes + symtab->stroff + 1);
for (uint32_t i = 0 ; i < symtab->strsize ; i++)
{
if (strings[i] == '\0')
{
i++;
size_t size = sizeof(char) * (i - string_start);
if (size == 1)
{
string_start = i+1;
continue;
}
methods.push_back(std::string((const char *)(strings + string_start)));
string_start = i+1;
}
}
}
offset += cmd->cmdsize;
//load next command
cmd = (struct load_command *)(bytes + offset);
}
free(bytes);
return methods;
}
This function read the file and parses the structure till mach-O strings section, then, parses each string and store it in a vector containing all the exposed functions.
Best regards.
I've seen it said multiple times that there is no way to limit a Lua script's memory usage, including people jumping through hoops to prevent Lua scripts from creating functions and tables. But given that lua_newstate allows you to pass a custom allocator, couldn't one just use that to limit memory consumption? At worst, one could use an arena-based allocator and put a hard limit even on the amount of memory that could be used by fragmentation.
Am I missing something here?
static void *l_alloc_restricted (void *ud, void *ptr, size_t osize, size_t nsize)
{
const int MAX_SIZE = 1024; /* set limit here */
int *used = (int *)ud;
if(ptr == NULL) {
/*
* <http://www.lua.org/manual/5.2/manual.html#lua_Alloc>:
* When ptr is NULL, osize encodes the kind of object that Lua is
* allocating.
*
* Since we don’t care about that, just mark it as 0.
*/
osize = 0;
}
if (nsize == 0)
{
free(ptr);
*used -= osize; /* substract old size from used memory */
return NULL;
}
else
{
if (*used + (nsize - osize) > MAX_SIZE) /* too much memory in use */
return NULL;
ptr = realloc(ptr, nsize);
if (ptr) /* reallocation successful? */
*used += (nsize - osize);
return ptr;
}
}
To make Lua use your allocator, you can use
int *ud = malloc(sizeof(int)); *ud = 0;
lua_State *L = lua_State *lua_newstate (l_alloc_restricted, ud);
Note: I haven't tested the source, but it should work.