Re: gtkDcoding Blog Post for 2019-03-29 - Grid

2019-03-29 Thread Michelle Long via Digitalmars-d-learn

On Friday, 29 March 2019 at 14:25:16 UTC, Ron Tarrant wrote:

I'm having trouble replying to the thread I usually use, so...

There's a new tutorial for using a GTK Grid. You can find it 
here: http://gtkdcoding.com/2019/03/29/0022-grids.html


I really wish you would start taking screenshots! It is not hard!


Duplicate class/interface/struct completely

2019-03-25 Thread Michelle Long via Digitalmars-d-learn
Given a class/interface/struct, I'd like to duplicate it's design 
exactly, as if I copied and pasted directly from the source and 
just changed the name. I need to inspect the contents too. Is 
this possible with D?


Main things I'm thinking will fail are (multiple) alias this 
unless there is a way to get which variables are aliased to this.


The idea is to be able to make sure one can modify a class and 
drop it in for the original and it work in all cases. With alias 
this, it can fail unless we can alias it too.


struct X { int y; alias this y; }

struct XX { mixin DupStruct!X; }

If DupStruct cannot handle the alias this then XX can fail to 
mimic X completely.





Derive from interface

2019-03-25 Thread Michelle Long via Digitalmars-d-learn
Since D does not support multiple inheritance, is there any way 
to effectively achieve this?



class A;
class B;

class C : A, interface!B;

Then it is as if I have done


class A;
interface iB;
class B : iB;

class C : A, iB;

But I can then do

C c = new B;

(but since I can't make B inherit iB, this is impossible)











Re: "if" statement

2019-03-25 Thread Michelle Long via Digitalmars-d-learn

On Sunday, 24 March 2019 at 12:45:13 UTC, Francesco Mecca wrote:

https://run.dlang.io/is/zRcj59

```
alias Alg = Algebraic!(int, string);

void main()
{
int n = 2;
Alg value;

value = n == 2 ? 2 : "string";
}
```

The original code used SumType but the effect is the same.

I suppose that I could write the following:

```
if(n == 2) value = 2;
else value = "string";
```

Is there a workaround for this that maintains a similar 
syntactic structure?
is this behaviour accepted or should the compiler translate the 
first case in the second?


You could make a Choose function:

auto Ch(A,B)(bool c, A a, B b);

Then

value = Ch(n == 2, n, "string");

Not much different than

value = (n == 2) ? Alg(2) : Alg("string");

except you don't have to write Alg all the time.

The compiler should translate the first but that requires 
implicit conversion of any of the types T... to Algebraic!T... . 
Of course, that should be possible but is it?











Re: Another Tuesday (Friday?), Another GtkDcoding Blog Post

2019-03-21 Thread Michelle Long via Digitalmars-d-learn

On Tuesday, 12 March 2019 at 14:44:59 UTC, Ron Tarrant wrote:
It was suggested that I do all these posts in one thread, so 
this is the thread where that'll happen. With that said...


It's Tuesday! (and that used to be a Theatresports game when 
Keith Johnstone still ran things)


OR...

It's Friday!

And that (the Tuesday OR Friday part) means it's time for 
another post on the gtkDcoding blog. Here it is: 
http://gtkdcoding.com/2019/03/12/0017-change-pointer.html


Today's topic: Changing the mouse pointer

You'll be thrilled by the heart-shaped point and tickled by the 
Gumby. Man, this stuff is exciting!


Sign up for RSS or follow on Facebook or drop me some email.

Anyway. 'Nuff said.


I'd suggest adding pictures! It's very easy to take a screen shot 
and not much harder to link them and they offer far more interest.




Re: gtkD: How to paint to screen for animation

2019-03-21 Thread Michelle Long via Digitalmars-d-learn

On Tuesday, 19 March 2019 at 15:33:19 UTC, Ron Tarrant wrote:

On Tuesday, 19 March 2019 at 00:54:34 UTC, Michelle Long wrote:
I've added a function to addOnDraw for a DrawingArea and it 
paints using the code I have when I resize.


I added a queueDraw in threadsAddIdle and it seems to draws 
the screen immediately but it does not seem to be called again.


If I put queueDraw inside the addOnDraw routine then the 
animation works but it is quite slow, about 1 fps and cpu 
usage is 100% without it, it is 0%.


I haven't dug into this stuff yet for my blog, but I have 
sourced some references. Here's one that may help:


https://www.cairographics.org/threaded_animation_with_cairo/


Not really what I'm after(maybe later).  Seems the code was 
running quite fast but I thought it should have displayed the 
results faster


Re: gtkD: How to paint to screen for animation

2019-03-21 Thread Michelle Long via Digitalmars-d-learn

On Tuesday, 19 March 2019 at 19:03:37 UTC, Mike Wey wrote:

On 19-03-2019 01:54, Michelle Long wrote:
I've added a function to addOnDraw for a DrawingArea and it 
paints using the code I have when I resize.


I added a queueDraw in threadsAddIdle and it seems to draws 
the screen immediately but it does not seem to be called again.


If I put queueDraw inside the addOnDraw routine then the 
animation works but it is quite slow, about 1 fps and cpu 
usage is 100% without it, it is 0%.


You will probably want to use glib.Timeout to make the time 
between redraws consistent.
The callBack for treadsAddIdle or glib.Idle is only called when 
the mainloop has nothing else to do.


The cairo clock demo is a good example: 
https://github.com/gtkd-developers/GtkD/blob/master/demos/cairo/cairo_clock/clock.d


If performance is an issue one option would be to save your 
context in a cairo surface and only redraw the parts that have 
changed.



This seems to be not any different than calling queueDraw inside 
AddOnDraw. I did the timing code and it does seem to say that I'm 
getting max 60fps so maybe it is quite fast.


I was bitting an imagine and moving a rect across the screen at 
1px per frame. I though it should be moving much faster but 
apparently my mental calculations are not all that great. 1680/60 
~= 28 so it should take nearly half a minute to move the rect 
from one side to the other.


The behavior was essentially identical. I'm curious if the 
drawing routine itself uses Timeout to get 60fps and adding 
another timeout is only useful to regulate a slower fps?





Re: gtkD: How to paint to screen for animation

2019-03-19 Thread Michelle Long via Digitalmars-d-learn

On Tuesday, 19 March 2019 at 19:03:37 UTC, Mike Wey wrote:

On 19-03-2019 01:54, Michelle Long wrote:
I've added a function to addOnDraw for a DrawingArea and it 
paints using the code I have when I resize.


I added a queueDraw in threadsAddIdle and it seems to draws 
the screen immediately but it does not seem to be called again.


If I put queueDraw inside the addOnDraw routine then the 
animation works but it is quite slow, about 1 fps and cpu 
usage is 100% without it, it is 0%.


You will probably want to use glib.Timeout to make the time 
between redraws consistent.
The callBack for treadsAddIdle or glib.Idle is only called when 
the mainloop has nothing else to do.


The cairo clock demo is a good example: 
https://github.com/gtkd-developers/GtkD/blob/master/demos/cairo/cairo_clock/clock.d


If performance is an issue one option would be to save your 
context in a cairo surface and only redraw the parts that have 
changed.



I will try the clock code and see if threading it will help 
though. Just not sure if it's limited by cario or the thread.


It seems that blitting the image is not the slow down because I 
removed the code and it still is slow, so it seems like it is a 
thread.



