splitter and matcher combined regex
Having to split and match seems slow(50%). Surely the regex splitter and matcher can be combined? Sometimes we just need to extract out and remove information simultaneously. I propose a new function called extractor that returns the matchAll and splitter's results but is optimized.
Scope exit bug?
void foo()
{
void bar() { foo; }
switch
case: scope(exit) { do } break
bar;
}
fails to execute do
void foo()
{
void bar() { foo; }
switch
case: bar; do return;
bar;
}
does work... yet there is no difference except the scope exit.
In my code it is if do is never executed...
I used it to avoid having to write bar twice or use a flag but
it's not working... I see no reason why it should not work.
scope(exit) is suppose to execute the block at the end of the
function call, right?
arsd dom
When parsing an xml file I get #text for tagName on basically
every other element.
I'm trying to recurse through all the elements
using
void recurse(T)(T parent, int depth = 0)
{
foreach(c; parent.children)
{
recurse(c, depth + 1);
writeln("\t".replicate(depth)~c.tagName);
}
//writeln("\t".replicate(depth)~parent.tagName);
}
recurse(i);
and I get
#text
requires
#text
#text
#text
property
#text
#text
property
#text
#text
property
#text
#text
property
#text
#text
property
#text
#text
#text
#text
property
#text
#text
property
#text
#text
property
#text
Any idea what might be going on?
Re: if (X !is null && X.Y !is null) access crash
On Monday, 10 June 2019 at 19:48:18 UTC, Steven Schveighoffer wrote: On 6/9/19 1:25 AM, Amex wrote: On Saturday, 8 June 2019 at 20:44:13 UTC, Steven Schveighoffer wrote: Try GC.addRef on the X reference, and see if it helps. This is during shutdown so I imagine simply turning off the GC should work fine? That way it prevents all cases rather than having to add a bunch of specific cases each time they crop up. I'm not sure if you can shut off the final collection. All you can do is disable collections during allocations. -Steve So far it seems to be working. It may prevent a collection at the right time that causes the problem... it all may be coincidence.
Re: if (X !is null && X.Y !is null) access crash
On Saturday, 8 June 2019 at 20:44:13 UTC, Steven Schveighoffer wrote: On 6/8/19 2:28 AM, Amex wrote: On Friday, 7 June 2019 at 16:09:47 UTC, Adam D. Ruppe wrote: It happens when I close down my app. is this inside a destructor? No, it's in an external thread(it is in a callback). All I can think of is that something is happening in between the two checks since there is no way it could happen otherwise. Possible the GC cleaned up the object already. When this happens, you get this kind of behavior (the GC intentionally sets the vtable to null to prevent invalid access). Try GC.addRef on the X reference, and see if it helps. -Steve This is during shutdown so I imagine simply turning off the GC should work fine? That way it prevents all cases rather than having to add a bunch of specific cases each time they crop up.
Can D optimize?
Can dmd or ldc optimize the following cases:
foo(int x)
{
if (x > 10 && x < 100) bar1; else bar2;
}
...
for(int i = 23; i < 55; i++)
foo(i); // equivalent to calling bar1(i)
clearly i is within the range of the if in foo and so the checks
are unnecessary.
I realize that this is generally a complex and possibly
unsolvable problem... but in the example above, which comes up
enough, it is not.
Many times when one iterates over an array the boundaries cause
special cases... for maximum performance one has to break up the
boundary cases which just increases code complexity and
verbosity. If the compiler can figure it out automatically then
it is unnecessary.
When working with algorithms
Of course, if the limits are not known at compile time this
method cannot be used...
So, I'm wondering if there is a simple way to achieve the same
thing that is easy on the eyes.
Suppose we have a resampling function. The boundaries require
different functionality.
So there are effectively 3 functions and the loop over the data
would be split up in to three parts. Normally we have to do it by
hand and maintain everything.
I imagine ranges might be able to help solve this in an optimal
way but I'm not sure what might be the best approach. It should
be equivalent to hand written code if not better.
Re: if (X !is null && X.Y !is null) access crash
On Friday, 7 June 2019 at 16:09:47 UTC, Adam D. Ruppe wrote: It happens when I close down my app. is this inside a destructor? No, it's in an external thread(it is in a callback). All I can think of is that something is happening in between the two checks since there is no way it could happen otherwise.
Re: if (X !is null && X.Y !is null) access crash
On Friday, 7 June 2019 at 14:07:34 UTC, KnightMare wrote: On Friday, 7 June 2019 at 09:26:52 UTC, Amex wrote: if (X !is null && X.Y !is null) access crash is crashing. imo this code is valid. u can write shorter if (X && X.Y) probably crashed in some another place (X is not objRef but something else.. some code later at same line.. dunno) The debugger is telling me it is at that line. X is an object. In the debugger X is shown with an address yet when expanded all the members are invalid. It happens rarely so it makes it even harder to diagnose. Only thing I can think of is that it has to do with the GC. I suppose I could turn off the GC for shutting down and that might prevent such as crash.
Re: FieldNameTuple!T and std.traits.Fields!T not empty for interfaces
On Thursday, 6 June 2019 at 20:52:42 UTC, Steven Schveighoffer wrote: On 6/6/19 4:49 PM, Steven Schveighoffer wrote: Oh wait! It's not empty, it has an empty string as a single member! That's definitely a bug. OK, not a bug, but not what I would have expected. From docs: "If T isn't a struct, class, or union, an expression tuple with an empty string is returned." I wonder why that behavior is there, certainly it's intentional. -Steve It is wrong, regardless if it is intentional. Every day people do intentional things that are wrong. The problem is that one returns a non-empty tuple and so loops will be executed on the empty string. While one can test for the empty string return there is absolutely no reason why one shouldn't just return an empty tuple as it plays correctly with the use case.
if (X !is null && X.Y !is null) access crash
I don't understand why if (X !is null && X.Y !is null) access crash is crashing. It is true that it is being used in a thread. It happens when I close down my app. The whole point of the check is to make sure X is not null but it seems to be failing. The debugger is showing X is not null yet X.Y is null. (Y is a delegate) I believe this is because I'm not using shared(which causes problems with orange serdes) and the GC. I'm not sure though.
FieldNameTuple!T and std.traits.Fields!T not empty for interfaces
FieldNameTuple!T std.traits.Fields!T are non-empty when T is an interface! An interface cannot contain fields and yet these return non-zero and screws up my code. While I can filter for interfaces it makes me wonder what else may slip through? Is it a bug or what is going on?
typeid, typeinfo, classinfo not returning most derived
- x 0x004b71e0 {Interface for main.I} {m_init={length=0
ptr=0x}, name="main.I", vtbl={length=0 ptr=0x},
...} object.TypeInfo_Class {TypeInfo_Class}
[TypeInfo_Class]D0006: Error: Type resolve failed
m_init {length=0 ptr=0x} byte[]
+ name"main.I" string
vtbl{length=0 ptr=0x} void*[]
interfaces {length=0 ptr=0x}
object.Interface[]
base0x object.TypeInfo_Class
destructor 0x void*
classInvariant 0x void function(object.Object)*
m_flags 36 uint
deallocator 0x void*
m_offTi {length=0 ptr=0x} object.OffsetTypeInfo[]
defaultConstructor 0x void
function(object.Object)*
m_RTInfo0x const(void)*
- i 0x004b71e0 {Interface for main.I} {m_init={length=0
ptr=0x}, name="main.I", vtbl={length=0 ptr=0x},
...} object.TypeInfo_Class {TypeInfo_Class}
[TypeInfo_Class]D0006: Error: Type resolve failed
m_init {length=0 ptr=0x} byte[]
+ name"main.I" string
vtbl{length=0 ptr=0x} void*[]
interfaces {length=0 ptr=0x}
object.Interface[]
base0x object.TypeInfo_Class
destructor 0x void*
classInvariant 0x void function(object.Object)*
m_flags 36 uint
deallocator 0x void*
m_offTi {length=0 ptr=0x} object.OffsetTypeInfo[]
defaultConstructor 0x void
function(object.Object)*
m_RTInfo0x const(void)*
- c 0x004b71e0 {Interface for main.I} {m_init={length=0
ptr=0x}, name="main.I", vtbl={length=0 ptr=0x},
...} object.TypeInfo_Class {TypeInfo_Class}
[TypeInfo_Class]D0006: Error: Type resolve failed
m_init {length=0 ptr=0x} byte[]
+ name"main.I" string
vtbl{length=0 ptr=0x} void*[]
interfaces {length=0 ptr=0x}
object.Interface[]
base0x object.TypeInfo_Class
destructor 0x void*
classInvariant 0x void function(object.Object)*
m_flags 36 uint
deallocator 0x void*
m_offTi {length=0 ptr=0x} object.OffsetTypeInfo[]
defaultConstructor 0x void
function(object.Object)*
m_RTInfo0x const(void)*
Simply for the code
auto info(T)(T o)
{
auto x = typeid(o);
auto i = x.typeinfo;
auto c = o.classinfo;
return;
}
info exists in it's own module called from the main module.
interface I
{
void foo();
}
abstract class A : I
{
}
class C : A
{
void foo()
{
writeln("x");
}
}
class D : C { }
and
I i = new D();
info(i);
(more or less)
-v lots of junk
Using -v I get a whole list(100's) of stuff that is irrelevant: ... import core.sys.windows.w32api (C:\dmd2\windows\bin\..\..\src\druntime\import\core\sys\windows\w32api.d) import core.sys.windows.basetyps (C:\dmd2\windows\bin\..\..\src\druntime\import\core\sys\windows\basetyps.d) import core.sys.windows.winver (C:\dmd2\windows\bin\..\..\src\druntime\import\core\sys\windows\winver.d) library kernel32 library version ... I'm using -v because it says I have to to see the expanded errors... so I do but then I get all the junk above.
Re: Very simple null reference escape
On Sunday, 2 June 2019 at 14:37:48 UTC, Paul Backus wrote:
On Sunday, 2 June 2019 at 07:55:27 UTC, Amex wrote:
A.B
If A is null, crash.
A?.B : writeln("HAHA");
No crash, ignored, equivalent to
if (A is null) writeln("HAHA"); else A.B;
The "optional" package on dub [1] has a .dispatch method that
does this:
auto d = some(A());
// Dispatch to one of its methods
d.dispatch.f(); // calls a.f, returns some(4)
d.dispatch.inner.g(); // calls a.inner.g, returns some(7)
// Use on a pointer or reference type as well
A* e = null;
// If there's no value in the reference type, dispatching
// works, and produces an optional
assert(e.dispatch.f() == none);
assert(e.dispatch.inner.g() == none);
Full example: https://run.dlang.io/is/SmsGQu
[1] https://code.dlang.org/packages/optional
thanks.
Error: module `M.Q` from file M\Q.d conflicts with another module Q from file M\Q.d
main.d(217): Error: module `M.Q` from file M\Q.d conflicts with another module Q from file M\Q.d the line is simply import Q : foo; the problem is that it should have been import M.Q : foo; There is no module Q. The error message is in error! There is no other module. the module is named module M.Q; where M is a subdirectory. This is probably suppose to be module Q; but everything works out. The error message could be more accurate(took me a min to figure out what was going on).
import and call
Tired of having to import a single function to call it. Since mod.foo(x); doesn't work since mod is not defined. we have to do import mod : foo; foo(x); Why not mod:foo(x)? or mod#foo(x) or mod@foo(x) or whatever Reduces 50% of the lines and reduces the import symbol. I realize that we could do import m = mod; m.foo(x); but the idea is to only import the single function. I'm not sure if it matters. I thought importing single functions were suppose to be faster. Am I wrong? The idea is to reduce having to litter the code with imports which I find I'm always having to do, or to make them global... just for a few calls in to them.
Very simple null reference escape
A.B
If A is null, crash.
A?.B : writeln("HAHA");
No crash, ignored, equivalent to
if (A is null) writeln("HAHA"); else A.B;
Re: emulate with
On Friday, 31 May 2019 at 08:35:23 UTC, Simen Kjærås wrote:
On Friday, 31 May 2019 at 07:17:22 UTC, Amex wrote:
What I'm talking about is that if A would be dispatched to,
say, W!X where W handles the special dispatching by returning
X_A rather than X.A.
I don't know if D can do this kinda stuff even though it would
be rather simple as it would depend on with.
Of course D can! However, it's not really pretty, and I think I
found a bug in the process.
This is my code that compiles and runs:
void X_A(int i) {}
void X_A(string s) {}
void X_B(int i) {}
void X_C_Q(int i) {}
unittest {
with (Dispatcher.X!({})) {
A(1);
A("a");
B(2);
C_Q(3);
}
}
template getMethod(alias x, string name) {
static if (__traits(hasMember, x, name)) {
alias getMethod = __traits(getMember, x, name);
} else static if (x.stringof[0..7] == "module ") {
import std.meta : AliasSeq;
alias getMethod = AliasSeq!();
} else {
alias getMethod = getMethod!(__traits(parent, x), name);
}
}
struct Dispatcher {
template opDispatch(string prefix) {
static auto opDispatch(alias context)() {
struct WithObject {
auto opDispatch(string name, A...)(A a) {
struct OverloadCaller {
auto opCall(Args...)(Args args) {
return getMethod!(context,
prefix~"_"~name)(args);
}
}
OverloadCaller result;
return result;
}
}
return WithObject();
}
}
}
So, the ugly:
1) Instead of just Dispatcher.X, we need to give Dispatcher a
context from where to look for X_. That's the curly
brackets in Dispatcher.X!({}).
2) The bug I mentioned. The whole OverloadCaller deal is a
silly workaround for WithObject's opDispatch not being called
correctly by DMD. That's also why WithObject's opDispatch takes
(A...)(A a). I'll be filing this, of course.
3) with doesn't correctly handle static opDispatch. I'll be
filing a bug for that as well.
We could fix 1) by introducing a new magic identifier -
something like __CONTEXT__, which would work somewhat like
__FUNCTION__, but be useful for reflection with __traits. I've
played a little with this idea, but I'm not ready to make a PR
with it.
With 1), 2) and 3) fixed, the code would look like this (only
changed code included):
unittest {
with (Dispatcher.X) {
A(1);
A("a");
B(2);
C_Q(3);
}
}
struct Dispatcher {
struct opDispatch(string prefix, alias context =
__CONTEXT__) {
static auto opDispatch(string name, Args...)(Args args)
{
return getMethod!(context, prefix~"_"~name)(args);
}
}
}
I think that's kinda neat, TBH.
--
Simen
Thanks, I haven't messed with it but it by your examples it
should do what I want...
I actually probably need the use of .'s turned in to _'s... so I
can write stuff like
A.B.C.D and it all goes to X.A_B_C_D.
I'm not sure if A.B.C.D would get dispatched as a whole or just
in part though(e.g., is it treated as A.(B.(C.D)) or (A.B).C).D
or A.B.C.D) which would require some type of chaining dispatcher
I guess).
In any case it helps with my specific problem. I like the idea of
_CONTEXT_ and it might be usable in other areas.
Thanks.
emulate with
with lets one remove a direct reference...
The problem is the things I want to access are not part of a
single object but have a common naming structure:
X_A
X_B
X_C_Q
(rather than X.A, X.B, X.C.Q)
it would be very helpful(since X is long) to be able to do
something like
with(X)
{
A;
B;
C_Q;
}
or even
with(X)
{
A;
B;
with(C)
{
Q;
}
}
I imagine this can actually be done with dispatching because one
could use opDispatch to redirect. The problem is that this
requires filling out the info which sorta defeated the
purpose(unless it's used often).
What I'm talking about is that if A would be dispatched to, say,
W!X where W handles the special dispatching by returning X_A
rather than X.A.
I don't know if D can do this kinda stuff even though it would be
rather simple as it would depend on with.
e.g., would be cool if there was an opWith ;)
Adding a payload to a type
I have some types I've declared and I'd like to magically extend them and add data. The problem is I inheriting from them them is bad news. Suppose, for example, I have an image type that is used in an application. For a small part of the application it needs to associate with each image type an xy coordinate type that adds a coordinate to the image to be used by the part of the app that needs to have coordinates for the image. The rest of the app does not care or need the xy coordinates. Inheritance solves this problem in some sense except it doesn't. If I want to add new data then it breaks. class image; class xy : image; // can only add an image. class z : ??; ?? could be xy, image, or something else Inheritance is not the correct thing to do here. I only want to associate data with an object. The hierarchy does not matter. I could add a payload type to image but this causes problems since it would have to be void or of a singular type. Mainly it causes problems with the serializer I'm using since it can't handle voids(I might be able to get it to work with a special type but it will not be easy). I could, of course, add a parallel struct that somehow associates the image it's extra data but to keep them in sync will not be easy since it will have to persist between runs(so the address could not be used). One could think of what I'm trying to do is create a tuple that holds the image and any other data. tuple(tuple(image, xy), z) // the outer tuple may occur later without knowing that the image has been "wrapped". How does one normally handle this? It seems like something really simple to do(attach data) but it has no real programmatic way to do naturally that works with oop. The main thing is that attaching different data should "stack" and not effect the base type or break the type hierarchy. If something takes an image it should take any extended object. I feel like the only way to do this is to create a special type that can be serialized properly and is part of the base class... I'll have to do it for all the classes. Hopefully someone has some better ideas?
Re: GtkD slows down visual D keyboard
On Friday, 26 April 2019 at 14:50:17 UTC, Mike Wey wrote:
On 26-04-2019 10:31, Amex wrote:
When debugging under visual D, the keyboard response is slowed
down to the extreme. This is a Gtk issue I believe. It only
has to do with the keyboard.
For example, if I hit F10 to step, it takes the ide about 10
seconds to "respond" and move to the next line... yet the
mouse can access stuff instantaneous.
I believe Gtk or GtkD is slowing down the keyboard input
somehow and for some reason making debugging apps a nightmare
since it literally takes about 100 times longer to debug than
it should.
searching google reveals:
https://github.com/Microsoft/vcpkg/issues/4529
https://developercommunity.visualstudio.com/content/problem/42018/debugging-with-keyboard-very-slow.html
"You somehow break keyboard shortcuts during debugging in VS
if the application you're debugging is registering a callback
with "SetWindowsHookEx" from user32.dll with hook ID
"WH_KEYBOARD_LL".
Don't call it in debug builds or add "if
(!Debugger.IsAttached)" in front of the call to
"SetWindowsHookEx" if the debugger is attached before the
function is called.
This brings debugging with keyboard back to the same speed as
with the UI buttons for our application."
This seems to be an issue with Gtk. I'm not sure if GtkD can
do anything about it. Maybe somehow reroute the keyboard
handler(first remove it from the hook then call it manually or
reduce the number of calls to it).
I can confirm that gtk call "SetWindowsHookEx" with the
"WH_KEYBOARD_LL" ID upon initialization.
As far as i can tell it doesn't provide a way to skip this.
Could you unhook it and manually call it or simply disable it
when the app is being debugged? essentially just wrap it with a
new hook that selectively calls it.
NewHook()
{
if (notdebugbreak) OldHook
}
Keyboard input doesn't need to happen to the app while in one is
in the debugger so the hook doesn't need to be called.
This requires two things:
1. To be able to get the hook of the function and remove it.
(this might be hard)
2. Know when in debug mode. This should be somewhat easy since
I'm sure Visual Studio sets some flag when broke in to a program.
Alternatively one could add a function that forces disabling
where one could call it in code that they are debugging(which
hopefully doesn't require keyboard input). I rarely am debugging
keyboard stuff so I'd just call it at the start of the program
and benefit from it... and if I have to do keyboard stuff I'll
enable it and suffer... but at least I'll have some control over
the problem.
GtkD slows down visual D keyboard
When debugging under visual D, the keyboard response is slowed down to the extreme. This is a Gtk issue I believe. It only has to do with the keyboard. For example, if I hit F10 to step, it takes the ide about 10 seconds to "respond" and move to the next line... yet the mouse can access stuff instantaneous. I believe Gtk or GtkD is slowing down the keyboard input somehow and for some reason making debugging apps a nightmare since it literally takes about 100 times longer to debug than it should. searching google reveals: https://github.com/Microsoft/vcpkg/issues/4529 https://developercommunity.visualstudio.com/content/problem/42018/debugging-with-keyboard-very-slow.html "You somehow break keyboard shortcuts during debugging in VS if the application you're debugging is registering a callback with "SetWindowsHookEx" from user32.dll with hook ID "WH_KEYBOARD_LL". Don't call it in debug builds or add "if (!Debugger.IsAttached)" in front of the call to "SetWindowsHookEx" if the debugger is attached before the function is called. This brings debugging with keyboard back to the same speed as with the UI buttons for our application." This seems to be an issue with Gtk. I'm not sure if GtkD can do anything about it. Maybe somehow reroute the keyboard handler(first remove it from the hook then call it manually or reduce the number of calls to it).
