Soup (libsoup)

[dejlek]

I am working on the Soup v3 binding.

Found a tiny bug in gidgen that caused gidgen not to generate valid D code. The PR is here: Kymorphia/gidgen#4 . There are few other issues. I will try to solve those too, and may make some additional PRs in gidgen eventually...

[dejlek]

Wow, that was quick. :)

I have another issue though:

packages/soup3/soup/global.d:234:39: error: function pointer ‘c_soup_form_encode_datalist(GData** formDataSet)’ is not callable using argument types ‘(GData*)’
  234 |   _cretval = soup_form_encode_datalist(formDataSet);

The problematic generated code:

string formEncodeDatalist(Data formDataSet)
{
  char* _cretval;
  _cretval = soup_form_encode_datalist(formDataSet);
  string _retval = _cretval.fromCString(Yes.Free);
  return _retval;
}

Do we have a case somewhere where we deal with pointer of pointers?

[elementgreen]

I remember running into GData** before and think I just avoided resolving it at the time, since it didn't really affect any API of particular interest. It is a keyed data list using GQuark as the key. It is used with functions such as g_datalist_foreach. The thing about it is that it has a gpointer as the value, which isn't introspectable. So there is no way to automatically know that in the case of this function it is a string. Perhaps they are always quark/string value pairs? If it is then that wouldn't be too difficult to handle. If it differs, we could do a custom extension to GIR to specify the value type, similar to GHashTable.

My tendency is to treat it as a container like GHashTable and convert to/from D associative arrays. For now, if there aren't a lot of these instances we could just write custom binding functions for them, rather than relying on gidgen to automatically bind such rare functions.

[dejlek]

I totally agree. I would gladly ignore this function, but I do not know how. The //!set function[form_encode_datalist][ignore] 1 suggestion does not work. gidgen fails with the same error.

[elementgreen]

I noticed an extra "." in your PR, once I removed that it seemed like it worked (did not see the generated binding for it in the package files). Master didn't have my latest gidgen changes, so you'll want to make sure to update that as well.

[dejlek]

It all works now. Here is a demo from my gid-examples project ( https://codeberg.org/dejan/gid-examples/src/branch/main/soup/source/app.d ):

import std.stdio;

import soup.session;          // Session
import soup.message_headers;  // MessageHeaders
import soup.message;          // Message
import soup.types;            // Bytes

import gio.file;              // File (Gio.File)
import gio.types;             // FileCreateFlags

import glib.bytes;            // Bytes


enum FILE_CREATE_NONE = 0;
enum SOUP_METHOD_GET = "GET";


void main(string[] args) {
    Session session = new Session();
    MessageHeaders mhs = null;
    string contentType;
    Message msg = new Message(SOUP_METHOD_GET, "https://editor.dlang.io/static/img/tour/dman.png");
    Bytes contentBytes = session.sendAndRead(msg, null);

    if (contentBytes is null) {
        writeln("Could not download the DMan PNG file! :(");
    } else {
        auto rhs = msg.getResponseHeaders(); // Returns MessageHeaders
        string[string] params;
        contentType = rhs.getContentType(params);
        writeln("Content-Type: ", contentType, ", Size: ", contentBytes.getSize);
    }

    // Let's use GIO File to save contentBytes
    auto file = gio.file.File.newForPath("dman.png");
    file.replaceContentsBytesAsync(contentBytes, null, false, FileCreateFlags.None, null, null);
}

, and after dub build:

dejan@mini:~/work/dejan/gid-examples/soup «git: main»
» ls
dub.json  gid-soup3-example  source
dejan@mini:~/work/dejan/gid-examples/soup «git: main»
» ./gid-soup3-example 
Content-Type: image/png, Size: 13979
dejan@mini:~/work/dejan/gid-examples/soup «git: main»
» ls -la dman.png 
-rw-r--r--. 1 dejan dejan 0 Mar  1 19:55 dman.png

Obviously it did not save those bytes to the file for some reason, but that is me not knowing anything about GIO... :)

[elementgreen]

Since you are using the async version, it is probably exiting before it completes. Probably the easiest would be to just use the synchronous version File.replace(). The alternative would mean waiting until the async callback is called.

[dejlek]

Yep, it was too late yesterday to figure it all out. As I mentioned I know nothing about GIO. :)

I replaced the code with

    OutputStream os = file.replace(null, false, FileCreateFlags.None, null);
    ulong bytesWritten;
    // Why the heck there is no writeAll(Bytes) ??
    os.writeAll(contentBytes.getData, bytesWritten, null);
    writeln("Bytes written:" , bytesWritten);
    os.close(null);

and it all works as expected. Now I can get d-man.png any time I want. :D

Btw. generated documentation is misleading:

cancellable: optional cancellable object

Yet, the generated code is: bool close(Cancellable cancellable)
This is good candidate for gidgen improvement. There are lots of places where Cacellable parameters should default to null, and that would prevent us from having to pass all those nulls and code would look cleaner. I think it is worth an "issue" in the gidgen project, so I will file one soon after I finish writing this comment.

[elementgreen]

I've thought about that before with respect to optional arguments. However, I think one limitation would be that it could only be optional if all the arguments after it were also optional, right? Not sure what the prevalence is of that scenario though.

I know there are other issues with the generated docs, which might be difficult to resolve automatically. Such as documentation about how to free data, which isn't usually applicable with the D API. Other bindings suffer from this as well. Maybe the best way to handle that would be to have patching commands for generated docs, similar to with the XML. I was deferring some of that effort, since at the moment I haven't found a satisfactory solution for generated DDocs. I really like the look of the GTK-Doc API reference. It would be nice to have something similar to that.

[dejlek]

We can do what Mike did with GtkD - ask Adam Ruppe to build gid docs on dpldocs.info. :)

I really like the look of the GTK-Doc API reference.

Me too - we can do that post v1 release as well...

[elementgreen]

That could work for now, with respect to using dpldocs.info, if Adam Ruppe is amiable to the idea.