Re: std.string.format call from varyargs

2017-07-02 Thread H. S. Teoh via Digitalmars-d-learn
On Sun, Jul 02, 2017 at 12:49:30AM +, LeqxLeqx via Digitalmars-d-learn 
wrote:
> Hello!
> 
> How does one go about invoking a templated-variatic function such as
> std.string.format with an array of objects?
> 
> For example:
> 
> string stringMyThing (string formatForMyThings, MyThing[] myThings)
> {
>   return format(
> formatForMyThings,
> myThings
> );
> }
> 
> 
> 
> In executing the above, the 'format' method always interprets the
> entire array 'myThings' as the first argument to the format, and no
> arguments afterwards, resulting in 'orphaned' format specifiers if the
> array is longer than a single element. Even if the array is only a
> single element, the formatter will wrap the result of the element's
> 'toString()' method with '[' and ']'
> 
> I really don't want to write my own format parser.
> Any help would be much appreciated!
[...]

Take a look at the docs that describe the "%(...%)" nested format
specifiers.  For example:

int[] arr = [ 1, 2, 3 ];
writefln("%(%s | %)", arr);

Output:

1 | 2 | 3

Explanation: %(...%) means a nested format specifier, where the stuff
enclosed between %( and %) are applied to each array element (actually,
range element -- it works for arbitrary input ranges). In this case, the
stuff in between is "%s | ", which is treated as "%s" followed by the
delimiter " | ". So each array element is formatted with %s, and " | "
is inserted as a delimiter.

A slightly more interesting example:

int[] arr = [ 1, 2, 3 ];
writefln("%(<%s>%|, %)", arr);

Output:

<1>, <2>, <3>

Explanation: the stuff between %( and %) is "<%s>%|, ", which is
understood as applying "<%s>" to each array element, and treating ", "
as the delimiter. The "%|" separates the per-element component from the
delimiter; this distinction is important because we want the ">" to
appear after every element including the last one, but we don't want the
", " to appear after the last element.

You can also nest %(...%) to handle multidimensional arrays. Here's my
favorite example:

auto m = [ [ 1, 2, 3 ], [ 4, 5, 6 ], [ 7, 8, 9 ] ];
writefln("%([ %(%s, %) ]%|\n%)", m);

Output:

[ 1, 2, 3 ]
[ 4, 5, 6 ]
[ 7, 8, 9 ]

Hope this helps!


T

-- 
Tech-savvy: euphemism for nerdy.


Re: weird error message

2017-07-02 Thread drug via Digitalmars-d-learn

02.07.2017 04:06, Ali Çehreli пишет:

On 07/01/2017 04:56 PM, crimaniak wrote:

 > about very long error messages generated in some
 > cases.

Please submit a bug report. The compiler may be able to abbreviate 
certain types. For example, in this case most of the error message text 
is values of a static array elements.


Ali

I had error messages 256K+ length in case of complex templates. That's 
was really annoying but I've managed)


Re: std.string.format call from varyargs

2017-07-02 Thread drug via Digitalmars-d-learn

02.07.2017 09:52, H. S. Teoh via Digitalmars-d-learn пишет:

On Sun, Jul 02, 2017 at 12:49:30AM +, LeqxLeqx via Digitalmars-d-learn 
wrote:

Hello!

How does one go about invoking a templated-variatic function such as
std.string.format with an array of objects?

For example:

string stringMyThing (string formatForMyThings, MyThing[] myThings)
{
   return format(
 formatForMyThings,
 myThings
 );
}



In executing the above, the 'format' method always interprets the
entire array 'myThings' as the first argument to the format, and no
arguments afterwards, resulting in 'orphaned' format specifiers if the
array is longer than a single element. Even if the array is only a
single element, the formatter will wrap the result of the element's
'toString()' method with '[' and ']'

I really don't want to write my own format parser.
Any help would be much appreciated!

[...]

Take a look at the docs that describe the "%(...%)" nested format
specifiers.  For example:

int[] arr = [ 1, 2, 3 ];
writefln("%(%s | %)", arr);

Output:

1 | 2 | 3

Explanation: %(...%) means a nested format specifier, where the stuff
enclosed between %( and %) are applied to each array element (actually,
range element -- it works for arbitrary input ranges). In this case, the
stuff in between is "%s | ", which is treated as "%s" followed by the
delimiter " | ". So each array element is formatted with %s, and " | "
is inserted as a delimiter.

A slightly more interesting example:

int[] arr = [ 1, 2, 3 ];
writefln("%(<%s>%|, %)", arr);

Output:

<1>, <2>, <3>

