Re: gtkDcoding Blog Post for 2019-03-29 - Grid
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
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
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
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
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
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
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
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
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?
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?
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?
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
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
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)
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)
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)
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)
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
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
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?
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?
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?
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?
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?
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.
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
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
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?".
static foreach not working with this
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
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
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
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
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
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
More simple is : do not use the same identifier ;) The whole point is to use the same identifier ;/
class template conflict
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
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
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
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
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?
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
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
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
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
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
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
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
Ignores spaces: <- Doesn't: < Concatenates results: <~
Pegged: spaces
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.