setSourcePixbuf(buf, 0,0);  
paint();

Thanks.






gtkD: How to paint to screen for animation

2019-03-18 Thread Michelle Long via Digitalmars-d-learn
I've added a function to addOnDraw for a DrawingArea and it 
paints using the code I have when I resize.


I added a queueDraw in threadsAddIdle and it seems to draws the 
screen immediately but it does not seem to be called again.


If I put queueDraw inside the addOnDraw routine then the 
animation works but it is quite slow, about 1 fps and cpu usage 
is 100% without it, it is 0%.





Re: Any easy way to extract files to memory buffer?

2019-03-18 Thread Michelle Long via Digitalmars-d-learn

On Monday, 18 March 2019 at 23:01:27 UTC, H. S. Teoh wrote:
On Mon, Mar 18, 2019 at 10:38:17PM +, Michelle Long via 
Digitalmars-d-learn wrote:
On Monday, 18 March 2019 at 21:14:05 UTC, Vladimir Panteleev 
wrote:
> On Monday, 18 March 2019 at 21:09:55 UTC, Michelle Long 
> wrote:
> > Trying to speed up extracting some files that I first have 
> > to extract using the command line to files then read those 
> > in...
> > 
> > Not sure what is taking so long. I imagine windows caches 
> > the extraction so maybe it is pointless?

[...]

Why not just use std.mmfile to memory-map the file into memory 
directly? Let the OS take care of actually paging in the file 
data.



T


The files are on disk and there is an external program that read 
them and converts them and then writes the converted files to 
disk then my program reads. Ideally the conversion program would 
take memory instead of disk files but it doesn't.





Re: Any easy way to extract files to memory buffer?

2019-03-18 Thread Michelle Long via Digitalmars-d-learn
On Monday, 18 March 2019 at 21:14:05 UTC, Vladimir Panteleev 
wrote:

On Monday, 18 March 2019 at 21:09:55 UTC, Michelle Long wrote:
Trying to speed up extracting some files that I first have to 
extract using the command line to files then read those in...


Not sure what is taking so long. I imagine windows caches the 
extraction so maybe it is pointless?


You can speed up such things using a tmpfs or RAM disk.

On Linux you just use mount -t tmpfs ...

On Windows it is a little more complicated, there are programs 
like ImDisk that can create RAM drives (which can then be 
formatted to whatever).


If it's just one file, sometimes you can pipe it from the 
unpacking program (tar etc.) into the consuming program.


Yeah, but it seems like a lot of work simply to extract the files 
to memory.


Any easy way to extract files to memory buffer?

2019-03-18 Thread Michelle Long via Digitalmars-d-learn
Trying to speed up extracting some files that I first have to 
extract using the command line to files then read those in...


Not sure what is taking so long. I imagine windows caches the 
extraction so maybe it is pointless?


Re: use dll's

2019-03-16 Thread Michelle Long via Digitalmars-d-learn

On Saturday, 16 March 2019 at 15:13:15 UTC, ontrail wrote:

On Saturday, 16 March 2019 at 14:18:07 UTC, Andre Pany wrote:

On Saturday, 16 March 2019 at 12:53:49 UTC, ontrail wrote:

hi,
i created a program (windows) and 2 dll's.
how do i use the 2 d-language dll's in a d-language program 
with only one GC?


any help is appreciated.


It is explained here (section d code calling d code in dll)

https://wiki.dlang.org/Win32_DLLs_in_D

Kind regards
Andre


well thank you kindly.
what i don't understand yet, is there a way to have the GC in 
my program only once instead of several times with the dll's.


Why do you need to do this? It might be more effective to allow 
multiple GC's.


but surely you can set the GC of the dll to use that of the 
another. You will need to expose a method to set the GC from the 
dll..


void SetGC(GC gc);

type of thing...

Where GC is info regarding the GC to do so which I don't know 
much about. The latest dmd supports hooking ones own GC so it 
might be just a matter of using those functions to point to the 
correct gc.


https://dlang.org/library/core/memory/gc.html

https://forum.dlang.org/thread/mzrxzdmhwuwjiybcb...@forum.dlang.org


Re: Switch function from runtime to compile time

2019-03-14 Thread Michelle Long via Digitalmars-d-learn

On Thursday, 14 March 2019 at 11:38:44 UTC, alex1974 wrote:
I have several geometric shapes (triangle, trapezoid, gauss, 
...) forming the membership functions of a fuzzy set.
For example the shape of the triangle is defined by the 
variables a, b and c. The function calculating membership looks 
like:


real triangle (real a, real b, real c, real value) {
  if (value <= a || value >= c) return 0.0;
  else if (value <= b) return (x-a)/(b-a);
  else return (c-x)/(c-b);
}

Intuitiv I packed this in a class:

class Triangle {
  real a,b,c;
  real getValue (real value) {
... // math as above
  }
}

My question is if this is the best practice. During the 
learning process of the fuzzy logic the shape of the triangle 
will change.
But once I found the optimal shape the triangle will be fixed 
and the program could be recompiled with the optimal shapes. 
The compiler could then perform optimization of the code at 
compile-time. Look at the term (b-a) and (c-b) which are then 
known at compile-time.
 How can I achieve this without writing duplicate code for 
runtime and compile-time?


Just store them to a file and read the file at compile time if it 
exists... quite simple.


if (exists(file)) import(file);
elseif (optimal) write(file);

If you need to retrain just remove the file or use something like 
version.






