std.json parsing real numbers.

[khurshid]

I just check  std.json for parsing real numbers.

import std.json;
import std.stdio: writeln;

int main()
{
auto json = parseJSON(1.24E  +1);
writeln(toJSON(json));
return 0;
}

and
output:  12.4


It's bug or normal ?

Re: std.json parsing real numbers.

[khurshid]

On Thursday, 8 August 2013 at 10:11:07 UTC, MrSmith wrote:

On Thursday, 8 August 2013 at 08:04:49 UTC, khurshid wrote:


I just check  std.json for parsing real numbers.

import std.json;
import std.stdio: writeln;

int main()
{
auto json = parseJSON(1.24E  +1);
writeln(toJSON(json));
return 0;
}

and
output:  12.4


It's bug or normal ?


Yep, because 1.24E+1 is 12.4E0


I wrote not a 1.24E+1, a 1 .24E +1  with leading 
spaces.

parseJSON bug

[khurshid]

std.json  parseJSON has a bug,

// leading whitespaces
auto json = parseJSON(1  .000);

-- should throws, but it's success parsed as `1.000` .


Khurshid...

Re: parseJSON bug

[khurshid]

On Thursday, 8 August 2013 at 12:08:00 UTC, khurshid wrote:


std.json  parseJSON has a bug,

// leading whitespaces
auto json = parseJSON(1  
.000);


-- should throws, but it's success parsed as `1.000` .


Khurshid...


Or more...

auto json = parseJSON(`{ one: 1.24E  +1
}`);//should throws.

writeln(toJSON(json)); // printed `{one:12.4}`

Re: parseJSON bug

[khurshid]

On Thursday, 8 August 2013 at 12:38:39 UTC, SteveGuo wrote:

On Thursday, 8 August 2013 at 12:08:00 UTC, khurshid wrote:


std.json  parseJSON has a bug,

// leading whitespaces
auto json = parseJSON(1  
.000);


-- should throws, but it's success parsed as `1.000` .


Khurshid...


I think bug reports should be here 
http://forum.dlang.org/group/digitalmars.D.bugs


I reported.
http://d.puremagic.com/issues/show_bug.cgi?id=10776

Needlessly large instantiation depth in std.typetuple algorithms

[khurshid]

Hi,
All.

I was create http://d.puremagic.com/issues/show_bug.cgi?id=9976 
issue, and thanks for Kenji Hara, and others most of algorithms 
were changed:


1. Filter
2. anySatisfy
3. allSatisfy
4. staticMap
5. Reverse

But, I think that following algorithms can change easily, too:
6. ReplaceAllwhich used GenericReplaseAll
7. Replace   which used GenericReplace
8. NoDuplicates
9. EraseAll which used GenericEraseAll
10. Erase   which used GenericErase
11. staticIndexOf   which used genericIndexOf


My idea was very simple--  replace head/tail principle to 
bisection principle.


What are  you think, for this idea?

Re: Needlessly large instantiation depth in std.typetuple algorithms

[khurshid]

On Friday, 14 June 2013 at 13:06:56 UTC, khurshid wrote:


But, I think that following algorithms can change easily, too:
6. ReplaceAllwhich used GenericReplaseAll
7. Replace   which used GenericReplace
8. NoDuplicates
9. EraseAll which used GenericEraseAll
10. Erase   which used GenericErase
11. staticIndexOf   which used genericIndexOf

12. MostDerived

about with statement

[khurshid]

D language have like Pascal/Delphi  with statement,  which very 
useful for writing readable code.


http://dlang.org/statement.html#WithStatement

Maybe I'm wrong, but, I never saw  where using this statement in 
phobos  source codes, what problem using this statement?


Regards,
Khurshid.

Re: about with statement

[khurshid]

On Sunday, 9 June 2013 at 11:11:47 UTC, bearophile wrote:

khurshid:

D language have like Pascal/Delphi  with statement,  which 
very useful for writing readable code.


It's a quite useful statement, especially with enumerations or 
associative array literals, to avoid repeating many times their 
name:


switch (en) with (MyEnum) {
  case foo: ...
  case bar: ...
}


It's very good example!!

And, May be, this is'not bad, too :))

struct C
{
   alias byte  B;
   alias short S;
};

with(C)
{
   B b;
   S s;
}

hello world in D

[khurshid]

I just download dmd 2.063, and compile simple hello world 
program:


// hello.d
import std.stdio;
int main()
{
writeln(hello world);
return 0;
}


with -O -release -inline -noboundscheck  flags.

And size of result output file  'hello'  equal to 1004.1 Kbyte !!!
Why size is big?


I'm using  fedora 14, 32-x.


Regards,
 Khurshid.

Re: hello world in D

[khurshid]

On Friday, 31 May 2013 at 14:48:02 UTC, Adam D. Ruppe wrote:
If you use printf instead of std.stdio, you'll save about 150 
KB in the executable


import core.stdc.stdio;

void main() {
printf(hello\n);
}

$ dmd test2.d
$ ls -lh test2
-rwxr-xr-x 1 me users 287K 2013-05-31 10:40 test2
$ strip test2
$ ls -lh test2
-rwxr-xr-x 1 me users 195K 2013-05-31 10:41 test2


I was try your code, result:

-rwxrwxr-x. 1 khurshid khurshid 299K May 31 19:53 hello

i.e. 299 Kbyte.