Explanation: the stuff between %( and %) is "<%s>%|, ", which is
understood as applying "<%s>" to each array element, and treating ", "
as the delimiter. The "%|" separates the per-element component from the
delimiter; this distinction is important because we want the ">" to
appear after every element including the last one, but we don't want the
", " to appear after the last element.

You can also nest %(...%) to handle multidimensional arrays. Here's my
favorite example:

auto m = [ [ 1, 2, 3 ], [ 4, 5, 6 ], [ 7, 8, 9 ] ];
writefln("%([ %(%s, %) ]%|\n%)", m);

Output:

[ 1, 2, 3 ]
[ 4, 5, 6 ]
[ 7, 8, 9 ]

Hope this helps!


T


Cool! Is it D only or could be used in printf (C/C++)?


strange static assert failure

2017-07-02 Thread Basile B. via Digitalmars-d-learn
I played with some strange stuff that are allowed, i.e "super" 
and "this" as BasicType, when I've reached this:


class B
{
super ringuard(){return null;}
void foo()
{
auto crate = ringuard();
pragma(msg, typeof(crate));
static assert(typeof(crate).stringof == Object.stringof);
static assert(is(crate == Object));
}
}

The second assert fails. Do you know why ?


Re: D and .lib files. C++/Other?

2017-07-02 Thread Jacob Carlborg via Digitalmars-d-learn

On 2017-07-01 21:11, Damien Gibson wrote:


As well I only intended to use shared libraries not static ones...


Well, you can use shared libraries in two different way, dynamic linking 
or dynamic loading.


Dynamic linking is when you declare your external symbols as usual and 
you link with the shared library at build time.


Dynamic loading is when you declared your external symbols as function 
pointer and you don't link with the shared libraries at build time. You 
then use "dlopen" and the family of functions on Posix and "LoadLibrary" 
on Windows to load the shared library at runtime.


When using dynamic linking on Posix you link directly with the shared 
library. When using dynamic linking on Windows you don't link directly 
with the shared library but instead link with an import library, which 
is basically a static library (as far as I understand). I would assume 
that this import library has the same problem as any other static library.


When using dynamic loading you don't have to worry about these different 
formats at all.


You can read more about static linking vs dynamic linking vs dynamic 
loading and about the problems with the different formats in the dlang 
blog [1] and here [2].


[1] http://dlang.org/blog/2017/06/26/project-highlight-derelict/
[2] http://derelictorg.github.io/bindings/

--
/Jacob Carlborg


Re: strange static assert failure

2017-07-02 Thread Basile B. via Digitalmars-d-learn

On Sunday, 2 July 2017 at 08:55:42 UTC, Basile B. wrote:

The second assert fails. Do you know why ?


pass your way, i've forgot the typeof()... everything is okay 
actually.


Re: D and .lib files. C++/Other?

2017-07-02 Thread Damien Gibson via Digitalmars-d-learn
Ahh, you need to initialise the D runtime before you call any 
functions that depend on it (e.g. ones that interact with the 
file system).


declare
extern "C" int rt_init();
in your c++ code and call it before ConsoleWrite and it should 
work.


Honestly i did try this and it didnt correct the problem... 
HOWEVER... I had been deleting the dll page VS and Xamarin always 
generate with a shared dll project as since i got dlls working 
with D in the first place(I was slow to figure it out) it worked 
just fine without the dllmain page they generated...


Placing that back in there now that weve come this far corrected 
the problem-> Without the need to even write rt_init in D or C++.


Thank you both very much for the help and information you guys 
have provided this problem is finally solved!


___
IF anyone happens to come across this thread in the future and 
has the same problem i did -> Note: Probably involving the use of 
Xamarin/MonoDevelop or Visual Studio with dll creation or 
compatibility with C++ I'd be happy to create a couple of sample 
projects and list the stuff it required me to install for it all 
to work.


I'm not going to do that at this moment as since I had to ask it 
seems i MAY be the only moron who seemed to have this issue? 
Anyway Bye everyone!


std.json cannot read an array floats back from file

2017-07-02 Thread Yuri via Digitalmars-d-learn

Hi there,

consider the following simple use case:

  import std.json;
  float[] floats = [1,2,3];
  JSONValue j = "{}".parseJSON;
  j.object["floats"] = floats;
  std.file.write("test.json", j.toString);
  JSONValue jj = readText("test.json").parseJSON;
  jj.object["floats"].array[1].floating.writeln;

It is expected to print '2' in the console, however an exception 
is thrown:


std.json.JSONException@/build/ldc-I3nwWj/ldc-0.17.1/runtime/phobos/std/json.d(235):
 JSONValue is not a floating type

