gcc -fPIC `apxs2 -q CFLAGS ` -I`apxs2 -q INCLUDEDIR`
-c time_cookie.c -o time_cookie.o
gcc -shared -lapr-1 -laprutil-1 time_cookie.o -o time_cookie.soAnd the FOREACH loop in it should use
curr_bucket = APR_BRIGADE_FIRST(bb);Anyway I wonder if anyone has done a Mysql/Json apache module.
while (curr_bucket != APR_BRIGADE_SENTINEL(bb)) {
...
curr_bucket = APR_BUCKET_NEXT(curr_bucket);
}
./gtkjs test/filetree.dsetc.
var sess = new Soup.SessionSync();
var msg = new Soup.Message("GET", "http://www.akbkhome.com/");
status = sess.sendMessage(msg);
println("Status is " + status);
println("ResponseHeaders is " + msg.responseHeaders.toSource());
var imp = new Dom.Implementation;
var doc = imp.createHtmlDocFromMemory(msg.response);
var a_s = doc.getElementsByTagName("a");
for(var i =0; i < a_s.length; i++) {
println("got href: " + a_s.item(i).getAttribute("href"));
}
var file = "/etc/passwd"
println("Directory = " + Path.getDirName(file));
println("Filename = " + Path.getBaseName(file));
println("combined filename = " + Path.join("etc","passwd"));
sh buildit.sh APILookupGLib.txt APILookupGObject.txt APILookupSoup.txtIt cant do the dependancy resolution yet, so you have to list all the pre-requisite packages so it has access to all the required types when building the library you need.
include "mytest.ds"; // this is run at compile time (not runtime!)Will successfully output
class A {
function A() {
println("This is the constructor A");
}
var c = 12;
function B() {
println("This is B and c is " + this.c);
}
}
class C extends A
{
function C() {
println("This is the constructor C");
A.prototype.constructor.call(this);
}
function D() {
println("This is D and c is " + this.c);
}
}
var a = new A();
a.B();
var c = new C();
c.B();
c.D();
Hello from mytestNow I can start writing tidy little javascript libraries...
This is the constructor A
This is B and c is 12
This is the constructor C
This is the constructor A
This is B and c is 12
This is D and c is 12
println(Request.toSource());Next job is to look at how GET/POST data is passed around and how to escape data on output. among a list of 100 ideas for how it could all work.
println("hellow world from javascript");
To generate the Gtk bindings (and adding other features) for gtkDjs I use a code generator. This is pretty common to all the Gtk bindings. I worked on the PHP-GTK ones a long time ago, which in turn where based loosely off the Python bindings.
For GtkDjs, the starting point was the GtkD binding code. While the current code is still similar to it's parent, It has grown considerably since it's original birth. So In the vain of "if someone ever feels like helping out with the bindings", or wants to write and send me bindings for SQLite, Mysql, curl or libsoup etc. Here's the inside story of them.
The basic concept.
In essence, the bindings work using "generator scripts" called APILookup*.txt, which contain a series of either information, or instructions to do tasks.
Other than the overall configuration settings for the generator, or libraries, the core part of generating bindings is to create classes. In Gtk this is normally done by reading the HTML documentation for a specific Gtk Struct, and using that information to generate data about the Enums, Signals and Methods that are defined. This is all done by GtkClassParser.d
Finally after the File has been parsed, the Output classes "ClassOut, FuncOut, EnumOut, LibraryOut, PhobosOut, SignalOut" generate the code files in the src directory.
Unlike the original GtkD bindings GtkDjs does a double pass at generating each of the packages, as we use the first pass to calculate dependencies and inheritance, rather than relying on the list of imports in the APILookup files. This means that the APILookup*.txt files do not really have to list all the required imports.
More details on the APILookup files.
While I'm not going to explain all the possible commands available in the files, I will explain the concept and a few key ones. The file "GtkWrap.d" contains the parser, with a complete list of keywords and actions, it's a reasonably simple and obvious piece of code. I'm still adding new commands when I see them as necessary, and may even remove a few as some are pretty pointless or unused.. (like code: *** which is ignored but is usefull for reference on how GtkD did things).
The basic concept of the file is a list of data in the formats:
#for simple data
keyword : Value
# for building a list of key value pairs
keyword : key valuepair
#for long data - like code etc.
keyword : subject
......
keyword : end
#for long data - (older style)
keyword : start
......
keyword : end
Order is quite important, as the parser for the APIWrap is not forgiving and can easily go into infinite loops if you get the wrong or unknown keyword in the wrong place. Fortunately using the existing files as a basis for a new one should help out a bit.
The core APILookup.txt files contains a few key pieces of information
The individual Binding for the specific libraries (or packages as the tend to be called) are structured a little differently.
The generator code.
In order of how they are used.
The design differs a little from the original GtkD generator in that I separated the parsing of the documentation and the code generation into separate classes. I felt the original code was pretty huge and unwieldy done that way.
Anyway comment away if you have any further thoughts...
