Re: Is there an alternative of `go get`
On Friday, 7 August 2020 at 07:17:25 UTC, Ky-Anh Huynh wrote: Hi everyone, `go get` in Golang world has a simple way to fetch and install binary ``` $ go get github/foo/bar.git $ export PATH=$PATH:$(go env GOPATH)/bin $ bar --help ``` This saves a lot of time and setup. Is that an alternative when using dub? Thanks a lot. Hello, you can use `dub build $name` to build the package. The resulting binary should be in $HOME/.dub/$name-$version/$name/bin then. You can also run the binary via `dub run $name -- $additional_args`, then you won't have to add that path to your PATH. If you haven't run `dub build $name` previously, `dub run $name` will do that for you.
Re: Does std.net.curl: download have support for callbacks?
On Thursday, 11 June 2020 at 06:13:59 UTC, adnan338 wrote: On Thursday, 11 June 2020 at 06:05:09 UTC, adnan338 wrote: I would like to set a callback for the `download()` function but I do not seem to find a way to add a callback to the procedure. [...] I have also been told that Gtk is not thread safe. What does this mean and does it effect me on this scenario? That means that you must not access GTK objects from anything but your mainthread, so e.g. spawning a new thread to listen for progress on the curl request and updating the thread directly from there wont work. You could use glib.Idle or glib.Timeout to listen for updates in your mainthread without blocking it. In case you need to do something heavier (e.g. decode a big response) you probably want to do that in a separate thread to not block your mainthread (and as such make your UI unresponsive while the decoding blocks the thread). In that case I'd recommend using message passing, meaning that you spawn a separate thread, do your decoding there and then send the result back to your mainthread and manipulate the GTK widget there.
Re: D, Unit_Threaded, and GtkD
On Saturday, 16 May 2020 at 10:51:07 UTC, Russel Winder wrote: Has anyone got any D code using the Glib event loop, usually GtkD code I'd guess, that is well tested using Unit_Threaded? I always had a hard time doing unittests for things with as many moving parts as glib based software, so I usually just do integration tests like so: https://gitlab.alpinelinux.org/Cogitri/apk-polkit/-/blob/1dfbe2b3d959e3c083fcb82419a0a0401c485937/tests/apkd_dbus_server/addAndDelete.d Maybe I should look into Unit_Threaded for more fine grained tests, but I think the effort for all the mocking stuff that I'd have to implement even for a (relatively) simple GDBus application would be quite substantial.
Re: DScanner warns class is undocumented, how to resolve it ?
On Thursday, 14 May 2020 at 06:08:17 UTC, Vinod K Chandran wrote: On Thursday, 14 May 2020 at 06:05:00 UTC, Vinod K Chandran wrote: Hi all, I wrote a class and in VS Code, DScanner says that the class is undocumented. How can i document a class ? Never mind, i found the answer myself. Just like in dot net, i added triple forward slash comment and problem solved. Also see https://dlang.org/spec/ddoc.html for more info on DDoc. FWIW you can also disable the warning by adding the following to VSCode's settings.json: "dscanner.ignoredKeys": [ "dscanner.style.undocumented_declaration" ] to your settings.json. I do that since I usually find the warning distracting while implementing new methods, where I only document things once I'm happy with the implementation and all the warnings about missing docs usually distract me from more important warnings during that phase.
Re: GtkD crash: 'BadAlloc (insufficient resources for operation)'
On Monday, 27 April 2020 at 14:53:06 UTC, mark wrote: Below is the bt. Does it look like my bug or a Gtk or GtkD bug? That's hard to say without the debug info for gtkd, gtk and glib installed (so the backtrace isn't all the useful), but since gtkd isn't mentioned in the log I guess that it's something in the interaction of gdk and X11. I guess it'd be best to ask the GTK folks about this.
Re: GtkD crash: 'BadAlloc (insufficient resources for operation)'
Hello, could you try what the error message suggest you to do: On Monday, 27 April 2020 at 12:03:18 UTC, mark wrote: (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the GDK_SYNCHRONIZE environment variable to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) Program exited with code -5 With that you should be able to run your program in gdb and get a backtrace. However, BadAlloc sounds to me as if your program is running out of RAM and as such can't allocate more memory.
