Re: Is HibernateD dead?
On Thursday, 3 May 2018 at 20:49:35 UTC, Matthias Klumpp wrote: On Thursday, 3 May 2018 at 18:52:34 UTC, singingbush wrote: On Thursday, 3 May 2018 at 10:27:47 UTC, Pasqui23 wrote: Last commit on https://github.com/buggins/hibernated was almost a year ago So what is the status of HibernateD?Should I use it if I need an ORM? Or would I risk unpatched security risks? Both hibernated and ddbc have had open pull requests for months. It's really frustrating. Oh hey :-) I applied your patches for ddbc and hibernated a to my copy while back, because they weren't merged and fix real issues. There are also other patches floating around, for example people will really want https://github.com/KrzaQ/hibernated/commit/efa38c50effdd77e973b174feea89016b8d1fa1f applied when using hibernated. If there is enough interest, we can maybe provide at least some basic level of maintenance for these projects together, maybe under the dlang-community umbrella or similar. Per adoption guidelines[1], I think the projects are popular enough, but Hibernated is of course not the only D ORM (although a pretty complete one), and the continued maintenance is also not sure, even when PRs finally get reviewed and accepted faster (but that really depends on the library users). In any case, we need to get in contact with buggins. I asked him ages ago about Hibernated on Gitter, but that was probably the worst way to contact him (as he is active on Github, but probably never read that message). [1]: https://github.com/dlang-community/discussions Guys, If someone is ready to maintain these projects, I can grant privileges for github repositories ddbc, hibernated. Best regards, Buggins
Re: Store any callable in an array
Thanks for replying.
On Friday, 4 May 2018 at 19:12:16 UTC, ag0aep6g wrote:
On 05/04/2018 06:33 PM, Neia Neutuladh wrote:
auto asDelegate(TFunc)(TFunc func) @trusted
{
import std.functional : toDelegate;
return toDelegate(func);
}
The "@trusted" means that you promise this thing is safe, even
if the compiler can't be certain.
If toDelegate isn't (always) @safe, how can you be sure that
your wrapper is? Also, TFunc may have an unsafe destructor.
That's not good use of `@trusted`.
Could you elaborate on the unsafe destructor please? Are there
any other gotchas ?
Re: Store any callable in an array
Thanks for replying. On Saturday, 5 May 2018 at 00:30:35 UTC, Neia Neutuladh wrote: On Friday, 4 May 2018 at 19:12:16 UTC, ag0aep6g wrote: [...] If it's a user-defined type with opCall, that's something to pay attention to, but it's beyond the scope of the original question. Actually it's not. Callable structs/classes are use cases I'm asking about as well.
Re: Purity of delegate-style toString
On Tuesday, 1 May 2018 at 12:03:15 UTC, ag0aep6g wrote:
On 05/01/2018 01:44 PM, Per Nordlöw wrote:
In which cases (if any) is it possible to make a
delegate-style implementation of toString such as
void toString(scope void delegate(const(char)[]) sink)
const @trusted pure
{
// sink("...");
// sink.formattedWrite!"..."(...);
}
pure?
You have to mark `sink` as pure, too:
void toString(scope void delegate (const(char)[]) pure sink)
const @trusted pure
Then the toString method itself works, but it may not be
callable by other code that wants to use an impure sink.
For example, `format` works, but `writeln` doesn't:
struct S
{
void toString(scope void delegate(const(char)[]) pure sink)
const @trusted pure
{
import std.format: formattedWrite;
sink("...");
sink.formattedWrite!"%s"(" ...");
}
}
void main()
{
import std.format: format;
import std.stdio: writeln;
writeln(format("%s", S())); /* Ok. Prints "... ...". */
writeln(S()); /* Nope. writeln would like to use an impure
sink. */
}
By the way, you shouldn't mark toString as @trusted when `sink`
is @system.
I had similar issue for opApply.
The generalized problem is, the attributes (pure, nothrow, @safe,
@nogc) are too strong on functionals (i.e. functions taking
function/delegate arguments). We could (and IMO should) weaken
the attributes to mean: the same as always, *assuming all
function/delegate arguments have it*.
Concrete example, say your `toString(scope void
delegate(const(char)[]))` is conceptually pure, i.e. if `sink` is
a pure function (by static typing), `toString(sink)` acts pure,
and for impure `sink`, `toString(sink)` possibly impure. So
purity of the functional `toString` depends on the purity of its
arguments; that is very natural as most functionals call their
parameters.
The current state makes attributes virtually useless for
functionals. Often, toString can be templetized without drawback
(except virtual functions), but opApply cannot. opApply must not
be a template to enable type deduction for the variable.[1]
Making attributes act structurally has almost no consequences in
terms of breakage; just more functions can be
pure/nothrow/@nogc/@safe. It would make functionals
impure/unsafe/..
that do not call their argument. The question is, in which
contexts are they used and is it an issue -- is it a greater
issue than this.
Complete example what the change would do:
Say you have
void toString(scope void delegate(const(char)[]) sink) pure {
sink("Example"); }
toString is a pure functional, so calling it is pure iff the
argument itself is. The compiler statically knows if the argument
is pure and can infer the purity of the expression.
[1]
https://dlang.org/spec/statement.html#foreach_over_struct_and_classes
(We could define very general special cases where type deduction
can be archived, e.g. opApply(DG : int delegate(Args))(DG).)
Overload Resulution Template with 2 Functions vs. 2 Templates difference
Why is there a difference between
struct S
{
template func(T)
{
enum impl = "whatever string";
auto func(T arg) { mixin(impl); } // eponymous template
auto func(T arg) const { mixin(impl); } // eponymous template
}
}
and
struct R
{
private enum impl = "whatever string";
auto func(T)(T arg) { mixin(impl); }
auto func(T)(T arg) const { mixin(impl); }
}
And what is the difference exactly? I know that
auto func(T)(T arg) { mixin(impl); }
is strictly equivalent to
template func(T) { auto func(T)(T arg) { mixin(impl); } }
so the difference is just 2 templates 1 function each vs. 1
template 2 functions.
I don't have a simple example; here is no difference observable.
The issue is with std.typecons.Tuple.opCmp; there are two
templates and I tried making it one, as the implementation is
identical. Unfortunately, one cannot use `inout` for more or less
obcious reasons.
An attempt to put them into one template (as for struct S) does
not work either, but I don't understand why. Solution like struct
R works.
Is there a complete reference for how overload resolution works
in D, including implicit template instantiation?
Re: C++ / const class pointer signature / unable to find correct D syntax
On Friday, 4 May 2018 at 07:57:26 UTC, Uknown wrote:
On Friday, 4 May 2018 at 07:49:02 UTC, Robert M. Münch wrote:
I have a static C++ and can't make it to get a correct binding
for one function:
DMD: public: unsigned int __cdecl b2d::Context2D::_begin(class
b2d::Image & __ptr64,class b2d::Context2D::InitParams const *
__ptr64 const) __ptr64
LIB: public: unsigned int __cdecl b2d::Context2D::_begin(class
b2d::Image & __ptr64,class b2d::Context2D::InitParams const *
__ptr64) __ptr64
So I somehow get some more const from D. This is the code I
used:
final uint _begin(ref Image image, const(InitParams)
initParams);
Which creates a const pointer to a const class signature. But
it should only be a const pointer. Any idea how to solve this?
The problem is that const in D is transitive. That means T *
const from C++ is not expressible in D. Any reference through a
const becomes const. To use it, IMO your best bet is to make a
wrapper function on the C++ side like this:
unsigned int __cdecl b2d::Context2D::_begin(class b2d::Image &
im,class b2d::Context2D::InitParams const * const InitParams)
{
return //the call to the original c++ function
}
Alternatively you can use dpp, or dstep or some similar tool to
try and let the tool create bindings. As a last ditch, you can
force the mangle to match by using pragma(mangle, ...) like
this:
pragma(mangle, _ZactualMangleFromC++Compiler)
final uint _begin(ref Image image, const(InitParams)
initParams);
Using pragma(mangle) isn't really a solution though, unless you
only plan on using one platform/compiler. C++ doesn't have a
single standard name mangling. You would need to get the name
mangling for every compiler you plan to use then use a version
define fore each. Which isn't really practical for how many
bindings you would need to do that for.
The easiest solution is to just write C bindings for the C++
library then use those instead from D.
Re: could someone test support for Asian languages in nanogui port?
On 06.05.2018 06:10, Binghoo Dang wrote: hi, I'm a Chinese, and I just have done the test. I also copied some Japanese text from Dlang twitter channel and added some Chinese wide punctuation Char. And It's all seems displayed correctly. The resulting screenshot is here: https://pasteboard.co/HjRmOYg.png The only problem is that the font style simply looks strange. You can see the 'normal' text display in Win10 by default like this: https://pasteboard.co/HjRrigh.png Can it fixed by other font or there are some other problems? And the font problem is probably related to SDL or GL, for all UI based on GL or SDL, they all have the same problem. Dlangui also has the same situation, that's why I just did not use Dlangui for a production project. Could you describe the problem in more details? But, Anyway, the text is displayed correctly. Great work for doing this! Dlang needs a great GUI framework. Thank you for your time!
