splitter and matcher combined regex

2019-06-16 Thread Amex via Digitalmars-d-learn
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?

2019-06-13 Thread Amex via Digitalmars-d-learn



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

2019-06-12 Thread Amex via Digitalmars-d-learn
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

2019-06-10 Thread Amex via Digitalmars-d-learn
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

2019-06-08 Thread Amex via Digitalmars-d-learn
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?

2019-06-08 Thread Amex via Digitalmars-d-learn

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

2019-06-07 Thread Amex via Digitalmars-d-learn

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

2019-06-07 Thread Amex via Digitalmars-d-learn

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

2019-06-07 Thread Amex via Digitalmars-d-learn
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

2019-06-07 Thread Amex via Digitalmars-d-learn

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

2019-06-06 Thread Amex via Digitalmars-d-learn

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

2019-06-06 Thread Amex via Digitalmars-d-learn
-		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

2019-06-05 Thread Amex via Digitalmars-d-learn

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

2019-06-02 Thread Amex via Digitalmars-d-learn

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

2019-06-02 Thread Amex via Digitalmars-d-learn
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

2019-06-02 Thread Amex via Digitalmars-d-learn



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

2019-06-02 Thread Amex via Digitalmars-d-learn

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

2019-05-31 Thread Amex via Digitalmars-d-learn

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

2019-05-31 Thread Amex via Digitalmars-d-learn

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

2019-05-27 Thread Amex via Digitalmars-d-learn
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

2019-04-26 Thread Amex via Digitalmars-d-learn

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

2019-04-26 Thread Amex via Digitalmars-d-learn
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).