Iup and nukclear interface in D.
http://code.dlang.org/packages/iupd http://code.dlang.org/packages/nukleard iupd removes all deprecated items in IUP, current version is IUP 3.18. nukleard may have some bugs in name mangling. Does a struct's field name like `null`, i changed it to null_, may be issue? Can pragma(mangle, "name") help in this context?
Re: D-Man culture
On Monday, 20 June 2016 at 14:14:06 UTC, Martin Tschierschke wrote: On Sunday, 19 June 2016 at 15:01:33 UTC, Seb wrote: Hi, I am not sure how much you have heard about the D-Man, but in Japan there is an entire culture based on the D-Man! As I learned about this by accident (and even Walter didn't know about it), I thought I share this great movement with the DLang community! [...] Funny stuff! I found this link useful: http://dlangcomicstrips.tumblr.com/ These are awesome, recommend the read.
Re: QtE5 - is a wrapping of Qt-5 for D
This is very nice! I would love to know how you managed to get it working. I had trouble with signals and slots, the class hierarchy, and numerous other things when I was trying to get Qt4 to work in D. How did you handle the Qt class constructors and destructors, etc.? Well, there are too many questions.The majority of answers you can find in qte5widgets(h,cpp)files.The main thing is the set of readymade slots that are based in prepared class "eAction"(C++). This class has the address of the D function by way of property and when the slot is called it will just call the D function. I suggest to continue the discussion at Github.
Re: Release DUB 1.0.0
Am 21.06.2016 um 00:37 schrieb Basile B.: You should add a system to support example files, without dependency. For example in a static library, something that would indicate that the package in which the file resides is itself a dependency but don't have to be downloaded: package examples ex1.d ex2.d source package src1.d ex1.d /+ dub.sdl: name "package" dependency "this" (or dependency "../..") +/ from ex1 you should be able to locate the package by using .dirName until a dub.json is found. Maybe that if the dep value is a relative path that leads to a description this works too. This currently works using dependency "package" path="../../" I'd like to avoid making this smarter, because currently (sub) packages are all logically distinct, which helps a lot to keep the internal logic simple in various places. An exception to this rule is that versions of sub packages are locked to the version of the parent package, which causes quite some complications in the dependency resolution algorithm, which in turn has often been a source of bugs.
Re: Release DUB 1.0.0
Am 22.06.2016 um 11:51 schrieb gleb: Sönke Ludwig wrote: I'm pleased to announce the release of the first stable version of the DUB package manager. Stable in this case means that Hello! That's great! But... Is "DFLAGS="-defaultlib=libphobos2.so" dub build" still the only way to build dynamically linked binaries? What about standard options to build/link against ".so's"? Thank You! Do you mean building a shared library, or linking against the shared version of Phobos? The former case should automatically add -defaultlib, if targetType is set to "dynamicLibrary" in the package recipe. In the latter case, it has to be specified dynamically. Using DFLAGS is a possibility, or putting it in the "dflags" field of the recipe.
Re: Release DUB 1.0.0
Sönke Ludwig wrote: > I'm pleased to announce the release of the first stable version of the > DUB package manager. Stable in this case means that Hello! That's great! But... Is "DFLAGS="-defaultlib=libphobos2.so" dub build" still the only way to build dynamically linked binaries? What about standard options to build/link against ".so's"? Thank You!
Re: dlang-requests 0.1.7 released
On Wednesday, 22 June 2016 at 02:04:25 UTC, Zekereth wrote:
On Saturday, 11 June 2016 at 23:03:52 UTC, ikod wrote:
Hello,
Dlang-requests is library created under influence of
Python-requests, with primary goal of easy to use and
performance.
I have a couple of questions. If a url can't be found and I
catch the ConnectError exception and handle it[2] I still get
an additional error[1] printed. For example:
try
{
getContent(url);
}
catch(ConnectError ex)
{
debug writeln("Error getting page: ", ex.msg);
}
Will error with this:
[1]2016-06-21T20:59:15.073:streams.d:connect:750 Failed to
connect: can't resolve www.systemcontrolpanel.com - getaddrinfo
error: Name or service not known
[2]Error getting page: Can't connect to
www.systemcontrolpanel.com:80: getaddrinfo error: Name or
service not known
The additional error[1] will still print in release build. The
only workaround I could find was to check getAddress myself and
ensure that the page exists before calling getContent.
Thanks!
Hello,
It makes no sense to log error message and throw exception in
next line, so I'll remove this error messages from the code.
Thanks for report(but better place it on the github project page
so that I can link code changes with bug reports)!
Re: QtE5 - is a wrapping of Qt-5 for D
On Monday, 20 June 2016 at 16:52:04 UTC, MGW wrote: This my library has about 400 functions from Qt and is quite efficient for small applications. https://github.com/MGWL/QtE5 Small video about QtE5 and id5 written on its basis - an example of use. QtE5 on Mac OSX https://www.youtube.com/watch?v=JBA4vkT5uKE This is very nice! I would love to know how you managed to get it working. I had trouble with signals and slots, the class hierarchy, and numerous other things when I was trying to get Qt4 to work in D. How did you handle the Qt class constructors and destructors, etc.?
