I need to use the Sqlite vapi without any depedence on GLib. SQlite is non-gobject library, so it should be possible to do that.
However, when I try to compile the following file with the --profile posix
option,
using Sqlite;
void main() {
stdout.printf("Hello, World!");
}
I get am error messages:
sqlite3.vapi:357.56-357.59: error: The symbol `GLib' could not be found
public int bind_blob (int index, void* value, int n,
GLib.DestroyNotify destroy_notify);
^^^^
sqlite3.vapi:362.68-362.71: error: The symbol `GLib' could not be found
public int bind_text (int index, owned string value, int n = -1,
GLib.DestroyNotify destroy_notify = GLib.g_free);
^^^^
sqlite3.vapi:411.42-411.45: error: The symbol `GLib' could not be found
public void result_blob (uint8[] data, GLib.DestroyNotify?
destroy_notify = GLib.g_free);
^^^^
sqlite3.vapi:420.59-420.62: error: The symbol `GLib' could not be found
public void result_text (string value, int length = -1,
GLib.DestroyNotify? destroy_notify = GLib.g_free);
^^^^
Compilation failed: 4 error(s), 0 warning(s)
It seems that several of the functions defined in the sqlite vapi make references to the GLib.g_free and GLib.DestroyNotify symbols. Are there any posix alternatives to those?
That should be fairly simple to solve, and I can imagine several solutions.
It boils down to declaring a different delegate void DestroyNotify (void* data) (either in the posix.vapi or sqlite3.vapi) and bind free() in posix.vapi.
The problem is the namespace, and you might need to file a bug and discuss it with the developers. If you want to avoid this problem and are ready to go with a workaround, just create a mini glib.vapi GLib namespace, where you bind only the DestroyNotify() and g_free() (binding to libc/posix free).
I would think that sqlite3 should not use GLib, but rather libc/posix, so you should be fine by modifying only posix.vapi and sqlite3.vapi and filing a bug with your patch (awesome, a contrib!).
Note that classes are unavailable under the POSIX profile, as Vala requires a support library (i.e. GLib, Dova) to support those features. Jürg Billeter has acknowledged that support for the POSIX profile is experimental and limited:
https://bugzilla.gnome.org/show_bug.cgi?id=618348
The only way you have is re-writing the sqlite VAPI (or just the classes/methods you need) making them posix friendly (but I guess you can't use classes in that way).
if the vapi for sqlite depends on glib you could just write your own or use the sqlite c code with c and just make some extern statements for the functions you need. for example i made a tool wich mixes vala and c for linux pure c for win32 and objective c and c for mac
https://github.com/boscowitch/wadoku-notify
i just added the 2 functions i need at the beginning of my vala app like this:
extern void init_db(char * path,bool mm);
extern void lookup(char * str);
i added the whole sqlite source cause i needed to activate full text indexing and change a bit in the code and in the beginning of vala there was no sqlite vapi
Related
Is it possible to split a communicator using openmpi's OMPI_COMM_TYPE_SOCKET in mpi4py?
I've verified this works:
from mpi4py import MPI
comm = MPI.COMM_WORLD
sharedcomm = comm.Split_type(MPI.COMM_TYPE_SHARED)
but this does not:
socketcomm = comm.Split_type(MPI.OMPI_COMM_TYPE_SOCKET)
nor does this:
socketcomm = comm.Split_type(MPI.COMM_TYPE_SOCKET)
I've looked at the docs but I can't find anything about this.
mpi4py only provides a wrapper around standard MPI features. OMPI_COMM_TYPE_SOCKET is an Open MPI specific split type. You may still use it in mpi4py if you know its numeric value as it is just a member of a C enum:
/*
* Communicator split type constants.
* Do not change the order of these without also modifying mpif.h.in
* (see also mpif-common.h.fin).
*/
enum {
MPI_COMM_TYPE_SHARED,
OMPI_COMM_TYPE_HWTHREAD,
OMPI_COMM_TYPE_CORE,
OMPI_COMM_TYPE_L1CACHE,
OMPI_COMM_TYPE_L2CACHE,
OMPI_COMM_TYPE_L3CACHE,
OMPI_COMM_TYPE_SOCKET, // here
OMPI_COMM_TYPE_NUMA,
OMPI_COMM_TYPE_BOARD,
OMPI_COMM_TYPE_HOST,
OMPI_COMM_TYPE_CU,
OMPI_COMM_TYPE_CLUSTER
};
#define OMPI_COMM_TYPE_NODE MPI_COMM_TYPE_SHARED
Being a member of an enum means that the actual numerical value of OMPI_COMM_TYPE_SOCKET depends on its position in the enum and hence may differ from one release of Open MPI to another. You have several options here.
Hardcode the value
This is the simplest option. Open mpi.h (ompi_info --path incdir gives you its location), count the position of OMPI_COMM_TYPE_SOCKET in the enclosing enum starting with 0 for MPI_COMM_TYPE_SHARED and hardcode the value. The code may break with releases of Open MPI different from yours.
Parse mpi.h
Read mpi.h, search for enum definitions and find the one containing OMPI_COMM_TYPE_SOCKET. Provided that MPI_COMM_TYPE_SHARED is 0, the value of OMPI_COMM_TYPE_SOCKET is its 0-based index in the sequence of enum values. This depends a lot on the code in mpi.h having a specific format and can easily break if that changes.
Parse mpif.h
The Fortran interface is easier to parse as there the value is defined as:
parameter (OMPI_COMM_TYPE_SOCKET=6)
This is easily parsable with a simple regular expression. The problem is that recent versions of Open MPI split mpif.h over a couple of files that are then included from mpif.h and currently the value is in mpif-constants.h. So you may need to parse the include statements and recurse into the files they reference. Note that those are Fortran include statements and not preprocessor #include directives.
Code generation
Write a small C program that outputs the value of OMPI_COMM_TYPE_SOCKET to a Python file and run it as part of your program's setup procedure. Something like:
#include <stdio.h>
#include <mpi.h>
int main (int argc, char **argv)
{
if (argc != 2)
{
printf("Usage: mkompimod /path/to/module.py\n");
return 1;
}
FILE *fh = fopen(argv[1], "w");
if (fh != NULL) {
fprintf(fh, "COMM_TYPE_SOCKET = %d\n", OMPI_COMM_TYPE_SOCKET);
fclose(fh);
}
return 0;
}
Put that in a file named mkompimod.c. Compile with mpicc -o mkompimod mkompimod.c and run with mkompimod /path/to/ompi.py to create a Python file ompi.py with the value of OMPI_COMM_TYPE_SOCKET. Import it and use it in the call to comm.Split_type():
import ompi
socketcomm = comm.Split_type(ompi.COMM_TYPE_SOCKET)
Write a Python module in C
That's a bit involved, but you can write a C module that includes mpi.h and exports the value of OMPI_COMM_TYPE_SOCKET as a Python constant. Consult the Python documentation on how to write extensions in C.
Use the CFFI module
CFFI lets you build Python modules that wrap C libraries and writes all the glue code for you. Put the following in a file named ompi_build.py:
from cffi import FFI
ffi = FFI()
ffi.set_source("ompi", r"#include <mpi.h>")
ffi.cdef(
r"""
const int OMPI_COMM_TYPE_HWTHREAD;
... more constants here ...
const int OMPI_COMM_TYPE_SOCKET;
... even more constants here ...
"""
)
if __name__ == "__main__":
ffi.compile(verbose=True)
Run like this:
$ CC=mpicc python ompi_build.py
This will create the C module ompi.c and compile it into a loadable DSO. You may then import it and access the constant like this:
from ompi.lib import OMPI_COMM_TYPE_SOCKET
socketcomm = comm.Split_type(OMPI_COMM_TYPE_SOCKET)
CFFI provides integration with Python's distutils and you can have it automatically build the C module as part of the setup process.
Use Cython
That's what mpi4py itself is written in. It blends C and Python into a single cryptic syntax. Read the source code. Try to figure out what's going on and how to write something yourself. Can't help you there.
Whichever path you choose, keep in mind that all this pertains to the system on which the program will be running, not only the system on which the program will be developed.
Could anyone please tell me is this the right model for non-deterministic values of integer and unsigned integer in Frama-C?
/* Suppose Frama-C is installed in /usr/local -default prefix */
#include "/usr/local/share/frama-c/builtin.h"
#include "/usr/local/share/frama-c/libc/limits.h"
...
#define nondet_int() Frama_C_interval(INT_MIN, INT_MAX)
#define nondet_uint() Frama_C_interval(0, UINT_MAX)
...
Are there any exceptions if I use the above code with different architectures in option -machdep?
No, in the Neon version you have to manually define the appropriate macro if you want to use another -machdep. You would typically end up with a command-line like that:
frama-c -cpp-extra-args="-D__FC_MACHDEP_X86_64" -machdep x86_64
Forthcoming Sodium release will make the -cpp-extra-args unnecessary, as well as providing by default a -I option to let preprocessor search into Frama-C's libc header, so that you won't have to provide it yourself or rely on absolute paths in your #include directive
NB: This answer is not a commitment to any particular date for the Sodium release.
One reason Frama_C_interval(0, UINT_MAX) may not work as intended is that Frama_C_interval has type int (int, int). When you happen to want the entire range of unsigned int values, that actually tends to help because the conversions that are introduced are subject to approximation, but in general the fact that Frama_C_interval is declared as returning an int is a nuisance.
The latest released version already has Frama_C_unsigned_int_interval, but it is in share/libc/__fc_builtin.h (installed to /usr/local/share/frama-c/libc/__fc_builtin.h. The file builtin.h looks like a vestigial remnant, especially with the $Id$ line dating back to when development was done under SVN.
For specifying that a value should be all possible unsigned intvalues, Frama_C_unsigned_int_interval(0, -1) saves yourself the trouble of including limit.h. The int value -1 passed as argument is converted to the largest unsigned int as per C rules.
What do I need to include to use DateTime? More specifically:
int month = System.DateTime.Now.Month;
Because I just put it there, and it doesn't recognize it.
Coding in C, with codeblocks
This is the error I am getting:
||=== Build: Debug in fm (compiler: GNU GCC Compiler) ===|
E:\CS50X\Projetos\FM\fm.c|224|error: 'System' undeclared (first use in this function)|
I just want to make a getage algorithm, but for that II need to get the current month and year.
Here is DateTime page:
http://msdn.microsoft.com/pt-br/library/system.datetime.aspx
The object you mention (System.DateTime.Now.Month) and the documentation to which you link (http://msdn.microsoft.com/pt-br/library/system.datetime.aspx) is all in the .NET Framework, used by languages such as C# and Visual Basic.
However, you're trying to compile C code:
|=== Build: Debug in fm (compiler: GNU GCC Compiler) ===|
Short answer... You can't use C# objects in C code. They're completely different languages on completely different platforms. If you're programming in C, you need to write your code in C. Different programming languages don't mix together like that.
drop system and use this
int month = DateTime.Now.Month;
in other words，Is there a command that can find the symbol at an address meanwhile use ptype show this symbol‘s detail info ？
or if there is not， how can i write a user-define command meet this needs ？
for example， now i can firstly get data struct‘s name (ngx_errlog_module_ctx) in a address use “info symbol” command， than use ptype show the data struct’s detail info like this：
(gdb) info symbol 0x80b4568
ngx_errlog_module_ctx in section .data of /usr/local/nginx/sbin/nginx
(gdb) ptype ngx_errlog_module_ctx
type = struct {
ngx_str_t name;
void *(*create_conf)(ngx_cycle_t *);
char *(*init_conf)(ngx_cycle_t *, void *);
}
but now， how can i write a user-difined command (ptype_with_address) that i can use like this :
ptype_with_address 0x80b4568
ngx_errlog_module_ctx in section .data of /usr/local/nginx/sbin/nginx
type = struct {
ngx_str_t name;
void *(*create_conf)(ngx_cycle_t *);
char *(*init_conf)(ngx_cycle_t *, void *);
}
i want to do this because i am research nginx’s code，i want write a user-defined command to show all ngx_modules's detail info, include each module's ctx member variable.
can i write a user-define command meet this need
If you have a reasonably recent version of GDB, you should be able to use built-in Python interpreter to achieve your goal.
Unfortunately, it doesn't look like you can get the gdb.Symbol from its address, you need the symbol name. In other words, it doesn't look like info symbol is currently exposed to Python interpreter in GDB.
I suggest filing a feature request in bugzilla to extend gdb.lookup_global_symbol to also accept an address.
Googling for "gdb python info symbol" revealed this thread, in which Tom Tromey (gdb developer) also asked to file a bugzilla issue, and suggested a workaround.
I'm using mingw32-make to compile a qt project that uses opengl, it compiles correctly and everything, but it spits countless warning messages of the form:
c:/qt3/include/qcolor.h:67: warning: inline function `int qGray(int, int,
int)' declared as dllimport: attribute ignored
For this particular instance, the function declaration is:
Q_EXPORT inline int qGray( int r, int g, int b )// convert R,G,B to gray 0..255
{ return (r*11+g*16+b*5)/32; }
My question is, why is it spitting all these warning? how can I silence them without silencing other legitimate warnings (i.e. warnings that are related directly to my code and could be potential problems)?
More importantly, why is mingw ignoring the dll import attribute in the first place?
I think Qt ought to only define Q_EXPORT (Q_DECL_EXPORT in Qt 4) to be the dllexport/import attribute if one of the following macros is defined, so make sure your makefiles or code that includes Qt headers (which eventually will include qglobal.h) aren't defining any of them: WIN32, _WIN32, __WIN32__, WIN64, _WIN64, __WIN64__. Or you can just define Q_EXPORT to be nothing in your compile (or preprocessor) flags, then Qt should skip defining it.