Re: Is HibernateD dead?
On Monday, 7 May 2018 at 18:15:17 UTC, Matthias Klumpp wrote: On Monday, 7 May 2018 at 08:26:15 UTC, bauss wrote: On Monday, 7 May 2018 at 06:12:19 UTC, Vadim Lopatin wrote: 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: [...] If someone is ready to maintain these projects, I can grant privileges for github repositories ddbc, hibernated. Best regards, Buggins I wouldn't mind attempting maintaining them I would help out as much as I can as well (but I lack the skill and time to properly maintain it, especially since I mostly care about my Postgres usecase, and not much about MySQL or ODBC). Having ddbc in dlang-community might actually be a neat thing, to make it very easy for other contributors to merge stuff and easy the maintenance of it. But ultimately that's Bauss' call, as potential future maintainer :-) P.S: @Bauss: While you definitely will want ddbc as solid database abstraction, for Hibernated you might want to change it to be less Java-esque and maybe fit your existing ORM better. Well it should still be backward compatible tbh. Even if abstractions are put on top of it, since some people already rely on it. I agree it would be nice to have it part of the dlang-community organization. If that isn't possible then I'm open to have it a part of Diamond's organization if he'd be okay with that. Anyone willing to maintain it will get write access. I believe it's better as a part of an organization rather than as a personal repository, because it won't suffer from always looking like it's a personal project. Ultimately it's his call who should maintain it.
Re: dxml behavior after exception: continue parsing
On Monday, May 07, 2018 22:16:58 Jesse Phillips via Digitalmars-d-learn
wrote:
> On Monday, 7 May 2018 at 19:46:00 UTC, Jesse Phillips wrote:
> > So I have an XML like document which fails to adhere completely
> > to XML. One of these such events is that & is used without
> > escaping.
> >
> > My observation is that after the exception it is possible to
> > move to the next element without issue. Is this something
> > expected and will be maintained?
> >
> > try {
> >
> > range.popFront();
> >
> > } catch (Exception e) {
> >
> > range.popFront;
> >
> > }
>
> Ok so this worked when inside a quoted attribute value but not a
> normal tag body. Clearly I'm not parsing valid XML so I'm going
> outside the bounds of valid parameters. But rather than writing a
> custom parser to handle this, it would be nice to have:
>
> try {
> range.popFront();
> } catch (Exception e) {
> range.moveToNextTag();
> }
>
> Which would make front a MalformedParse containing the content up
> to the next <.
I don't think that such an approach would work with how dxml does its
validation, because it's designed with the idea that only the range farthest
along does the validation (which was critical in avoiding having to allocate
memory in functions like save). Some validation is currently done by every
range, but it's been my plan too look at making it so that as little
validation as possible is done by the other ranges. Either way, the fact
that any validation is skipped by ranges that are farther behind would cause
a definite problem with trying to then continue parsing passed invalid XML.
As it stands, any range that is farther behind should throw the same
exception when it reaches the one that first hit the invalid XML, whereas if
that range could somehow continue, then the range that's farther behind
would then not do the same validation and would not do the right thing when
it hit the point where moveToNextTag had been called on the first range.
- Jonathan M Davis
Re: dxml behavior after exception: continue parsing
On Monday, May 07, 2018 19:46:00 Jesse Phillips via Digitalmars-d-learn
wrote:
> So I have an XML like document which fails to adhere completely
> to XML. One of these such events is that & is used without
> escaping.
>
> My observation is that after the exception it is possible to move
> to the next element without issue. Is this something expected and
> will be maintained?
>
>
> try {
> range.popFront();
> } catch (Exception e) {
> range.popFront;
> }
The documentation on EntityRange / parseXML specifically states:
"If invalid XML is encountered at any point during the parsing process, an
XMLParsingException will be thrown. If an exception has been thrown, then
the parser is in an invalid state, and it is an error to call any functions
on it."
What happens if you continue parsing after an exception is effectively
undefined behavior and could vary wildly depending on what was invalid in
the XML and which part of the parser threw. It may very well be that in some
circumstances, you would be able to continue parsing without any real
negative side effects, but the parser could also end up asserting or doing
who-knows-what, because it's not in a valid state. I could add a member to
the parser which says whether it's in a valid state or not an then have the
parser throw if you try to call anything on it after an exception has been
thrown, but that would add overhead that I'd rather avoid. At most, such a
check would be done with assertions like the checks for whether you're
allowed to call name, text, or attributes are assertions.
I've been considering adding more configuration options where you say
something like you don't care if any invalid characters are encountered, in
which case, you could cleanly parse past something like an unescaped &, but
you'd then potentially be operating on invalid XML without knowing it and
could get undesirable results depending on what exactly is wrong with the
XML. I haven't decided for sure whether I'm going to add any such
configuration options or how fine-grained they'd be, but either way, the
current behavior will continue to be the default behavior.
- Jonathan M Davis
Re: dxml behavior after exception: continue parsing
On Monday, 7 May 2018 at 19:46:00 UTC, Jesse Phillips wrote:
So I have an XML like document which fails to adhere completely
to XML. One of these such events is that & is used without
escaping.
My observation is that after the exception it is possible to
move to the next element without issue. Is this something
expected and will be maintained?
try {
range.popFront();
} catch (Exception e) {
range.popFront;
}
Ok so this worked when inside a quoted attribute value but not a
normal tag body. Clearly I'm not parsing valid XML so I'm going
outside the bounds of valid parameters. But rather than writing a
custom parser to handle this, it would be nice to have:
try {
range.popFront();
} catch (Exception e) {
range.moveToNextTag();
}
Which would make front a MalformedParse containing the content up
to the next <.
Re: Is HibernateD dead?
On Monday, 7 May 2018 at 06:12:19 UTC, Vadim Lopatin wrote: Guys, If someone is ready to maintain these projects, I can grant privileges for github repositories ddbc, hibernated. Best regards, Buggins I'm happy to put some time in
dxml behavior after exception: continue parsing
So I have an XML like document which fails to adhere completely
to XML. One of these such events is that & is used without
escaping.
My observation is that after the exception it is possible to move
to the next element without issue. Is this something expected and
will be maintained?
try {
range.popFront();
} catch (Exception e) {
range.popFront;
}
As an aside, here is a snippet for skipping over the BOM since
dxml doesn't expect the BOM to be there:
import std.encoding;
import std.algorithm;
auto fileContent = cast(ubyte[])read(file);
if(getBOM(fileContent).schema != BOM.none)
fileContent.skipOver(getBOM(fileContent).sequence);
Re: Is HibernateD dead?
On Monday, 7 May 2018 at 08:26:15 UTC, bauss wrote: On Monday, 7 May 2018 at 06:12:19 UTC, Vadim Lopatin wrote: 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: [...] If someone is ready to maintain these projects, I can grant privileges for github repositories ddbc, hibernated. Best regards, Buggins I wouldn't mind attempting maintaining them I would help out as much as I can as well (but I lack the skill and time to properly maintain it, especially since I mostly care about my Postgres usecase, and not much about MySQL or ODBC). Having ddbc in dlang-community might actually be a neat thing, to make it very easy for other contributors to merge stuff and easy the maintenance of it. But ultimately that's Bauss' call, as potential future maintainer :-) P.S: @Bauss: While you definitely will want ddbc as solid database abstraction, for Hibernated you might want to change it to be less Java-esque and maybe fit your existing ORM better.
Re: Is HibernateD dead?
On Saturday, 5 May 2018 at 09:32:32 UTC, Brian 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? You can use Entity & Database library: https://github.com/huntlabs/entity https://github.com/huntlabs/database I've tried both a while back, and they are still inferior to Hibernated (no surprise there, both projects are very new). There was even a "fun" SQL injection issue initially. So, while in the long run Entity might be a great option, if you want an ORM that is as complete as Hibernated is today, it's not a solution (I have high hopes for it though).
Re: Is HibernateD dead?
You should get a hold of Vadim Lopatin and see if he would give you commit rights to the main repo. There was a great article I can't find by someone who would add contributors if they made good pull requests. It helped to keep his work living on and didn't need to keep involved. So I push for people to follow this model (remove contributors if it isn't working out.
Re: Windows to Linux Porting - timeCreated and timeLastAccessed
On Monday, 7 May 2018 at 14:31:23 UTC, Jesse Phillips wrote: I wouldn't use time created. It can be newer than last modified this wholey inacurate. Last accessed could be a much more appopriate choice if trying to determine what is important. Sorry, to answer your actual question, I do believe that using the OS version specification to select the function is correct.
Re: Windows to Linux Porting - timeCreated and timeLastAccessed
On Friday, 4 May 2018 at 11:49:24 UTC, Vino wrote: Hi All, Request your help, I have a D program written on Windows platform and the program is working as expected, now i am trying to port the same program to Linux, my program use the function "timeCreated" from std.file for Windows hugely where as in Linux we do not have the same function hence planned to use the function "timeLastAccessed" from std.file, so what is the best approach to port the program. I tried the below code but not working, so can you one please guide me on the right method to port the program to linux, below is the example code. I wouldn't use time created. It can be newer than last modified this wholey inacurate. Last accessed could be a much more appopriate choice if trying to determine what is important.
Re: `recursive template expansion` error msg isn't informative
On Monday, 7 May 2018 at 10:28:14 UTC, drug wrote: I get the error like: ``` ./foo/bar/baz/builder.d(57,23): Error: template instance `staticMap!(DebugTypeMapper, BaseDebuggerTypes)` recursive template expansion ``` That's all. It doesn's print instantiations stack so I can't track back the reason. Could someone give an advice how to struggle with such error? Could you give us some code snippet to eventually reproduce it?
Re: Windows to Linux Porting - timeCreated and timeLastAccessed
On Friday, 4 May 2018 at 15:42:56 UTC, wjoe wrote: I think that's not possible. You can't query information that hasn't been stored. I stand corrected. As Russel Winder points out there are file systems that store this information and since Linux 4.11 you can query it via statx(2).
Re: Store any callable in an array
On Monday, 7 May 2018 at 10:20:22 UTC, ag0aep6g wrote:
On 05/07/2018 04:41 AM, wjoe wrote:
Could you elaborate on the unsafe destructor please?
If TFunc has an unsafe destructor, asDelegate is also not safe
and can't be @trusted.
An example of how that can break safety:
auto asDelegate(TFunc)(TFunc func) @trusted
{
import std.functional : toDelegate;
return toDelegate(func);
}
int* ptr;
size_t length;
struct S
{
void opCall() {}
~this() @system
{
ptr[length - 1] = 13;
}
}
void main() @safe
{
ptr = new int;
length = 5; /* Whoops, got the length wrong. */
immutable int* imm = new int(42);
auto dg = asDelegate(S.init);
assert(*imm == 42); /* Fails. Immutability has been broken.
*/
}
The program has undefined behavior, which means it's invalid.
And it's the fault of the wrong @trusted.
Are there any other gotchas ?
The postblit function `this(this)` is also commonly overlooked
with regards to @trusted. It might not be a problem here,
though, because toDelegate has a `ref` parameter.
An unsafe `alias this` would be another problem. Example:
/* ... asDelegate, ptr, length, main as above ... */
struct S
{
@property T t() @system
{
ptr[length - 1] = 13;
return T.init;
}
alias t this;
}
struct T
{
void opCall() {}
}
Those are the things I can see happening in asDelegate.
Additionally, you'd have to check what the toDelegate call does
exactly before trusting it. And if it turns out that the call
can be trusted, then you can probably just mark toDelegate
itself as @trusted. And then there would be no need for
asDelegate anymore.
Thank you for taking the time to write up this reply and widen my
horizon. Very much appreciated.
After further investigation I found a post where someone asked
about the differences of function/delegate and one of the replies
explained that functions converted to a delegate occur a
considerable performance impact.
This and since toDelegate has a bug with @safe functions, and
slapping a @trusted on to it sounds like more headache than it's
worth, I will handle these cases separately.
Thanks everybody for all the replies.
`recursive template expansion` error msg isn't informative
I get the error like: ``` ./foo/bar/baz/builder.d(57,23): Error: template instance `staticMap!(DebugTypeMapper, BaseDebuggerTypes)` recursive template expansion ``` That's all. It doesn's print instantiations stack so I can't track back the reason. Could someone give an advice how to struggle with such error?
Re: Store any callable in an array
On 05/07/2018 04:41 AM, wjoe wrote:
Could you elaborate on the unsafe destructor please?
If TFunc has an unsafe destructor, asDelegate is also not safe and can't
be @trusted.
An example of how that can break safety:
auto asDelegate(TFunc)(TFunc func) @trusted
{
import std.functional : toDelegate;
return toDelegate(func);
}
int* ptr;
size_t length;
struct S
{
void opCall() {}
~this() @system
{
ptr[length - 1] = 13;
}
}
void main() @safe
{
ptr = new int;
length = 5; /* Whoops, got the length wrong. */
immutable int* imm = new int(42);
auto dg = asDelegate(S.init);
assert(*imm == 42); /* Fails. Immutability has been broken. */
}
The program has undefined behavior, which means it's invalid. And it's
the fault of the wrong @trusted.
Are there any other gotchas ?
The postblit function `this(this)` is also commonly overlooked with
regards to @trusted. It might not be a problem here, though, because
toDelegate has a `ref` parameter.
An unsafe `alias this` would be another problem. Example:
/* ... asDelegate, ptr, length, main as above ... */
struct S
{
@property T t() @system
{
ptr[length - 1] = 13;
return T.init;
}
alias t this;
}
struct T
{
void opCall() {}
}
Those are the things I can see happening in asDelegate.
Additionally, you'd have to check what the toDelegate call does exactly
before trusting it. And if it turns out that the call can be trusted,
then you can probably just mark toDelegate itself as @trusted. And then
there would be no need for asDelegate anymore.
Re: Is HibernateD dead?
On Monday, 7 May 2018 at 06:12:19 UTC, Vadim Lopatin wrote: 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 I wouldn't mind attempting maintaining them
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