Re: dcompute - Error: unrecognized `pragma(LDC_intrinsic)

2019-02-28 Thread Michelle Long via Digitalmars-d-learn
On Thursday, 28 February 2019 at 10:37:22 UTC, Nicholas Wilson 
wrote:
On Thursday, 28 February 2019 at 09:58:35 UTC, Michelle Long 
wrote:
I've included it in Visual D as di and it seems not to add it 
to the include line...


Is it in any way possible that it being an di file would allow 
that? Seems that it is an LDC issue though but LDC has some 
usage of it I believe and it works fine.


Could it be a LDC version? Or do I need to include something 
to make it work? Seems like it would be part of the compiler 
itself.


(I'm on cold and flu meds so apologies if this doesn't make 
sense)


It should be on the atuoimport path of LDC as that file had 
others 
(https://github.com/ldc-developers/druntime/tree/ldc/src/ldc) 
are part of LDC's druntime which should be imported by ldc's 
.conf file, it won't show up on the command line unless you do 
something (... brain not working properly...).


Irrespective of all that, the error comes from

https://github.com/ldc-developers/ldc/blob/f5a5324773484447953746725ea455d2827e6004/dmd/dsymbolsem.d#L1862

which should never happen because this branch should be taken

https://github.com/ldc-developers/ldc/blob/f5a5324773484447953746725ea455d2827e6004/dmd/dsymbolsem.d#L1807

because that pragma is explicitly checked for here

https://github.com/ldc-developers/ldc/blob/187d8198e63564c633f22f2ef4db2a31a8a600ce/gen/pragma.cpp#L110




Yeah, in the config it is

// default switches appended after all explicit command-line 
switches

post-switches = [
"-I%%ldcbinarypath%%/../import",

I've hard coded it and it still doesn't find them.

I've added -conf=

and nothing...

dcompute\driver\cuda\package.d(3): Error: module `dcompute` is in 
file 'ldc\dcompute.d' which cannot be read


Of course if I manually include it then it gives more problems...

Seems ldc is not even reading the conf file or using it if it is?


If you are right then it seems you are suggesting it is an LDC 
bug... but that this is highly unlikely...


I am using Visual D and maybe it is all setup for dub and dub 
takes care of configuring something that Visual D does not?



Note that I've had to include the dcompute imports(downloaded 
from git), rt(for xmalloc I think), and derelict modules.


I did those because when I added dcompute it would complain about 
the missing modules so I had to hunt and peck to find them.



When I remove the ldc imports from Visual D,

then the error about missing ldc.dcompute is at

module dcompute.driver.cuda;
public import ldc.dcompute;

which, is in the ldc imports dir(which is why i manually included 
them which solves it then gives the intrinsics error).



In any case, it seems like it is a very strange bug since 
`pragma(LDC_intrinsic` should work fine. It's analogous to 
`pragma(msg` not working in dmd...


Are you using the latest ldc? (1.14.0?)





Re: dcompute - Error: unrecognized `pragma(LDC_intrinsic)

2019-02-28 Thread Michelle Long via Digitalmars-d-learn
On Thursday, 28 February 2019 at 11:22:49 UTC, Michelle Long 
wrote:
On Thursday, 28 February 2019 at 10:37:22 UTC, Nicholas Wilson 
wrote:

[...]




Yeah, in the config it is

[...]


Also, is it possible that intrinsics are disabled?



Re: dcompute - Error: unrecognized `pragma(LDC_intrinsic)

2019-02-28 Thread Michelle Long via Digitalmars-d-learn
On Thursday, 28 February 2019 at 02:35:59 UTC, Nicholas Wilson 
wrote:
On Wednesday, 27 February 2019 at 22:56:14 UTC, Michelle Long 
wrote:
Trying to get dcompute to work... after a bunch of issues 
dealing with all the crap this is what I can't get past:


Error: unrecognized `pragma(LDC_intrinsic)

This is actually from the ldc.intrinsics file, which I had to 
rename from .di to d so it would be included in by VisualD.


I upgraded to latest LDC just before

LDC - the LLVM D compiler (1.14.0git-1bbda74):
  based on DMD v2.084.1 and LLVM 7.0.1


pragma(LDC_intrinsic, "llvm.returnaddress")
void* llvm_returnaddress(uint level);


..\..\..\..\D\LDC\import\ldc\intrinsics.d(85): Error: 
unrecognized `pragma(LDC_intrinsic)`


I've got no idea why that is the case, although I note that you 
shouldn't need to change intrinsics.di to intrinsics.d, as a 
.di it only needs to be on the include path which should 
already be the case for LDC.


I've included it in Visual D as di and it seems not to add it to 
the include line...


Is it in any way possible that it being an di file would allow 
that? Seems that it is an LDC issue though but LDC has some usage 
of it I believe and it works fine.


Could it be a LDC version? Or do I need to include something to 
make it work? Seems like it would be part of the compiler itself.




dcompute - Error: unrecognized `pragma(LDC_intrinsic)

2019-02-27 Thread Michelle Long via Digitalmars-d-learn
Trying to get dcompute to work... after a bunch of issues dealing 
with all the crap this is what I can't get past:


Error: unrecognized `pragma(LDC_intrinsic)

This is actually from the ldc.intrinsics file, which I had to 
rename from .di to d so it would be included in by VisualD.


I upgraded to latest LDC just before

LDC - the LLVM D compiler (1.14.0git-1bbda74):
  based on DMD v2.084.1 and LLVM 7.0.1


pragma(LDC_intrinsic, "llvm.returnaddress")
void* llvm_returnaddress(uint level);


..\..\..\..\D\LDC\import\ldc\intrinsics.d(85): Error: 
unrecognized `pragma(LDC_intrinsic)`





Re: Template recursion exceeded

2019-02-26 Thread Michelle Long via Digitalmars-d-learn
On Wednesday, 27 February 2019 at 06:56:59 UTC, Nicholas Wilson 
wrote:
On Wednesday, 27 February 2019 at 05:45:19 UTC, Michelle Long 
wrote:

Basically

void foo(int k = 20)()
{
   static if (k <= 0 || k >= 100) return;
   foo!(k-1)();
}

Error		Error: template instance `foo!-280` recursive 
expansion		


Yep, that return is a dynamic return, not a static one.


   static if (k <= 0 || k >= 100) {} else:
   foo!(k-1)();


will work.


Right, I forgot ;/ At first I wasn't using a static if then threw 
it in their.










Template recursion exceeded

2019-02-26 Thread Michelle Long via Digitalmars-d-learn

Basically

void foo(int k = 20)()
{
   static if (k <= 0 || k >= 100) return;
   foo!(k-1)();
}

Error   Error: template instance `foo!-280` recursive expansion 





Re: How can we template an alias?

2019-02-26 Thread Michelle Long via Digitalmars-d-learn
On Wednesday, 27 February 2019 at 04:11:09 UTC, Michelle Long 
wrote:

doubles and ints are not upcasted properly to complex
foo(Complex!double c)

foo(3) fails

I'd like to do something like

alias CR(t) = Complex!double(t);


CR(3)

which would be equivalent to typing Complex!double(3) but much 
shorter.


Writing a wrapper is overkill.


I guess I oversimplied...

alias C = Complex!double;

then C(3) works fine.

My problem is slightly more complex but I haven't figured out how 
to reduce it.


How can we template an alias?

2019-02-26 Thread Michelle Long via Digitalmars-d-learn

doubles and ints are not upcasted properly to complex
foo(Complex!double c)

foo(3) fails

I'd like to do something like

alias CR(t) = Complex!double(t);


CR(3)

which would be equivalent to typing Complex!double(3) but much 
shorter.


Writing a wrapper is overkill.





Re: How to setup dub to use x86 and x64 dll's when appropriate?

2019-02-25 Thread Michelle Long via Digitalmars-d-learn

On Tuesday, 26 February 2019 at 04:17:04 UTC, Michelle Long wrote:
e.g., using sdl for different versions and have it 
automatically switch.


What would be nice is if one could stick all the files for x86 
in one dir and x64 in the others and they will be used 
depending on the build(and copied)


Ideally one can do it for debug and release versions too.


It seems also that dub is shit for swapping between different 
archs... I added the -m64 flag and then get build errors for lib 
format errors, compiles fine for x86...





How to setup dub to use x86 and x64 dll's when appropriate?

2019-02-25 Thread Michelle Long via Digitalmars-d-learn
e.g., using sdl for different versions and have it automatically 
switch.


What would be nice is if one could stick all the files for x86 in 
one dir and x64 in the others and they will be used depending on 
the build(and copied)


Ideally one can do it for debug and release versions too.




Fractal generators in D?

2019-02-18 Thread Michelle Long via Digitalmars-d-learn
Are their any fractal generators in D, ideally using the GPU and 
possibly supporting 3D/4D generation?




Re: All these errors running basic Pegged helloworld example.

2019-01-11 Thread Michelle Long via Digitalmars-d-learn

On Sunday, 27 September 2015 at 06:30:37 UTC, Enjoys Math wrote:

The example is:

import pegged.grammar;

mixin(grammar(`
Arithmetic:
Term < Factor (Add / Sub)*
Add  < "+" Factor
Sub  < "-" Factor
Factor   < Primary (Mul / Div)*
Mul  < "*" Primary
Div  < "/" Primary
Primary  < Parens / Neg / Pos / Number / Variable
Parens   < "(" Term ")"
Neg  < "-" Primary
Pos  < "+" Primary
Number   < ~([0-9]+)

Variable <- identifier
`));

I'm using Visual D and have C:\MyProjects\D\Pegged (the git 
clone of pegged) added to the add'l imports field under project 
properties > compiler.


I'm getting errors like these:

Error	1	Error 42: Symbol Undefined 
_D6pegged7dynamic7grammar7grammarFAyaHAyaDFS6pegged3peg9ParseTreeZS6pegged3peg9ParseTreeZS6pegged7dynamic7grammar14DynamicGrammar (pegged.dynamic.grammar.DynamicGrammar pegged.dynamic.grammar.grammar(immutable(char)[], pegged.peg.ParseTree delegate(pegged.peg.ParseTree)[immutable(char)[]]))	C:\MyProjects\D\PeggedPractice\	
Error	2	Error 42: Symbol Undefined 
_D6pegged7dynamic7grammar12__ModuleInfoZ	C:\MyProjects\D\PeggedPractice\	


The # of errors was greatly reduced when I added the 3 pegged 
source files to my project.   What can be going wrong?  Thanks!


You need to add most of the pegged files... there are more than 
3. Try adding them all first then remove the junk like the 
examples, docs, etc until it works.


signed nibble

2019-01-07 Thread Michelle Long via Digitalmars-d-learn
Is there any direct way to convert a signed nibble in to a signed 
byte with the same absolute value? Obviously I can do some bit 
comparisons but just curious if there is a very quick way.





Re: static foreach not working with this

2019-01-07 Thread Michelle Long via Digitalmars-d-learn

On Monday, 7 January 2019 at 16:29:25 UTC, Alex wrote:

On Monday, 7 January 2019 at 16:16:57 UTC, Michelle Long wrote:

On Monday, 7 January 2019 at 16:01:50 UTC, Michelle Long wrote:

static foreach(k, p; AliasSeq!(this, s))
{{
p.foo(); // Fails even if this line is removed
}}

this not known at compile time. replace s with this and it 
works! s is an argument which is also not known at compile 
time(generally).


Should work with this.

Just "simplifying"

this.foo();
s.foo();


(obviously more complex code)


static foreach(k, p; AliasSeq!(Alias!this, s))  
{{
p.foo(); // Fails even if this line is removed
}}


referring to
https://forum.dlang.org/post/aqypsijjvajybtqtm...@forum.dlang.org

Do you trying to do a recursive call from foo to itself?


foo has nothing to do with it, as I said, removing it produces 
the same error['p.foo(); // Fails even if this line is removed']. 
I only put in something in the block because some blockhead would 
say something if there was nothing there like "Why are you even 
bothering with a static for each on an empty block? are you that 
stupid that you don't realize the compiler won't emit any code?".





Re: static foreach not working with this

2019-01-07 Thread Michelle Long via Digitalmars-d-learn

On Monday, 7 January 2019 at 16:01:50 UTC, Michelle Long wrote:

static foreach(k, p; AliasSeq!(this, s))
{{
p.foo(); // Fails even if this line is removed
}}

this not known at compile time. replace s with this and it 
works! s is an argument which is also not known at compile 
time(generally).


Should work with this.

Just "simplifying"

this.foo();
s.foo();


(obviously more complex code)


static foreach(k, p; AliasSeq!(Alias!this, s))  
{{
p.foo(); // Fails even if this line is removed
}}


static foreach not working with this

2019-01-07 Thread Michelle Long via Digitalmars-d-learn

static foreach(k, p; AliasSeq!(this, s))
{{
p.foo(); // Fails even if this line is removed
}}

this not known at compile time. replace s with this and it works! 
s is an argument which is also not known at compile 
time(generally).


Should work with this.

Just "simplifying"

this.foo();
s.foo();


(obviously more complex code)




Re: static foreach direct use of variables

2019-01-01 Thread Michelle Long via Digitalmars-d-learn

On Tuesday, 1 January 2019 at 21:34:08 UTC, Paul Backus wrote:

On Tuesday, 1 January 2019 at 21:14:09 UTC, Michelle Long wrote:

auto foo(S s)
{
static foreach(k, p; [s, this])
for(int i = 0; i < p.length; i++)
...
}

The idea is to provide single for loop structure for each of 
the variables(in this case s and this).


You can do this with `std.meta.AliasSeq`:

string[] a = ["lions", "tigers", "bears"];
int[] b = [123, 456, 789];

static foreach(array; AliasSeq!(a, b)) {
foreach (item; array) {
writeln(item);
}
}


I tried that but it didn't work... I will try again.


static foreach direct use of variables

2019-01-01 Thread Michelle Long via Digitalmars-d-learn

auto foo(S s)
{
static foreach(k, p; [s, this])
for(int i = 0; i < p.length; i++)
...
}

The idea is to provide single for loop structure for each of the 
variables(in this case s and this).


The is to avoid string mixins which are pathetic for this kind of 
work.


The point is that instead of having to do

for(int i = 0; i < s.length; i++)
 ...
for(int i = 0; i < this.length; i++)
 ...

in which case ... might be very long.

Sure one can create a function and all that mess but the compiler 
should be able to do symbol replacement very naturally and easily.






Low order hashes

2019-01-01 Thread Michelle Long via Digitalmars-d-learn
I need to hash a few strings to a byte, short, or int. hashOf 
works for int only on x86.


What would be a nice way to accomplish this? Collisions are not 
good but not catastrophic. Mainly I need a unique ID to emulate 
enums. I might just chop off the extra bits or mash them up 
somehow and it will probably work but hoping for something more 
solid.




Re: class template conflict

2018-12-25 Thread Michelle Long via Digitalmars-d-learn

On Tuesday, 25 December 2018 at 18:34:04 UTC, bauss wrote:
On Monday, 24 December 2018 at 00:24:05 UTC, Michelle Long 
wrote:

More simple is : do not use the same identifier ;)