Even, when I type  dmd -v  :
DMD32 D Compiler v2.063
Copyright (c) 1999-2012 by Digital Mars written by Walter Bright
Documentation: http://dlang.org/
-
Why copyright  2012 not a 2013?

Re: 1 matches bool, 2 matches long

[khurshid]

On Friday, 26 April 2013 at 18:22:10 UTC, Walter Bright wrote:

On 4/26/2013 6:51 AM, deadalnix wrote:
The last time I experienced that feature was with a char 
getting casted to bool
implicitly and then appended to a string, causing super weird 
behavior after

when using the resulting (corrupted) string.



void main()
{
bool b = 'c';
}

dmd -c foo
foo.d(4): Error: cannot implicitly convert expression ('c') of 
type char to bool

import std.stdio;

void main()
{
bool c0 = '\1'; //compiled OK
bool c1 = '\0'; //compiled OK

writeln(c0,' ',c1); //output: true false
}

Re: D compile time algorithms implementation

[khurshid]

I am newbie D language. Only, I am playing with meta programming.

I have a question.

Using D language futures, could to implement NoDuplicates meta 
algorithm with O(N) time, or though O(N ln(N) )?

Re: D compile time algorithms implementation

[khurshid]

And, what to you're saying about that, MostDerived implementation?
http://d.puremagic.com/issues/show_bug.cgi?id=9976

Re: D compile time algorithms implementation

[khurshid]

But,
I'm sorry, I do not have the ability to work with the code
itself, now.
I take a few other things.

Regards,
Khursid.


Oh,god !!!

Re: D compile time algorithms implementation

[khurshid]

Is this code right?


template templateAnd(Preds...)
{
  template templateAnd(T...)
  {
  static if (Preds.length == 0)
  {
  enum  templateAnd = true;
  }
  else static if (Preds.length == 1)
  {
enum  templateAnd = Instantiate!(Preds[0],T);
}
else
{
static if (Instantiate!(.templateAnd(Preds[0..$/2]),T))
{
   enum  templateAnd =
Instantiate!(.templateAnd(Preds[$/2..$]),T);
}
else
{
enum  templateAnd = false;
}
}
  }
}

here
   template Instantiate(alias P, T...)
   {
 alias Instantiate = P!(T);
   }

Re: D compile time algorithms implementation

[khurshid]

On Monday, 22 April 2013 at 15:01:26 UTC, Andrei Alexandrescu
wrote:

On 4/20/13 8:41 AM, khurshid wrote:

I wanted to say NoDuplicates ))


I'd say let's add bug reports (either for library, compiler, or 
both) for each of these instances, and post pull requests 
appropriately.


Thanks,

Andrei


Thanks for suggestion.

But,
I'm sorry, I do not have the ability to work with the code
itself, now.
I take a few other things.

Regards,
Khursid.

Re: D compile time algorithms implementation

[khurshid]

On Saturday, 20 April 2013 at 20:12:18 UTC, Walter Bright wrote:

On 4/20/2013 2:27 AM, Peter Alexander wrote:
If possible, could you file an enhancement request? It would 
also be great if

you could add your improvement as a pull request on github!

http://d.puremagic.com/issues/enter_bug.cgi?product=D
https://github.com/D-Programming-Language/phobos


Yes, please do so.


I just have create issue: 
http://d.puremagic.com/issues/show_bug.cgi?id=9976

D compile time algorithms implementation

[khurshid]

I just have read from github  std.variant, std.typetuple, etc. 
source codes.

And I have a question.
Why more linear algorithms implemented with O(N^2) ?
example: staticMap,  it doesnot compiled  more 500 arguments.
although, following version compiled for more than 32768 
arguments:


template staticMap2(alias F, T...)
{
static if (T.length == 0)
{
alias TypeTuple!() staticMap2;

}
else static if (T.length == 1)
{
alias TypeTuple!(F!(T[0])) staticMap2;
}
else
{
alias TypeTuple!( staticMap2!(F, T[0..$/2]), 
staticMap2!(F,

T[$/2..$]))  staticMap2;
}
}

Re: D compile time algorithms implementation

[khurshid]

On Saturday, 20 April 2013 at 11:07:28 UTC, Timon Gehr wrote:

On 04/20/2013 08:07 AM, khurshid wrote:
I just have read from github  std.variant, std.typetuple, etc. 
source

codes.
And I have a question.
Why more linear algorithms implemented with O(N^2) ?
example: staticMap,  it doesnot compiled  more 500 arguments.
although, following version compiled for more than 32768 
arguments:


template staticMap2(alias F, T...)
{
static if (T.length == 0)
{
alias TypeTuple!() staticMap2;

}
else static if (T.length == 1)
{
alias TypeTuple!(F!(T[0])) staticMap2;
}
else
{
alias TypeTuple!( staticMap2!(F, T[0..$/2]),
staticMap2!(F,
T[$/2..$]))  staticMap2;
}
}


FWIW I think the O(N^2) behaviour is a limitation of the 
compiler implementation (I think ropes might be a better data 
structure than arrays to back compiler tuples.)


For using only one algorithm - it's no problem.

But if we are using algorithm inside another algorithm (like 
NoDuples(..) which  inside uses EraseAll ) - compile time will 
become very slowly.

Re: D compile time algorithms implementation

[khurshid]

I wanted to  say NoDuplicates ))