while the below works fine:

  import std.json;
  float[] floats = [1,2,3];
  JSONValue j = "{}".parseJSON;
  j.object["floats"] = floats;
  j.object["floats"].array[1].floating.writeln;

any pointers to what could be going wrong?


Re: std.json cannot read an array floats back from file

2017-07-02 Thread Adam D. Ruppe via Digitalmars-d-learn

On Sunday, 2 July 2017 at 21:07:40 UTC, Yuri wrote:
It is expected to print '2' in the console, however an 
exception is thrown:


std.json.JSONException@/build/ldc-I3nwWj/ldc-0.17.1/runtime/phobos/std/json.d(235):
 JSONValue is not a floating type



I think it just read the json string of "1" as being an integer 
instead of a float, so the reader thought it was integral instead 
of floating.


It should prolly just transparently auto-convert, but it doesn't 
seem to. Try accessing the int instead and see waht happens.




Re: std.json cannot read an array floats back from file

2017-07-02 Thread ketmar via Digitalmars-d-learn

Yuri wrote:


Hi there,

consider the following simple use case:

   import std.json;
   float[] floats = [1,2,3];
   JSONValue j = "{}".parseJSON;
   j.object["floats"] = floats;
   std.file.write("test.json", j.toString);
   JSONValue jj = readText("test.json").parseJSON;
   jj.object["floats"].array[1].floating.writeln;

It is expected to print '2' in the console, however an exception is 
thrown:


std.json.JSONException@/build/ldc-I3nwWj/ldc-0.17.1/runtime/phobos/std/json.d(235): 
JSONValue is not a floating type


while the below works fine:

   import std.json;
   float[] floats = [1,2,3];
   JSONValue j = "{}".parseJSON;
   j.object["floats"] = floats;
   j.object["floats"].array[1].floating.writeln;

any pointers to what could be going wrong?


'cause what you got back is `JSON_TYPE.INTEGER`. dunno why it is there at 
all, as JSON has no "integers" per se, but it read as integer, and 
`.floating` failed type checking.


so, write your own wrapper that will convert INTEGER/UINTEGER/FLOAT to 
`double`. i think this is the best solution (if there can be "best 
solution" with std.json at all).


Re: std.string.format call from varyargs

2017-07-02 Thread H. S. Teoh via Digitalmars-d-learn
On Sun, Jul 02, 2017 at 11:38:34AM +0300, drug via Digitalmars-d-learn wrote:
> 02.07.2017 09:52, H. S. Teoh via Digitalmars-d-learn пишет:
[...]
> > Take a look at the docs that describe the "%(...%)" nested format
> > specifiers.  For example:
> > 
> > int[] arr = [ 1, 2, 3 ];
> > writefln("%(%s | %)", arr);
> > 
> > Output:
> > 
> > 1 | 2 | 3
> > 
> > Explanation: %(...%) means a nested format specifier, where the
> > stuff enclosed between %( and %) are applied to each array element
> > (actually, range element -- it works for arbitrary input ranges). In
> > this case, the stuff in between is "%s | ", which is treated as "%s"
> > followed by the delimiter " | ". So each array element is formatted
> > with %s, and " | " is inserted as a delimiter.
> > 
> > A slightly more interesting example:
> > 
> > int[] arr = [ 1, 2, 3 ];
> > writefln("%(<%s>%|, %)", arr);
> > 
> > Output:
> > 
> > <1>, <2>, <3>
> > 
> > Explanation: the stuff between %( and %) is "<%s>%|, ", which is
> > understood as applying "<%s>" to each array element, and treating ",
> > " as the delimiter. The "%|" separates the per-element component
> > from the delimiter; this distinction is important because we want
> > the ">" to appear after every element including the last one, but we
> > don't want the ", " to appear after the last element.
> > 
> > You can also nest %(...%) to handle multidimensional arrays. Here's
> > my favorite example:
> > 
> > auto m = [ [ 1, 2, 3 ], [ 4, 5, 6 ], [ 7, 8, 9 ] ];
> > writefln("%([ %(%s, %) ]%|\n%)", m);
> > 
> > Output:
> > 
> > [ 1, 2, 3 ]
> > [ 4, 5, 6 ]
> > [ 7, 8, 9 ]
> > 
> > Hope this helps!
[...]
> Cool! Is it D only or could be used in printf (C/C++)?

AFAIK, this is a D-specific extension.


T

-- 
Why do conspiracy theories always come from the same people??


Re: Bulk allocation and partial deallocation for tree data structures.

2017-07-02 Thread Filip Bystricky via Digitalmars-d-learn

Anyone?



Re: Bulk allocation and partial deallocation for tree data structures.

2017-07-02 Thread Stefan Koch via Digitalmars-d-learn

On Monday, 3 July 2017 at 02:51:49 UTC, Filip Bystricky wrote:

Anyone?


The answer is no.

Partial deallocation in an arbitrary fashion is not advisable.

And there are no standard library mechanisms for it.


Funny issue with casting double to ulong

2017-07-02 Thread Saurabh Das via Digitalmars-d-learn

Consider this snippet:

void main()
{
import std.stdio;
auto a = 6.2151;
auto b = a * 1;
auto c = cast(ulong)b;
writeln("a: ", typeof(a).stringof, " ", a);
writeln("b: ", typeof(b).stringof, " ", b);
writeln("c: ", typeof(c).stringof, " ", c);

auto x = 62151.0;
auto y = cast(ulong)x;
writeln("x: ", typeof(x).stringof, " ", x);
writeln("y: ", typeof(y).stringof, " ", y);
}

The output is:
a: double 6.2151
b: double 62151
c: ulong 62150
x: double 62151
y: ulong 62151

Why does c round off from 62151 to 62150 when casting to ulong?

Thanks,
Saurabh



Re: Funny issue with casting double to ulong

2017-07-02 Thread Basile B via Digitalmars-d-learn

On Monday, 3 July 2017 at 03:50:14 UTC, Saurabh Das wrote:

Consider this snippet:

void main()
{
import std.stdio;
auto a = 6.2151;
auto b = a * 1;
auto c = cast(ulong)b;
writeln("a: ", typeof(a).stringof, " ", a);
writeln("b: ", typeof(b).stringof, " ", b);
writeln("c: ", typeof(c).stringof, " ", c);

auto x = 62151.0;
auto y = cast(ulong)x;
writeln("x: ", typeof(x).stringof, " ", x);
writeln("y: ", typeof(y).stringof, " ", y);
}

The output is:
a: double 6.2151
b: double 62151
c: ulong 62150
x: double 62151
y: ulong 62151

Why does c round off from 62151 to 62150 when casting to ulong?

Thanks,
Saurabh


6.251 has no perfect double representation. It's real value is:

6.215099962483343551867E0

Hence when you cast to ulong after the product by 10_000, this is 
the equivalent of


trunc(62150.99962483343551867E0)

which gives 62150

CQFD ;-]