The whole point is to use the same identifier ;/


I think there is a bigger problem at stake here in terms of 
software architecture.




No, the problem is reasoning from the conclusion...


Re: class template conflict

2018-12-25 Thread Michelle Long via Digitalmars-d-learn

On Monday, 24 December 2018 at 22:55:55 UTC, Daniel Kozak wrote:
ne 23. 12. 2018 13:10 odesílatel Michelle Long via 
Digitalmars-d-learn < digitalmars-d-learn@puremagic.com> napsal:



class X
{

}

class X(int N) : X
{

}

Is there any real reason we can't do this?


Actually yes.  It would break almost all of my code.


How would it break your code?



In D you can do thing like this:
class X(int N)
{
X something; // it is same as X!N something;
}

So I do not need to write X!N everywhere inside X class template


But I am not talking about inside the template being used. The 
whole point of doing this is so that one can refer to the base 
class using the same name as the derived with a template 
parameter to make a composite structure.


X!N should be totally different than X.

The fact that you can use X inside a class to refer to X!N is a 
hack... and in any case should not effect what I'm talking about 
because it is only used in the inherited part.. which it would be 
circular to use it as it is:


class X(int N) : X
{

}

creates circular inheritance.

so for the inherited part it should never be used and you never 
use it in your code like that... so it won't break anything.


Also, as long as there is no other symbol with that name it won't 
break anything.


Suppose this did work:

class X;

class X(int N) : X // (Here X refers to the base class above
{
  // Using X can still be X!N since we can just alias the 
original X away.

}

class X;
alias XX = X;
class X(int N) : X
{
   X x; // X!N x;
   XX xx; // X = x;
}

So it would not break anything. It really has nothing to do with 
what one does inside a template but how it looks to the outside.





Re: class template conflict

2018-12-23 Thread Michelle Long via Digitalmars-d-learn

More simple is : do not use the same identifier ;)


The whole point is to use the same identifier ;/


class template conflict

2018-12-23 Thread Michelle Long via Digitalmars-d-learn

class X
{

}

class X(int N) : X
{

}

Is there any real reason we can't do this?

It is very nice to be able to treat X like the base and X!n as a 
derived class.


Sure we can do

class X(int N) : X!0
{
   static if(N == 0)
   {
   }
}

but this is very ugly, in my code I always have to use X!0 as the 
basis!


I do not think there is any harm to allow this since the 
templated class always has to specify N. It is not like we can do


class X(int N = 0) : X
{
   static if(N == 0)
   {
   }
}


Actually we can, so... I don't see the point in not allowing the 
first case, they are logically equivalent. That static if is just 
ugly and it is defining the base class inside the derived class 
which seems unnatural.






Re: Mixin operator 'if' directly

2018-12-21 Thread Michelle Long via Digitalmars-d-learn

On Saturday, 22 December 2018 at 03:44:09 UTC, Timoses wrote:
On Wednesday, 19 December 2018 at 15:40:50 UTC, Neia Neutuladh 
wrote:

On Wed, 19 Dec 2018 15:12:14 +, bauss wrote:
Or while instantiating it:

mixin template foo()
{
  int _ignoreme()
  {
if (readln.strip == "abort") throw new AbortException;
return 1;
  }
  int _alsoIgnoreMe = _ignoreme();
}
void main()
{
  mixin foo;
}


Awesome hack!
Being a hack, it would be even nicer if it worked ouf of the 
box:


mixin template foo(bool b)
{
int _impl() { writeln(b); return int.init; }
int _ipml2 = _impl();
}

vs

mixin template foo(bool b)
{
writeln(b);
}


Yep, except they will probably disable it in some way.

Surely though a template could be created that does all the work. 
Just pass an lambda in to a template.


mixin template Code(alias f)
{
int _impl2 = (() { f(); return int.init; })();
}