Re: Funny issue with casting double to ulong

2017-07-02 Thread Saurabh Das via Digitalmars-d-learn

On Monday, 3 July 2017 at 03:57:25 UTC, Basile B wrote:

On Monday, 3 July 2017 at 03:50:14 UTC, Saurabh Das wrote:

[...]


6.251 has no perfect double representation. It's real value is:

6.215099962483343551867E0

Hence when you cast to ulong after the product by 10_000, this 
is the equivalent of


trunc(62150.99962483343551867E0)

which gives 62150

CQFD ;-]


That explains it!

Thank you.


Re: Funny issue with casting double to ulong

2017-07-02 Thread Era Scarecrow via Digitalmars-d-learn

On Monday, 3 July 2017 at 03:57:25 UTC, Basile B wrote:

6.251 has no perfect double representation. It's real value is:


 I almost wonder if a BCD, fixed length or alternative for 
floating point should be an option... Either library, or a hook 
to change how the FPU works since doubles are suppose to do 16-18 
digits of perfect simple floatingpoint for the purposes of money 
and the like without relying on such imperfect transitions.


Re: Funny issue with casting double to ulong

2017-07-02 Thread H. S. Teoh via Digitalmars-d-learn
On Mon, Jul 03, 2017 at 05:38:56AM +, Era Scarecrow via Digitalmars-d-learn 
wrote:
> On Monday, 3 July 2017 at 03:57:25 UTC, Basile B wrote:
> > 6.251 has no perfect double representation. It's real value is:
> 
>  I almost wonder if a BCD, fixed length or alternative for floating
>  point should be an option... Either library, or a hook to change how
>  the FPU works since doubles are suppose to do 16-18 digits of perfect
>  simple floatingpoint for the purposes of money and the like without
>  relying on such imperfect transitions.

>From what I've heard, word on the street is to avoid using
floating-point for money calculations, and use fixed-point arithmetic
instead (i.e., basically ints / longs, with a built-in decimal point in
a fixed position).  Inexact representations of certain fractions of tens
like the above are one reason for this.

I don't think there's a way to change how the FPU works -- the hardware
is coded that way and can't be changed.  You'd have to build your own
library or use an existing one for this purpose.


T

-- 
Food and laptops don't mix.