mixin Code!(() { writeln("Haha, we inserted code via 
declarations!");});


So now you can do

mixin template foo(bool b)
{
mixin Code!(() { writeln(b); });
}

If it could be made robust, maybe it would be effective.  One 
still can't insert arbitrary code though. So it is not as useful 
as it looks but still gets over the arbitrary restriction.




Re: Mixin operator 'if' directly

2018-12-21 Thread Michelle Long via Digitalmars-d-learn

On Thursday, 20 December 2018 at 16:23:39 UTC, H. S. Teoh wrote:
On Thu, Dec 20, 2018 at 11:04:19AM +, bauss via 
Digitalmars-d-learn wrote:
On Wednesday, 19 December 2018 at 15:40:50 UTC, Neia Neutuladh 
wrote:

[...]

> mixin template foo()
> {
>   int _ignoreme()
>   {
> if (readln.strip == "abort") throw new AbortException;
> return 1;
>   }
>   int _alsoIgnoreMe = _ignoreme();
> }
> void main()
> {
>   mixin foo;
> }

That's a genius hack.

I have to adapt this!


Me too!  This is awesome!  This basically lets you insert 
arbitrary code via mixin templates with essentially no 
restrictions!  You can even reuse the same ignore-identifiers 
in multiple instantiations of the same template, e.g.:


import std.stdio;
mixin template CodeMixin(int i)
{
int _impl()
{
static if (i == 0)
{
writeln("Haha, we inserted code via declarations!");
return int.init;
}
else static if (i == 1)
{
writeln("Well whaddya know, we can do multiple mixins!");
return int.init;
}
else static assert(0);
}
int _impl2 = _impl();
}
void main()
{
writeln("Does it respect order?");
mixin CodeMixin!0;
writeln("I should think so! But you never know...");
mixin CodeMixin!1;
	writeln("Wow, can we really do multiple mixins of this 
sort?");

}

The output is:

Does it respect order?
Haha, we inserted code via declarations!
I should think so! But you never know...
Well whaddya know, we can do multiple mixins!
Wow, can we really do multiple mixins of this sort?


T


Note that it even captures locals:

import std.stdio, std.conv;
mixin template CodeMixin(int i)
{
int _impl()
{
static if (i == 0)
{
		writeln("Haha, we inserted code via declarations! - " ~ 
to!string(x));

return int.init;
}
else static if (i == 1)
{
		writeln("Well whaddya know, we can do multiple mixins! - " 
~ to!string(x));

return int.init;
}
else static assert(0);
}
int _impl2 = _impl();
}
void main()
{
int x = 3;
writeln("Does it respect order?");
mixin CodeMixin!0;
writeln("I should think so! But you never know...");
x = 4;
mixin CodeMixin!1;
writeln("Wow, can we really do multiple mixins of this sort?");
getchar();
}


Seems like it could be used to replace a lot of string mixins so 
that real debugging could take place along with CT error 
checking, etc.







Re: Bug in shifting

2018-12-13 Thread Michelle Long via Digitalmars-d-learn
On Friday, 14 December 2018 at 02:17:20 UTC, Jonathan M Davis 
wrote:
On Thursday, December 13, 2018 6:56:33 PM MST Steven 
Schveighoffer via Digitalmars-d-learn wrote:

On 12/13/18 7:16 PM, Michelle Long wrote:
> I've noticed the compiler is not throwing up errors and 
> warnings like it used to:

>
> I thought D required breaks for cases? Seems it doesn't any 
> longer! I'm only using -g -gf -d


It doesn't require breaks for cases, it requires no 
fall-through on cases. Again, an example would help describe 
what you mean.


Well, to be more precise, it doesn't allow fallthrough when the 
case statement contains code. It will allow it when it doesn't. 
e.g.


case 0:
case 1: break;

is perfectly legal. However, when the case statement contains 
code, then yeah, some form of control statement is required to 
exit the case statement, but that's a lot more than just break. 
continue, goto, return, etc. can all be used to exit a case 
statement. Any control statement that explicitly exits the case 
statement will work. And of course, goto case can be used for 
explicit fallthrough.


- Jonathan M Davis


I thought I had code in it which is what struct me as odd. There 
is a good chance I was wrong about this though since I was adding 
a bunch of case statements and code. Given that this occurred 
with the other problem might correlate to something else. Not 
that big a yet but the first struck me as a big problem if it is 
a bug... having code that should error but passes and provides 
wrong calculations is very prone to producing major bugs in a 
program.


I don't feel like trying to reproduce them, but if they crop up 
again I'll try and catch them.





Bug in shifting

2018-12-13 Thread Michelle Long via Digitalmars-d-learn

byte x = 0xF;
ulong y = x >> 60;

Does not compute the proper value.

It seems that the shift amount is wrapped. My code is more 
complex. The code above does give an error. I am using the code 
in a template. If I change x to ulong it works as expected.


I've noticed the compiler is not throwing up errors and warnings 
like it used to:


I thought D required breaks for cases? Seems it doesn't any 
longer! I'm only using -g -gf -d



DMD64 D Compiler v2.083.0




Re: Why do ints defined in template mixins have garbage values?

2018-12-12 Thread Michelle Long via Digitalmars-d-learn

On Wednesday, 12 December 2018 at 16:33:02 UTC, H. S. Teoh wrote:
On Wed, Dec 12, 2018 at 01:35:00PM +, AlCaponeJr via 
Digitalmars-d-learn wrote:

On Tuesday, 11 December 2018 at 21:17:46 UTC, H. S. Teoh wrote:
> Whoa.  That looks like a compiler bug. File a bug here:
> ...

Genuinely asking if this is a case of lacking of unit test for 
the Compiler or this is a case that where is hard to test or 
prevent?

[...]

I think it's just a case of too many possible combinations of 
features to test that some inevitably get overlooked.  
Combinatorial explosion. But once bug reports like these are 
filed and fixed, more unittests will be added, which increase 
the surface area of tested feature combinations and (hopefully) 
reduce the likelihood of similar bugs.





Proper factorization prevents this. It may be a difficult problem 
but all it requires is to think before one leaps. People have 
already developed randomized program testing(essentially 
generates random but working programs(or non-working for error 
codes)).  Someone could setup a machine that continuously 
generates these programs and tests the compiler. Any 
discrepancies are reported and investigated.




Re: Is this a bug? +goto

2018-11-08 Thread Michelle Long via Digitalmars-d-learn
On Thursday, 8 November 2018 at 10:31:31 UTC, Jonathan M Davis 
wrote:
On Thursday, November 8, 2018 2:34:34 AM MST Michelle Long via 
Digitalmars- d-learn wrote:
Obviously, but that is not the case I mentioned. You can 
assume that I know how scopes work. No need to assume everyone 
that shows two cases that you have to bring up an unrelated 
case as a potential cause unless it is relevant.


Remember, I'm showing the starting case that has the bug and 
the final case that doesn't... it is simply "mental dustmite" 
on the code I have.


You shouldn't assume everyone can't comprehend such 
trivialities.


If a person cannot understand scope then I doubt they 
understand goto's... and definitely not that adding braces 
should not change the compiler behavior.


What happens when you do that you just create noise that makes 
it more difficult to have a proper discussion that gets at the 
whole point of the conversation.


You seem to default to assuming that the person you are 
talking to has no clue about the problem at hand. You might 
not do it intentionally but it is wrong to assume that because 
it almost never helps.


If you fully understood the situation, you wouldn't be asking 
whether your case was a compiler bug or not, and I don't know 
which parts you do and don't understand. So, I tried to be 
thorough in explaining the situation. And yes, by being 
thorough, I'm more likely to cover information that you already 
know and understand, but I'm also more likely to cover the 
information that you actually need. In order to avoid repeating 
anything you already understand and only tell you exactly what 
you need to know, I would have to somehow understand exactly 
which piece of the puzzle it is you're missing, and I don't.




Nope, you are simply wrong here. You have a need to try to show 
that you know these trivial difference rather than, as you claim, 
to show that they exist because the other party doesn't know them.


To say that anyone posting a problem doesn't fully understand the 
situation simply because they don't know it is a compiler bug is 
either a very arrogant and blatant egotism at work in your 
mind(if you really believe what you said is true) or you are just 
ignorant of the facts.


I mean, obviously I don't fully understand the situation, but 
neither do you... so for you to claim that the poser must not 
fully understand you are implying that you do, which you don't.


See, you will say the person asking must be ignorant(not fully 
understand) of some facts about the problem.


Obviously! Everyone is, Even Walter does not have all the D code 
memorized. So, in a theoretical sense... but in that same sense 
neither do you. But you are asserting that you actually do know 
since you then make the claim that you can solve this "ignorance" 
problem because you do fully know everything.


You are conflating theoretical and factual.

You actually have no idea how much I know. You make the very 
arrogant(even if you don't see it that way) assumption that you 
know more about it...


And guess what? We haven't even defined what "it" is completely. 
So you simply choose to consistently make decisions based on your 
ego rather than what is factual and provable.


Everything is probabilistic and you mind and it's bias towards 
stroking your own ego adjusts the probabilities to do this rather 
than just taking them as very week approximations(that will 
become more accurate over time by asking questions).


The fact is, it is kinda pointless, you will continue to approach 
"helping" people with the same method. I'm trying to tell you 
that is the wrong approach(maybe it is better than nothing, but 
you basically make a shit load of assumptions about things and 
generally are wrong and the most important ones) I've noticed 
from the past that you tend to ignore all suggestions that you do 
this rather than realizing you do and try to be aware and correct 
them. This means you do not care about growing or are just 
ignorant of reality.


I'm not saying you are evil or stupid but that you can learn to 
be a better "helper" by actually trying to help people rather 
than be "Mr. KnowItAll"(not, again, saying you are blatant about 
it but you seem to go down the path of having to bring up trivial 
and basically irrelevant things to point them out. It could be 
that you have a little bit of the Captain Obvious DNA or 
whatever).


I'm only ranting about this so that maybe you can learn how to 
have a fully productive communication with someone when providing 
them help rather than waste time. See, even if you were a perfect 
programmer and knew everything about D it doesn't mean you have 
any idea how to communicate with other human beings in solving 
problems with D.


Sometimes the answer is a simple "yes" or "no"(0) and sometimes 
it is a "thesis"(1). Knowing how much to spin it is what is key, 
and yo

Re: Is this a bug? +goto

2018-11-08 Thread Michelle Long via Digitalmars-d-learn
On Thursday, 8 November 2018 at 06:56:14 UTC, Jonathan M Davis 
wrote:
On Wednesday, November 7, 2018 10:50:29 PM MST Michelle Long 
via Digitalmars-d-learn wrote:

On Thursday, 8 November 2018 at 02:22:42 UTC, Jonathan M Davis

wrote:
> On Wednesday, November 7, 2018 1:03:47 PM MST Michelle Long 
> via

>
> Digitalmars- d-learn wrote:
>> Don't let their psychobabble fool you. They are wrong and 
>> you were right from the start.

>
> ...
>
>> Case A:
>> {
>>
>> if (true) goto X;
>> int x;
>>
>> }
>> X:
>>
>>
>> Case B:
>> {
>>
>> if (true) goto X;
>> {
>>
>>int x;
>>
>> }
>>
>> }
>> X:
>>
>>
>> These two cases are EXACTLY the same semantically. It's like
>> writing A + B and (A + B).
>
> That's not the situation that the OP was describing. If 
> adding braces in a situation where the braces have no 
> semantic effect has any impact on goto, then it's a compiler 
> bug. It's adding a new scope that affects the lifetime of a 
> variable whose declaration is being jumped over by a goto 
> that matters.

>
> I know that you're frustrated, because you've hit a problem 
> with goto in complex code, and you don't have a simple 
> example that shows the compiler bug, but the approach that D 
> takes with goto (and any construct that potentially requires 
> code flow analysis) of avoiding requiring that the compiler 
> be smart is precisely to reduce the risk of there being 
> cases where the compiler is going to screw it up in complex 
> code even though it gets it right in the simple cases. If 
> the language required the compiler to be smart about such 
> things, we'd have a lot more problems with subtle, hard to 
> track down compiler bugs in complex code. So, we'd just have 
> _more_ cases where people would be hitting frustrating bugs 
> like you are.


That's fine. The D compiler writers can decide to do whatever 
they want. I can simply take my "business" elsewhere if I 
don't like it.


What I am talking about is about an obvious error(Ok, I 
haven't produced a simplified test case but dustmite or visual 
D is not working for me to do so at this point in time, but it 
would be nice for sake of argument to assume I'm right...).


> Regardless, if you want to actually have your problem fixed, 
> you're going to need to provide a reproducible test case in 
> a bugzilla report, even if it's large, otherwise no one is 
> going to be able to track it down for you.


That's easier said than done. I wasn't expecting anyone to be 
able to fix a bug that can't be reproduced.


What I expect is that, given my assumptions that I'm right, 
that people can agree the compiler does have a bug or flaw 
that can easily be fixed give then two simplified test cases 
basic purely what I have done in my own code.


1.

foreach(...)
{
   if (x) goto Y:
   int z;
}
Y:

Fails.

foreach(...)
{
   if (x) goto Y:
   {
  int z;
   }
}
Y:

Passes.

THAT IS FACT! It doesn't matter if the examples work above. I 
have simplified what I have done and in my code I simply add 
brackets and it works! That is what people should be thinking 
about... not test cases, MWE's, compiler versions, etc.


Is it logical that the compiler **should** error out in the 
first case and no in the second?


That is what the discussion is ALL about. Once that is dealt 
with then we can move on to finding out more specifics. There 
is no reason to build the windows of a house before the 
foundation, it's just far more work without any benefit.



Once people can say: If that is all you are doing is adding 
brackets around what follows the goto and break out of 
scope(which is what the code above says) and you can compile, 
then it is a compiler bug or flaw.


Once people verify that, rather than trying to create rabbit 
holes, then I can do more work on finding out more specifics. 
Until then, it is pointless to do anything on my side because 
if people come back and say "No, it is suppose to work that 
way" then what the hell am I trying to simplify and fix? It's 
not a bug then.


If you have code where you get a compiler error about a goto 
skipping the initializiation of a variable, and you add braces 
that should have no semantic effect on the code whatsoever, and 
the error goes away, then yes, that's a compiler bug. If, 
however, the braces do affect the semantics of the code, then 
that's not necessarily a compiler bug. At that point, whether 
it's a compiler bug or not would depend on what exactly the 
code was.


In an example such as

while(1)
{
if(cond)
goto label;
int x;
}
label:

adding braces such as

while(1)
{
if(cond)
{
goto label;
}
int x;
}
label:

or

while(1)
{
if(cond)
goto 

Re: Is this a bug? +goto

2018-11-07 Thread Michelle Long via Digitalmars-d-learn
On Thursday, 8 November 2018 at 02:22:42 UTC, Jonathan M Davis 
wrote:
On Wednesday, November 7, 2018 1:03:47 PM MST Michelle Long via 
Digitalmars- d-learn wrote:
Don't let their psychobabble fool you. They are wrong and you 
were right from the start.


...


Case A:
{
if (true) goto X;
int x;
}
X:


Case B:
{
if (true) goto X;
{
   int x;
}
}
X:


These two cases are EXACTLY the same semantically. It's like
writing A + B and (A + B).


That's not the situation that the OP was describing. If adding 
braces in a situation where the braces have no semantic effect 
has any impact on goto, then it's a compiler bug. It's adding a 
new scope that affects the lifetime of a variable whose 
declaration is being jumped over by a goto that matters.


I know that you're frustrated, because you've hit a problem 
with goto in complex code, and you don't have a simple example 
that shows the compiler bug, but the approach that D takes with 
goto (and any construct that potentially requires code flow 
analysis) of avoiding requiring that the compiler be smart is 
precisely to reduce the risk of there being cases where the 
compiler is going to screw it up in complex code even though it 
gets it right in the simple cases. If the language required the 
compiler to be smart about such things, we'd have a lot more 
problems with subtle, hard to track down compiler bugs in 
complex code. So, we'd just have _more_ cases where people 
would be hitting frustrating bugs like you are.


That's fine. The D compiler writers can decide to do whatever 
they want. I can simply take my "business" elsewhere if I don't 
like it.


What I am talking about is about an obvious error(Ok, I haven't 
produced a simplified test case but dustmite or visual D is not 
working for me to do so at this point in time, but it would be 
nice for sake of argument to assume I'm right...).


Regardless, if you want to actually have your problem fixed, 
you're going to need to provide a reproducible test case in a 
bugzilla report, even if it's large, otherwise no one is going 
to be able to track it down for you.


That's easier said than done. I wasn't expecting anyone to be 
able to fix a bug that can't be reproduced.


What I expect is that, given my assumptions that I'm right, that 
people can agree the compiler does have a bug or flaw that can 
easily be fixed give then two simplified test cases basic purely 
what I have done in my own code.


1.

foreach(...)
{
  if (x) goto Y:
  int z;
}
Y:

Fails.

foreach(...)
{
  if (x) goto Y:
  {
 int z;
  }
}
Y:

Passes.

THAT IS FACT! It doesn't matter if the examples work above. I 
have simplified what I have done and in my code I simply add 
brackets and it works! That is what people should be thinking 
about... not test cases, MWE's, compiler versions, etc.


Is it logical that the compiler **should** error out in the first 
case and no in the second?


That is what the discussion is ALL about. Once that is dealt with 
then we can move on to finding out more specifics. There is no 
reason to build the windows of a house before the foundation, 
it's just far more work without any benefit.



Once people can say: If that is all you are doing is adding 
brackets around what follows the goto and break out of 
scope(which is what the code above says) and you can compile, 
then it is a compiler bug or flaw.


Once people verify that, rather than trying to create rabbit 
holes, then I can do more work on finding out more specifics. 
Until then, it is pointless to do anything on my side because if 
people come back and say "No, it is suppose to work that way" 
then what the hell am I trying to simplify and fix? It's not a 
bug then.



But what it seems is that people cannot reason about the purely 
theoretical underpinnings of the problem and need proof that 
there is even a problem in the first place, as if I'm making it 
up and then they create all kinds of obfuscation that doesn't 
help anyone.


If you can agree that removing the brackets in the two test cases 
should work in ALL regular cases then I can attempt to provide 
more information.


Again, until then, it is pointless. I could waste 10 hours trying 
to track the issue down to provide a test case and you can just 
come back and say "Oh, no, that is not a bug, it's suppose to be 
that way. We will not change anything". I know from previous 
history that is the typical mentality.


Until We can agree that it is a bug, it is pointless for me to 
treat it as a bug.




Now, a goto-related regression has recently been reported for 
joiner:


https://issues.dlang.org/show_bug.cgi?id=19213

where some code worked with joiner in 2.081.2 but does not work 
with 2.082.0 or later, so you may want to test your code with 
an older compiler release to see if you've hit a compiler 
regression. If so, that could be a starting point for tracking 
down the problem.




Until I can simplify th

Re: Is this a bug? +goto

2018-11-07 Thread Michelle Long via Digitalmars-d-learn

On Tuesday, 6 November 2018 at 13:53:41 UTC, MatheusBN wrote:
On Tuesday, 6 November 2018 at 05:46:40 UTC, Jonathan M Davis 
wrote:
On Monday, November 5, 2018 7:55:46 PM MST MatheusBN via 
Digitalmars-d-learn wrote:

On Tuesday, 6 November 2018 at 01:55:04 UTC, Jonathan M Davis

wrote:
>> And I found a bit strange that in such code, since "x" is 
>> never used, why it isn't skipped.

>
> It's skipped right over. The goto jumps out of the scope, 
> and the line with

>
> int x;
>
> is never run. In fact, if you compile with -w or -wi, the 
> compiler will give you a warning about unreachable code.


That is exactly my point.

Since "x" it's skipped and never used, it shouldn't just be a 
warning (unreachable code) instead of an error?


I'm trying to understand why/when such code could give any 
problem.


On the other hand if the code were:

{
goto Q:
int x;

Q:
x = 10; // <- Now you are accessing an uninitialized 
variable.

}

Then I think an error would be ok.


D tries to _very_ little with code flow analysis, because once 
you start having to do much with it, odds are that the 
compiler implementation is going to get it wrong. As such, any 
feature that involves code flow analysis in D tends to be 
_very_ simple. So, D avoids the issue here by saying that you 
cannot skip the initialization of a variable with goto. The 
compiler is not going to do the complicated logic of keeping 
track of where you access the variable in relation to the 
goto. That's exactly the sort of thing that might be obvious 
in the simple case but is highly likely to be buggy in more 
complex code. Code such as


{
goto Q;
int x;
}
Q:

or

{
if(foo)
goto Q;
int x;
}
Q:


is fine, because the compiler can trivially see that it is 
impossible for x to be used after it's been skipped, whereas 
with something like


goto Q;
int x;
Q:

the compiler has to do much more complicated analysis of what 
the code is doing in order to determine that, and when the 
code isn't trivial, that can get _really_ complicated.


You could argue that it would be nicer if the language 
required that the compiler be smarter about it, but by having 
the compiler be stupid, it reduces the risk of compiler bugs, 
and most people would consider code doing much with gotos like 
this to be poor code anyway. Most of the cases where goto is 
reasonable tend to be using goto from inside braces already, 
because it tends to be used as a way to more efficiently exit 
deeply nested code. And with D's labeled break and continue, 
the need for using goto outside of switch statements also 
tends to be lower than it is in C/C++.


- Jonathan M Davis


It's clear now about this decision and by the way thanks for 
replying all my doubts.


MatheusBN.


Don't let their psychobabble fool you. They are wrong and you 
were right from the start.


There is no initialization of the variable, or, if there 
is(because it's "on the tack, which is "initialized" at the start 
of the function"), the variable is still never used and that is 
the whole problem.


What you will find with some of these guys is they start with the 
assumption that everything D does is correct then they try to 
disprove anything that goes against it by coming up with reasons 
that explain why D does it the way it does. It is circular 
reasoning and invalid. Each step they come up with some new 
explanation when you pick holes in their previous ones.


Eventually it's either "It's because D is not designed to do 
that" or "write an enhancement yourself" type of answer.



The fact is simple: Who ever implemented the goto statement did 
not create code to handle this case and chose the easiest route 
which is to error out. This was either oversight or "laziness".


It's really simple as that. Not once has anyone proven that the 
semantics are illogical, which is what it would require for the 
compiler to be absolutely correct in it's error.



In this case, they are simple wrong because it requires no flow 
analysis or any complex logic to determine. It's not because C is 
stupid and is unsafe, it's unreachable, etc...



The compiler simply knows what line and scope a variable is 
initialized on(since it can determine if a variable is used for 
initialization, which is a logic error) and it simply has to 
determine if the goto escapes the scope before using any 
initialized variable.


It can do this easily but the logic was not added.

Case A:
{
   if (true) goto X;
   int x;
}
X:


Case B:
{
   if (true) goto X;
   {
  int x;
   }
}
X:


These two cases are EXACTLY the same semantically. It's like 
writing A + B and (A + B).


What the extra scope does though is create a new scope in the 
compiler AST and this separates the goto logic, which is properly 
implemented to handle that case.


The fact that one produces one error and the other is valid 
proves that the compiler is incomplete. Adding scopes does not 
change semantics no different than adding 

Re: Where do I learn to use GtkD

2018-10-30 Thread Michelle Long via Digitalmars-d-learn

On Sunday, 13 March 2016 at 19:28:57 UTC, karabuta wrote:
Gtk3 from python3 has got I nice book with examples that are 
not so advanced but enough to get you doing real work(from a 
beginner point of view). GtkD seem to have changed the API 
structure compared to python3 Gtk3 and the demo examples just 
"show-off" IMO :). The documentation is really^ not good :)


Any help on where I can get better leaning materials(GtkD)? 
Repo, blogs post, etc please


I will avoid using GTK for large projects. If can be used for 
simple things and you can automate a lot of acts(and use glade 
for UI design)... but it has some problems that will bite you in 
the long run.


I'd just jump in to it, it's not too hard but hard to find the 
correct information. It will be a time investment of a few months.


Might try nuklearD first. Seems to be better in many aspects.


Re: Pegged: spaces

2018-10-27 Thread Michelle Long via Digitalmars-d-learn

On Friday, 26 October 2018 at 07:36:50 UTC, drug wrote:

25.10.2018 23:34, Michelle Long пишет:

Ignores spaces: <-

Doesn't: <

Concatenates results: <~



Thank you for sharing your results!


I got it backwards when posting:

/*
	<  (space arrow) consume spaces before, between and after 
elements

<-
	<~ (squiggly arrow) concatenates the captures on the right-hand 
side of the arrow.
	<: (colon arrow) drops the entire rule result (useful to ignore 
comments, for example)
	<^ (keep arrow) that calls the 'keep' operator to all 
subelements in a rule.
	/   binary operator - conditional or (Matches first rule, if 
fails then matches the next)
	|	binary operator - Longest match alternation(matches the 
longest rule first)

:   Prefix that ignores match in rule but requires it to be valid.
*/

List is not complete, maybe I will update.

What would be really cool if one could have an autogrammar 
generator! Somehow it looks at text and figures out the grammar. 
Might require some human interaction but can figure out the rules 
that will generate the specific grammars. Maybe neural net could 
do it? Train it enough and it could be fairly accurate and a 
human just has to fix up small cases.


e.g., get a few million lines of C++ source code, pass in to the 
generator and it pops out a grammar for it! Should be possible 
since it's usually 1 to 1(for peg grammars at least).






Re: Pegged: spaces

2018-10-25 Thread Michelle Long via Digitalmars-d-learn

Ignores spaces: <-

Doesn't: <

Concatenates results: <~




Pegged: spaces

2018-10-25 Thread Michelle Long via Digitalmars-d-learn

Is Pegged suppose to consume white spaces automatically?

I have some text like "abvdfs dfddf"

and I have made some rules to divide the two parts by a space.

The sub-rules are complex but none of them contain a space(' ', 
they do contain spaces to separate the sub-rules).


The parser though is essentially ignore the space.

Sometimes it seems to work on certain rule construction and then 
other times it doesn't.


Basically none of my sub-rules have any space and the main rule is

A ' '+ B

Where A attempts to parse the first half and B the second half.

But A consumes the whole string!

A does not consume any spaces though! (no . usage or ' ' in the 
rule definitions that A uses)



I'd be able to limit the application of the rule to a substring 
that sort of emulates splitting of the string.


(!' ':A) ' '+ B

hypothetically would parse each char for A but terminate the rule 
when it encounters a space before A get to see the space. Is this 
possible with pegged?


It's sort of a look ahead but it has to do it for each character 
rather than (!' ' A) which would only check the first character 
then continue on with A.