Re: Deploying Vibe.d applications to OpenShift

2014-07-24 Thread Nikolay via Digitalmars-d-learn



Please let me know how you did it, because I know it's possible
with the DIY-cartridge they provide you(atleast it should be).


I tried it some time ago. It is possible but:
 - vibe.d requires a lot of memory for project compilation
 - it is hard to install additional libraries (it is not usual 
Linux distrib)




Type deduction on templated constructor.

2014-07-24 Thread francesco cattoglio via Digitalmars-d-learn

So, I have this code (also on http://dpaste.dzfl.pl/3f767b17e83c)
This Vector(T) struct is taken from gfm.math.vector.

struct Vector(T) {
T x, y, z;
this(X : T, Y : T, Z : T)(X x_, Y y_, Z z_)
{
x = x_; y = y_; z = z_; 
}
}

void main()
{
Vector!ubyte test = Vector!ubyte(1, 1, 1);  
}

It fails to compile because template 
f508.Vector!ubyte.Vector.__ctor cannot deduce function from 
argument types !()(int, int, int).
Note that if one just defines a constructor as this(T x_, T y_, T 
z_) everything works.


My question is: should this code compile? I understand that the 
literal 1 is int therefore it can screw type deduction, but I 
wonder if the compiler should be smart enough to deduce it 
correctly.


Re: Type deduction on templated constructor.

2014-07-24 Thread bearophile via Digitalmars-d-learn

francesco cattoglio:

should this code compile? I understand that the literal 1 is 
int therefore it can screw type deduction, but I wonder if 
the compiler should be smart enough to deduce it correctly.


To keep both the compiler and programmers sane, D templates don't 
perform implicit type conversions. This sometimes is not handy, 
but on the whole saves from a large number of troubles.


So you can write (D V.2.066):

Vector!ubyte(ubyte(1), ubyte(1), ubyte(1));

Or you can create a little helper function that makes that code 
more DRY.


Bye,
bearophile


Re: Type deduction on templated constructor.

2014-07-24 Thread francesco cattoglio via Digitalmars-d-learn

On Thursday, 24 July 2014 at 09:38:14 UTC, bearophile wrote:

francesco cattoglio:

should this code compile? I understand that the literal 1 is 
int therefore it can screw type deduction, but I wonder if 
the compiler should be smart enough to deduce it correctly.


To keep both the compiler and programmers sane, D templates 
don't perform implicit type conversions. This sometimes is not 
handy, but on the whole saves from a large number of troubles.


So you can write (D V.2.066):

Vector!ubyte(ubyte(1), ubyte(1), ubyte(1));

Or you can create a little helper function that makes that code 
more DRY.


Bye,
bearophile


I expected such an answer and I do understand the decisions 
behind it. Yet, you gave me a really GOOD news! Having to write 
cast(ubyte) 1 was way too much verbose for my liking, while the 
new ubyte(1) is reasonable enough.


Re: How to know whether a file's encoding is ansi or utf8?

2014-07-24 Thread Kagamin via Digitalmars-d-learn
I first try to load the file as utf8 (or some 8kb at the start of 
it) with encoding exceptions turned on, if I catch an exception, 
I reload it as ansi, otherwise I assume it's valid utf8.


Re: Deploying Vibe.d applications to OpenShift

2014-07-24 Thread Etienne via Digitalmars-d-learn

On 2014-07-24 3:45 AM, Nikolay wrote:



Please let me know how you did it, because I know it's possible
with the DIY-cartridge they provide you(atleast it should be).


I tried it some time ago. It is possible but:
  - vibe.d requires a lot of memory for project compilation
  - it is hard to install additional libraries (it is not usual Linux
distrib)



You should compile and test on a CentOS 6.3 machine first and then write 
the cartridge using the wget command to move the same libevent package 
and the compiled vibe.d binary. You won't be able to compile on a cartridge.


Your cartridge would look like this:

https://github.com/Filirom1/openshift-cartridge-nodejs/blob/master/bin/setup


Re: Deploying Vibe.d applications to OpenShift

2014-07-24 Thread John Colvin via Digitalmars-d-learn

On Thursday, 24 July 2014 at 02:48:45 UTC, Rutger wrote:
On Thursday, 24 July 2014 at 01:47:43 UTC, Rikki Cattermole 
wrote:

On 24/07/2014 1:28 p.m., Rutger wrote:

Hello! Really enjoying D so far and have started to toy around
with Vibe.d.
I was just wondering if someone here has had any experience 
with

publishing vibe applications on the OpenShift Paas?
(https://www.openshift.com)

Please let me know how you did it, because I know it's 
possible

with the DIY-cartridge they provide you(atleast it should be).


I was looking into it a while back. Its not so much the 
cartridges which are a problem. They are pretty easy to make. 
The issue is with the gears. 2gb is the max and most expensive.
But with D unless your very careful 1gb is more the norm. 
Atleast in my tests with Cmsed.
Also you will need to find a way to compile for their 
instances OS. Could be an issue as its most likely redhat (as 
its owned by them).


But they have a free plan. Might as well have a go.



Right now I've managed to try and start the binary but it logs 
an

error because the required libraries can't be found. Also do you
know if it's possible to compile a binary on ubuntu that will be
compatible with RHEL/Fedora?


Yes. However, you will probably have compatibility problems with 
the various shared libraries loaded by your executable, most 
prominently glibc.


zlibs gzip dosent work with http

2014-07-24 Thread Sean Campbell via Digitalmars-d-learn
I'm trying to add gzip compression to a HTTP server i wrote in D. 
here is the code that dose the gzip encoding.


if ((Info.modGzip)  
(indexOf(client.getRequestHeaderFieldValue(Accept-Encoding),gzip) 
!= -1)){

writeln(gzip);
auto gzip = new Compress(HeaderFormat.gzip);
client.addToResponseHeader(Content-Encoding: gzip);
client.sendHeader(200 ok);
while (0  (filestream.readBlock(readbuffer))){
client.client.send(gzip.compress(readbuffer));
}
client.client.send(gzip.flush());
delete gzip;
delete filestream;
}

but when i test it Firefox, internet explorer and chrome says 
that the encoding or compression is bad. why? the data is 
compressed with gzip.


the rest of the code is available at 
http://sourceforge.net/p/netspark/netsparkb1/ci/master/tree/


Git
git clone git://git.code.sf.net/p/netspark/netsparkb1 
netspark-netsparkb1


Segfault games with factorials

2014-07-24 Thread Darren via Digitalmars-d-learn
I have the following code in fac.d (modified from the factorial 
examples on RosettaCode):


#!/usr/bin/rdmd
import std.bigint;

pure BigInt factorial(BigInt n) {
static pure BigInt inner(BigInt n, BigInt acc) {
return n == 0 ? acc : inner(n - 1, acc * n);
}
return inner(n, BigInt(1));
}

void main(string[] args) {
import std.stdio;
BigInt input = args[1];
writeln(factorial(input));
return;
}

It (more or less consistently) on my machine will calculate 'fac 
47610', and (more or less consistently) will core dump with a 
segfault on 'fac 47611'.


Interestingly, if I redirect stdout to a file it will usually 
manage to get to 47612.


To satisfy my own curiosity about what's happening, are there any 
resources I can use to analyse the core dump?


Thanks.


Re: zlibs gzip dosent work with http

2014-07-24 Thread Adam D. Ruppe via Digitalmars-d-learn

On Thursday, 24 July 2014 at 13:09:53 UTC, Sean Campbell wrote:
I'm trying to add gzip compression to a HTTP server i wrote in 
D. here is the code that dose the gzip encoding.


I know zlib gzip works for http, I used it in my cgi.d


if(gzipResponse  acceptsGzip  isAll) {
auto c = new Compress(HeaderFormat.gzip); 
// want gzip


auto data = c.compress(t);
data ~= c.flush();

t = data;
}


But your http server is buggy in a lot of ways. It doesn't reply 
to curl and doesn't keep the connection open to issue manual 
requests.



Among the bugs I see looking at it quickly:

server.d getRequestHeaderFieldValue, you don't check if epos is 
-1. If it is, you should return null or something instead of 
trying to use it - the connection will hang because of an 
out-of-bounds array read killing the handler.



You also wrote:

if ((Info.modGzip)  
(indexOf(client.getRequestHeaderFieldValue(Accept-Encoding),gzip) 
!= -1)){



Notice the  instead of . That's in fspipedserver.d.



Finally, you write client.client.send... which never sent the 
headers back to the client, so it didn't know you were gzipping! 
Change that to client.sendData (and change sendData in server.d 
to take in void[] instead of void[]) and then it sends the 
headers and seems to work by my eyeballing.




if ((Info.modGzip)  
(indexOf(client.getRequestHeaderFieldValue(Accept-Encoding),gzip) 
!= -1)){

writeln(gzip);
auto gzip = new Compress(HeaderFormat.gzip);
client.addToResponseHeader(Content-Encoding: gzip);
client.sendHeader(200 ok);
while (0  (filestream.readBlock(readbuffer))){
client.client.send(gzip.compress(readbuffer));
}
client.client.send(gzip.flush());
delete gzip;
delete filestream;
}

but when i test it Firefox, internet explorer and chrome says 
that the encoding or compression is bad. why? the data is 
compressed with gzip.


the rest of the code is available at 
http://sourceforge.net/p/netspark/netsparkb1/ci/master/tree/


Git
git clone git://git.code.sf.net/p/netspark/netsparkb1 
netspark-netsparkb1




Re: Segfault games with factorials

2014-07-24 Thread H. S. Teoh via Digitalmars-d-learn
On Thu, Jul 24, 2014 at 01:14:40PM +, Darren via Digitalmars-d-learn wrote:
 I have the following code in fac.d (modified from the factorial
 examples on RosettaCode):
 
 #!/usr/bin/rdmd
 import std.bigint;
 
 pure BigInt factorial(BigInt n) {
 static pure BigInt inner(BigInt n, BigInt acc) {
   return n == 0 ? acc : inner(n - 1, acc * n);
 }
 return inner(n, BigInt(1));
 }
 
 void main(string[] args) {
   import std.stdio;
   BigInt input = args[1];
   writeln(factorial(input));
   return;
 }
 
 It (more or less consistently) on my machine will calculate 'fac
 47610', and (more or less consistently) will core dump with a segfault
 on 'fac 47611'.
[...]

You're probably running out of stack space because of your recursive
function. Write it as a loop instead, and you should be able to go
farther:

pure BigInt factorial(BigInt n) {
auto result = BigInt(1);
while (n  1)
result *= n;
return result;
}


T

-- 
Ignorance is bliss... until you suffer the consequences!


Re: Segfault games with factorials

2014-07-24 Thread Darren via Digitalmars-d-learn
On Thursday, 24 July 2014 at 14:39:12 UTC, H. S. Teoh via 
Digitalmars-d-learn wrote:
On Thu, Jul 24, 2014 at 01:14:40PM +, Darren via 
Digitalmars-d-learn wrote:

I have the following code in fac.d (modified from the factorial
examples on RosettaCode):

#!/usr/bin/rdmd
import std.bigint;

pure BigInt factorial(BigInt n) {
static pure BigInt inner(BigInt n, BigInt acc) {
return n == 0 ? acc : inner(n - 1, acc * n);
}
return inner(n, BigInt(1));
}

void main(string[] args) {
import std.stdio;
BigInt input = args[1];
writeln(factorial(input));
return;
}

It (more or less consistently) on my machine will calculate 
'fac
47610', and (more or less consistently) will core dump with a 
segfault

on 'fac 47611'.

[...]

You're probably running out of stack space because of your 
recursive
function. Write it as a loop instead, and you should be able to 
go

farther:

pure BigInt factorial(BigInt n) {
auto result = BigInt(1);
while (n  1)
result *= n;
return result;
}


T


It does seem that's the case. Which is odd, as I thought that DMD 
and LDC did TCO. Not in this case obviously.


PS. This was a slightly silly program, but in the general case, 
is there a way to use a core dump to diagnose a stack overflow?


Re: Segfault games with factorials

2014-07-24 Thread John Colvin via Digitalmars-d-learn

On Thursday, 24 July 2014 at 14:59:16 UTC, Darren wrote:
On Thursday, 24 July 2014 at 14:39:12 UTC, H. S. Teoh via 
Digitalmars-d-learn wrote:
On Thu, Jul 24, 2014 at 01:14:40PM +, Darren via 
Digitalmars-d-learn wrote:
I have the following code in fac.d (modified from the 
factorial

examples on RosettaCode):

#!/usr/bin/rdmd
import std.bigint;

pure BigInt factorial(BigInt n) {
   static pure BigInt inner(BigInt n, BigInt acc) {
return n == 0 ? acc : inner(n - 1, acc * n);
   }
   return inner(n, BigInt(1));
}

void main(string[] args) {
import std.stdio;
BigInt input = args[1];
writeln(factorial(input));
return;
}

It (more or less consistently) on my machine will calculate 
'fac
47610', and (more or less consistently) will core dump with a 
segfault

on 'fac 47611'.

[...]

You're probably running out of stack space because of your 
recursive
function. Write it as a loop instead, and you should be able 
to go

farther:

pure BigInt factorial(BigInt n) {
auto result = BigInt(1);
while (n  1)
result *= n;
return result;
}


T


It does seem that's the case. Which is odd, as I thought that 
DMD and LDC did TCO. Not in this case obviously.


PS. This was a slightly silly program, but in the general case, 
is there a way to use a core dump to diagnose a stack overflow?


A debugger should be able to tell you why the segfault occurred.


Re: D JSON (WAT?!)

2014-07-24 Thread Justin Whear via Digitalmars-d-learn
On Thu, 24 Jul 2014 15:15:36 +, Pavel wrote:

 Ok, let me start with the sample code:
 
 import std.stdio;
 import std.json;
 
 void main() {
scope(failure) writeln(FaILED!!);
string jsonStr = `{ name: 1, type: r }`;
auto parsed = parseJSON(jsonStr);
string s = parsed[fail].str;
writeln(s == );
writeln(s is null);
writeln(s);
 }
 
 Running rdmd app.d doesn't produce any output.
 Can anyone explain such a behavior???
 
 
 PS: Running dmd v2.065 on Linux x64.

That's because it produces a segmentation fault, which rdmd masks for 
some reason.  The `parsed[fail]` should throw a range bounds exception--
not sure why it's not.


Re: D JSON (WAT?!)

2014-07-24 Thread Adam D. Ruppe via Digitalmars-d-learn

On Thursday, 24 July 2014 at 15:15:37 UTC, Pavel wrote:

  string s = parsed[fail].str;


Since there is no entry fail in the object, it returns a null 
JSON_VALUE pointer. Trying to get the string out of it is then 
seen as a null pointer access and kills the program.


Check for null on a key before trying to get a value out.


D JSON (WAT?!)

2014-07-24 Thread Pavel via Digitalmars-d-learn

Ok, let me start with the sample code:

import std.stdio;
import std.json;

void main() {
  scope(failure) writeln(FaILED!!);
  string jsonStr = `{ name: 1, type: r }`;
  auto parsed = parseJSON(jsonStr);
  string s = parsed[fail].str;
  writeln(s == );
  writeln(s is null);
  writeln(s);
}

Running rdmd app.d doesn't produce any output.
Can anyone explain such a behavior???


PS: Running dmd v2.065 on Linux x64.


Re: D JSON (WAT?!)

2014-07-24 Thread bearophile via Digitalmars-d-learn

Adam D. Ruppe:


Check for null on a key before trying to get a value out.


Is something like the get() function usable here?

Bye,
bearophile


Re: D JSON (WAT?!)

2014-07-24 Thread Pavel via Digitalmars-d-learn

On Thursday, 24 July 2014 at 15:22:46 UTC, Adam D. Ruppe wrote:

On Thursday, 24 July 2014 at 15:15:37 UTC, Pavel wrote:

 string s = parsed[fail].str;


Since there is no entry fail in the object, it returns a null 
JSON_VALUE pointer. Trying to get the string out of it is then 
seen as a null pointer access and kills the program.


Check for null on a key before trying to get a value out.


Ok, added:

writeln(parsed[fail] == null);

Now compiler complains:

Error: incompatible types for ((parsed.opIndex(fail)) == 
(null)): 'JSONValue' and 'typeof(null)'



WAT?!


Re: D JSON (WAT?!)

2014-07-24 Thread Daniel Gibson via Digitalmars-d-learn

Am 24.07.2014 17:29, schrieb Pavel:

On Thursday, 24 July 2014 at 15:22:46 UTC, Adam D. Ruppe wrote:

On Thursday, 24 July 2014 at 15:15:37 UTC, Pavel wrote:

 string s = parsed[fail].str;


Since there is no entry fail in the object, it returns a null
JSON_VALUE pointer. Trying to get the string out of it is then seen as
a null pointer access and kills the program.

Check for null on a key before trying to get a value out.


Ok, added:

writeln(parsed[fail] == null);

Now compiler complains:

Error: incompatible types for ((parsed.opIndex(fail)) == (null)):
'JSONValue' and 'typeof(null)'


WAT?!



is instead of == ?


Re: D JSON (WAT?!)

2014-07-24 Thread Ali Çehreli via Digitalmars-d-learn

On 07/24/2014 08:29 AM, Pavel wrote:


writeln(parsed[fail] == null);

Now compiler complains:

Error: incompatible types for ((parsed.opIndex(fail)) == (null)):
'JSONValue' and 'typeof(null)'


WAT?!


Comparing against null should be done with the 'is' operator, not the == 
operator:


if (x is null)

Ali



Re: D JSON (WAT?!)

2014-07-24 Thread John Colvin via Digitalmars-d-learn

On Thursday, 24 July 2014 at 15:15:37 UTC, Pavel wrote:

Ok, let me start with the sample code:

import std.stdio;
import std.json;

void main() {
  scope(failure) writeln(FaILED!!);
  string jsonStr = `{ name: 1, type: r }`;
  auto parsed = parseJSON(jsonStr);
  string s = parsed[fail].str;
  writeln(s == );
  writeln(s is null);
  writeln(s);
}

Running rdmd app.d doesn't produce any output.
Can anyone explain such a behavior???


PS: Running dmd v2.065 on Linux x64.


It's a bug in std.json (you should get a segfault, not no output 
at all)


It is fixed now and I'm pretty sure it will be in 2.066

std.json has been improved a lot, but I would still recommend 
using http://vibed.org/api/vibe.data.json/ instead


Re: D JSON (WAT?!)

2014-07-24 Thread Pavel via Digitalmars-d-learn

On Thursday, 24 July 2014 at 15:31:30 UTC, Daniel Gibson wrote:

Am 24.07.2014 17:29, schrieb Pavel:

On Thursday, 24 July 2014 at 15:22:46 UTC, Adam D. Ruppe wrote:

On Thursday, 24 July 2014 at 15:15:37 UTC, Pavel wrote:

string s = parsed[fail].str;


Since there is no entry fail in the object, it returns a 
null
JSON_VALUE pointer. Trying to get the string out of it is 
then seen as

a null pointer access and kills the program.

Check for null on a key before trying to get a value out.


Ok, added:

writeln(parsed[fail] == null);

Now compiler complains:

Error: incompatible types for ((parsed.opIndex(fail)) == 
(null)):

'JSONValue' and 'typeof(null)'


WAT?!



is instead of == ?


Nope, the compiler still complains.


Re: D JSON (WAT?!)

2014-07-24 Thread Pavel via Digitalmars-d-learn

On Thursday, 24 July 2014 at 15:20:58 UTC, Justin Whear wrote:

On Thu, 24 Jul 2014 15:15:36 +, Pavel wrote:


Ok, let me start with the sample code:

import std.stdio;
import std.json;

void main() {
   scope(failure) writeln(FaILED!!);
   string jsonStr = `{ name: 1, type: r }`;
   auto parsed = parseJSON(jsonStr);
   string s = parsed[fail].str;
   writeln(s == );
   writeln(s is null);
   writeln(s);
}

Running rdmd app.d doesn't produce any output.
Can anyone explain such a behavior???


PS: Running dmd v2.065 on Linux x64.


That's because it produces a segmentation fault, which rdmd 
masks for
some reason.  The `parsed[fail]` should throw a range bounds 
exception--

not sure why it's not.


Here's phobos code from github:

/// Hash syntax for json objects.
/// Throws $(D JSONException) if $(D type) is not $(D 
JSON_TYPE.OBJECT).

ref inout(JSONValue) opIndex(string k) inout
{
enforceEx!JSONException(type == JSON_TYPE.OBJECT,
JSONValue is not an object);
return *enforceEx!JSONException(k in store.object,
Key not found:  ~ k);
}

Added in 
https://github.com/D-Programming-Language/phobos/commit/13fbd451bcca923cf8d1028495e58aa88cc7efeb


Maybe phobos is not up to date for me???


Re: Segfault games with factorials

2014-07-24 Thread safety0ff via Digitalmars-d-learn

On Thursday, 24 July 2014 at 14:59:16 UTC, Darren wrote:


It does seem that's the case. Which is odd, as I thought that 
DMD and LDC did TCO. Not in this case obviously.


DMD doesn't do it with the :? operator: 
https://issues.dlang.org/show_bug.cgi?id=3713


Re: D JSON (WAT?!)

2014-07-24 Thread John Colvin via Digitalmars-d-learn

On Thursday, 24 July 2014 at 15:32:29 UTC, John Colvin wrote:

On Thursday, 24 July 2014 at 15:15:37 UTC, Pavel wrote:

Ok, let me start with the sample code:

import std.stdio;
import std.json;

void main() {
 scope(failure) writeln(FaILED!!);
 string jsonStr = `{ name: 1, type: r }`;
 auto parsed = parseJSON(jsonStr);
 string s = parsed[fail].str;
 writeln(s == );
 writeln(s is null);
 writeln(s);
}

Running rdmd app.d doesn't produce any output.
Can anyone explain such a behavior???


PS: Running dmd v2.065 on Linux x64.


It's a bug in std.json (you should get a segfault, not no 
output at all)


It is fixed now and I'm pretty sure it will be in 2.066

std.json has been improved a lot, but I would still recommend 
using http://vibed.org/api/vibe.data.json/ instead


perhaps bug is too strong a word, but it was a deficiency that 
is now corrected. You will get an exception thrown now and 
everything should work how you expect.


Re: D JSON (WAT?!)

2014-07-24 Thread Pavel via Digitalmars-d-learn

On Thursday, 24 July 2014 at 15:34:22 UTC, Ali Çehreli wrote:

On 07/24/2014 08:29 AM, Pavel wrote:


writeln(parsed[fail] == null);

Now compiler complains:

Error: incompatible types for ((parsed.opIndex(fail)) == 
(null)):

'JSONValue' and 'typeof(null)'


WAT?!


Comparing against null should be done with the 'is' operator, 
not the == operator:


if (x is null)

Ali


My compiler disagreed:

app.d(8): Error: incompatible types for ((parsed.opIndex(fail)) 
is (null)): 'JSONValue' and 'typeof(null)'


Re: D JSON (WAT?!)

2014-07-24 Thread Pavel via Digitalmars-d-learn

On Thursday, 24 July 2014 at 15:32:29 UTC, John Colvin wrote:

On Thursday, 24 July 2014 at 15:15:37 UTC, Pavel wrote:

Ok, let me start with the sample code:

import std.stdio;
import std.json;

void main() {
 scope(failure) writeln(FaILED!!);
 string jsonStr = `{ name: 1, type: r }`;
 auto parsed = parseJSON(jsonStr);
 string s = parsed[fail].str;
 writeln(s == );
 writeln(s is null);
 writeln(s);
}

Running rdmd app.d doesn't produce any output.
Can anyone explain such a behavior???


PS: Running dmd v2.065 on Linux x64.


It's a bug in std.json (you should get a segfault, not no 
output at all)


It is fixed now and I'm pretty sure it will be in 2.066

std.json has been improved a lot, but I would still recommend 
using http://vibed.org/api/vibe.data.json/ instead


I'm pretty sure it's improving, but it has that Java disease, 
which is creating new Types, which are just wrappers for common 
types.
Why don't just use Variant[string] for objects, and Variant[] for 
arrays. This way you won't be putting another layer of knowledge 
for those who work with std.json.


Re: D JSON (WAT?!)

2014-07-24 Thread Pavel via Digitalmars-d-learn

On Thursday, 24 July 2014 at 15:42:58 UTC, Pavel wrote:

On Thursday, 24 July 2014 at 15:38:06 UTC, John Colvin wrote:

On Thursday, 24 July 2014 at 15:32:29 UTC, John Colvin wrote:

On Thursday, 24 July 2014 at 15:15:37 UTC, Pavel wrote:

Ok, let me start with the sample code:

import std.stdio;
import std.json;

void main() {
scope(failure) writeln(FaILED!!);
string jsonStr = `{ name: 1, type: r }`;
auto parsed = parseJSON(jsonStr);
string s = parsed[fail].str;
writeln(s == );
writeln(s is null);
writeln(s);
}

Running rdmd app.d doesn't produce any output.
Can anyone explain such a behavior???


PS: Running dmd v2.065 on Linux x64.


It's a bug in std.json (you should get a segfault, not no 
output at all)


It is fixed now and I'm pretty sure it will be in 2.066

std.json has been improved a lot, but I would still recommend 
using http://vibed.org/api/vibe.data.json/ instead


perhaps bug is too strong a word, but it was a deficiency 
that is now corrected. You will get an exception thrown now 
and everything should work how you expect.


Maybe. But still it's not the way I expect, any time you check 
for non-existing property you must consider exception, which is 
very heavy to deal with in such a situation. I'd rather expect 
to get null, whenever I try to fetch non-existing property, and 
not an exception.


That's purely my point, and I don't claim to be right in this 
way. It's up to Phobos maintainers to decide how to reprent 
JSON parsing results.


Also that's why you just can't write:

writeln(fail in parsed);

As JSONValue is just a wrapper: non-native, non-intuitive.


Re: D JSON (WAT?!)

2014-07-24 Thread Pavel via Digitalmars-d-learn

On Thursday, 24 July 2014 at 15:38:06 UTC, John Colvin wrote:

On Thursday, 24 July 2014 at 15:32:29 UTC, John Colvin wrote:

On Thursday, 24 July 2014 at 15:15:37 UTC, Pavel wrote:

Ok, let me start with the sample code:

import std.stdio;
import std.json;

void main() {
scope(failure) writeln(FaILED!!);
string jsonStr = `{ name: 1, type: r }`;
auto parsed = parseJSON(jsonStr);
string s = parsed[fail].str;
writeln(s == );
writeln(s is null);
writeln(s);
}

Running rdmd app.d doesn't produce any output.
Can anyone explain such a behavior???


PS: Running dmd v2.065 on Linux x64.


It's a bug in std.json (you should get a segfault, not no 
output at all)


It is fixed now and I'm pretty sure it will be in 2.066

std.json has been improved a lot, but I would still recommend 
using http://vibed.org/api/vibe.data.json/ instead


perhaps bug is too strong a word, but it was a deficiency 
that is now corrected. You will get an exception thrown now and 
everything should work how you expect.


Maybe. But still it's not the way I expect, any time you check 
for non-existing property you must consider exception, which is 
very heavy to deal with in such a situation. I'd rather expect to 
get null, whenever I try to fetch non-existing property, and not 
an exception.


That's purely my point, and I don't claim to be right in this 
way. It's up to Phobos maintainers to decide how to reprent JSON 
parsing results.


Re: D JSON (WAT?!)

2014-07-24 Thread Edwin van Leeuwen via Digitalmars-d-learn

On Thursday, 24 July 2014 at 15:42:58 UTC, Pavel wrote:

On Thursday, 24 July 2014 at 15:38:06 UTC, John Colvin wrote:

On Thursday, 24 July 2014 at 15:32:29 UTC, John Colvin wrote:

On Thursday, 24 July 2014 at 15:15:37 UTC, Pavel wrote:

Ok, let me start with the sample code:

import std.stdio;
import std.json;

void main() {
scope(failure) writeln(FaILED!!);
string jsonStr = `{ name: 1, type: r }`;
auto parsed = parseJSON(jsonStr);
string s = parsed[fail].str;
writeln(s == );
writeln(s is null);
writeln(s);
}

Running rdmd app.d doesn't produce any output.
Can anyone explain such a behavior???


PS: Running dmd v2.065 on Linux x64.


It's a bug in std.json (you should get a segfault, not no 
output at all)


It is fixed now and I'm pretty sure it will be in 2.066

std.json has been improved a lot, but I would still recommend 
using http://vibed.org/api/vibe.data.json/ instead


perhaps bug is too strong a word, but it was a deficiency 
that is now corrected. You will get an exception thrown now 
and everything should work how you expect.


Maybe. But still it's not the way I expect, any time you check 
for non-existing property you must consider exception, which is 
very heavy to deal with in such a situation. I'd rather expect 
to get null, whenever I try to fetch non-existing property, and 
not an exception.


You can turn your json object into an AA object and then use in 
to check for existence (I know it is not very intuitive):


JSONValue[string] jsonAA = parsed.object;
if ( fail in jsonAA )
  s = jsonAA[fail].str;





That's purely my point, and I don't claim to be right in this 
way. It's up to Phobos maintainers to decide how to reprent 
JSON parsing results.




Re: D JSON (WAT?!)

2014-07-24 Thread Pavel via Digitalmars-d-learn
On Thursday, 24 July 2014 at 15:48:32 UTC, Edwin van Leeuwen 
wrote:

On Thursday, 24 July 2014 at 15:42:58 UTC, Pavel wrote:

On Thursday, 24 July 2014 at 15:38:06 UTC, John Colvin wrote:

On Thursday, 24 July 2014 at 15:32:29 UTC, John Colvin wrote:

On Thursday, 24 July 2014 at 15:15:37 UTC, Pavel wrote:

Ok, let me start with the sample code:

import std.stdio;
import std.json;

void main() {
scope(failure) writeln(FaILED!!);
string jsonStr = `{ name: 1, type: r }`;
auto parsed = parseJSON(jsonStr);
string s = parsed[fail].str;
writeln(s == );
writeln(s is null);
writeln(s);
}

Running rdmd app.d doesn't produce any output.
Can anyone explain such a behavior???


PS: Running dmd v2.065 on Linux x64.


It's a bug in std.json (you should get a segfault, not no 
output at all)


It is fixed now and I'm pretty sure it will be in 2.066

std.json has been improved a lot, but I would still 
recommend using http://vibed.org/api/vibe.data.json/ instead


perhaps bug is too strong a word, but it was a deficiency 
that is now corrected. You will get an exception thrown now 
and everything should work how you expect.


Maybe. But still it's not the way I expect, any time you check 
for non-existing property you must consider exception, which 
is very heavy to deal with in such a situation. I'd rather 
expect to get null, whenever I try to fetch non-existing 
property, and not an exception.


You can turn your json object into an AA object and then use in 
to check for existence (I know it is not very intuitive):


JSONValue[string] jsonAA = parsed.object;
if ( fail in jsonAA )
  s = jsonAA[fail].str;





That's purely my point, and I don't claim to be right in this 
way. It's up to Phobos maintainers to decide how to reprent 
JSON parsing results.


Guess what, here's a new snippet:

import std.stdio;
import std.json;

void main() {
  scope(failure) writeln(FaILED!!);
  string jsonStr = `{ name: 1, type: r }`;
  auto parsed = parseJSON(jsonStr).object;
  writeln(fail in parsed);
}

Output is:
null

WAT?!

Ofcourse, writing like:

writeln(cast(bool)(fail in parsed));

Produces false... but why on earth boolean expression would 
output null?


PS: Sorry, for such an emotional boom, I'm so frustrated right 
now.


Re: D JSON (WAT?!)

2014-07-24 Thread Daniel Gibson via Digitalmars-d-learn

Am 24.07.2014 17:54, schrieb Pavel:


Guess what, here's a new snippet:

import std.stdio;
import std.json;

void main() {
   scope(failure) writeln(FaILED!!);
   string jsonStr = `{ name: 1, type: r }`;
   auto parsed = parseJSON(jsonStr).object;
   writeln(fail in parsed);
}

Output is:
null

WAT?!

Ofcourse, writing like:

writeln(cast(bool)(fail in parsed));

Produces false... but why on earth boolean expression would output null?

PS: Sorry, for such an emotional boom, I'm so frustrated right now.


Relax :-)

And see http://dlang.org/hash-map.html

in doesn't just return if something is in a map.
If it is, it returns a pointer to the value, otherwise null.
Thus null.

Cheers,
Daniel


Re: D JSON (WAT?!)

2014-07-24 Thread bearophile via Digitalmars-d-learn

Pavel:


writeln(cast(bool)(fail in parsed));

Produces false... but why on earth boolean expression would 
output null?


In D if you perform an associative array in, the return isn't a 
boolean but a pointer. It's zero if the item is not present. And 
it's a valid pointer to the value if the key is present.


Bye,
bearophile


Re: D JSON (WAT?!)

2014-07-24 Thread H. S. Teoh via Digitalmars-d-learn
On Thu, Jul 24, 2014 at 03:54:20PM +, Pavel via Digitalmars-d-learn wrote:
[...]
 Guess what, here's a new snippet:
 
 import std.stdio;
 import std.json;
 
 void main() {
   scope(failure) writeln(FaILED!!);
   string jsonStr = `{ name: 1, type: r }`;
   auto parsed = parseJSON(jsonStr).object;
   writeln(fail in parsed);
 }
 
 Output is:
 null
 
 WAT?!
 
 Ofcourse, writing like:
 
 writeln(cast(bool)(fail in parsed));
 
 Produces false... but why on earth boolean expression would output null?

It's not a boolean expression. The 'in' operator returns a pointer.
Rationale: avoid double lookups, for example:

if (auto ptr = key in assocArray) {
doSomething(*ptr);
}


T

-- 
The right half of the brain controls the left half of the body. This means that 
only left-handed people are in their right mind. -- Manoj Srivastava


Re: D JSON (WAT?!)

2014-07-24 Thread Pavel via Digitalmars-d-learn

On Thursday, 24 July 2014 at 15:59:52 UTC, Daniel Gibson wrote:

Am 24.07.2014 17:54, schrieb Pavel:


Guess what, here's a new snippet:

import std.stdio;
import std.json;

void main() {
  scope(failure) writeln(FaILED!!);
  string jsonStr = `{ name: 1, type: r }`;
  auto parsed = parseJSON(jsonStr).object;
  writeln(fail in parsed);
}

Output is:
null

WAT?!

Ofcourse, writing like:

writeln(cast(bool)(fail in parsed));

Produces false... but why on earth boolean expression would 
output null?


PS: Sorry, for such an emotional boom, I'm so frustrated right 
now.


Relax :-)

And see http://dlang.org/hash-map.html

in doesn't just return if something is in a map.
If it is, it returns a pointer to the value, otherwise null.
Thus null.

Cheers,
Daniel


Thanks to all you folks who explained in operator for me. My 
bad.

Let's focus on the real problem, which is JSON wrapper class.
Is it needed? Wouldn't it be better to get AA from parseJSON?


Re: D JSON (WAT?!)

2014-07-24 Thread Justin Whear via Digitalmars-d-learn
On Thu, 24 Jul 2014 15:54:20 +, Pavel wrote:

 On Thursday, 24 July 2014 at 15:48:32 UTC, Edwin van Leeuwen wrote:
 On Thursday, 24 July 2014 at 15:42:58 UTC, Pavel wrote:
 On Thursday, 24 July 2014 at 15:38:06 UTC, John Colvin wrote:
 On Thursday, 24 July 2014 at 15:32:29 UTC, John Colvin wrote:
 On Thursday, 24 July 2014 at 15:15:37 UTC, Pavel wrote:
 Ok, let me start with the sample code:

 import std.stdio;
 import std.json;

 void main() {
 scope(failure) writeln(FaILED!!);
 string jsonStr = `{ name: 1, type: r }`;
 auto parsed = parseJSON(jsonStr);
 string s = parsed[fail].str;
 writeln(s == );
 writeln(s is null);
 writeln(s);
 }

 Running rdmd app.d doesn't produce any output.
 Can anyone explain such a behavior???


 PS: Running dmd v2.065 on Linux x64.

 It's a bug in std.json (you should get a segfault, not no output at
 all)

 It is fixed now and I'm pretty sure it will be in 2.066

 std.json has been improved a lot, but I would still recommend using
 http://vibed.org/api/vibe.data.json/ instead

 perhaps bug is too strong a word, but it was a deficiency that is
 now corrected. You will get an exception thrown now and everything
 should work how you expect.

 Maybe. But still it's not the way I expect, any time you check for
 non-existing property you must consider exception, which is very heavy
 to deal with in such a situation. I'd rather expect to get null,
 whenever I try to fetch non-existing property, and not an exception.

 You can turn your json object into an AA object and then use in to
 check for existence (I know it is not very intuitive):

 JSONValue[string] jsonAA = parsed.object;
 if ( fail in jsonAA )
   s = jsonAA[fail].str;




 That's purely my point, and I don't claim to be right in this way.
 It's up to Phobos maintainers to decide how to reprent JSON parsing
 results.
 
 Guess what, here's a new snippet:
 
 import std.stdio;
 import std.json;
 
 void main() {
scope(failure) writeln(FaILED!!);
string jsonStr = `{ name: 1, type: r }`;
auto parsed = parseJSON(jsonStr).object; writeln(fail in parsed);
 }
 
 Output is:
 null
 
 WAT?!
 
 Ofcourse, writing like:
 
 writeln(cast(bool)(fail in parsed));
 
 Produces false... but why on earth boolean expression would output
 null?
 
 PS: Sorry, for such an emotional boom, I'm so frustrated right now.

The `in` expression produces a pointer to the value in the container, not 
a bool.  If the key is not present in the container, it returns the null 
pointer.  So this test is working precisely as expected.  Here are some 
common idioms for working with `in` and associative arrays:

// if with declaration
if (auto vptr = fail in parsed.object)
writeln(here's the value: , *vptr);
else
writeln(fail is not in the JSON);

// coerce to bool
writeln(!!(fail in parsed.object));

// get the value or a default value
writeln(parsed.object.get(fail, someDefaultJson));


Re: D JSON (WAT?!)

2014-07-24 Thread John Colvin via Digitalmars-d-learn

On Thursday, 24 July 2014 at 15:54:21 UTC, Pavel wrote:
On Thursday, 24 July 2014 at 15:48:32 UTC, Edwin van Leeuwen 
wrote:

On Thursday, 24 July 2014 at 15:42:58 UTC, Pavel wrote:

On Thursday, 24 July 2014 at 15:38:06 UTC, John Colvin wrote:

On Thursday, 24 July 2014 at 15:32:29 UTC, John Colvin wrote:

On Thursday, 24 July 2014 at 15:15:37 UTC, Pavel wrote:

Ok, let me start with the sample code:

import std.stdio;
import std.json;

void main() {
scope(failure) writeln(FaILED!!);
string jsonStr = `{ name: 1, type: r }`;
auto parsed = parseJSON(jsonStr);
string s = parsed[fail].str;
writeln(s == );
writeln(s is null);
writeln(s);
}

Running rdmd app.d doesn't produce any output.
Can anyone explain such a behavior???


PS: Running dmd v2.065 on Linux x64.


It's a bug in std.json (you should get a segfault, not no 
output at all)


It is fixed now and I'm pretty sure it will be in 2.066

std.json has been improved a lot, but I would still 
recommend using http://vibed.org/api/vibe.data.json/ instead


perhaps bug is too strong a word, but it was a deficiency 
that is now corrected. You will get an exception thrown now 
and everything should work how you expect.


Maybe. But still it's not the way I expect, any time you 
check for non-existing property you must consider exception, 
which is very heavy to deal with in such a situation. I'd 
rather expect to get null, whenever I try to fetch 
non-existing property, and not an exception.


You can turn your json object into an AA object and then use 
in to check for existence (I know it is not very intuitive):


JSONValue[string] jsonAA = parsed.object;
if ( fail in jsonAA )
 s = jsonAA[fail].str;





That's purely my point, and I don't claim to be right in this 
way. It's up to Phobos maintainers to decide how to reprent 
JSON parsing results.


Guess what, here's a new snippet:

import std.stdio;
import std.json;

void main() {
  scope(failure) writeln(FaILED!!);
  string jsonStr = `{ name: 1, type: r }`;
  auto parsed = parseJSON(jsonStr).object;
  writeln(fail in parsed);
}

Output is:
null

WAT?!

Ofcourse, writing like:

writeln(cast(bool)(fail in parsed));

Produces false... but why on earth boolean expression would 
output null?


PS: Sorry, for such an emotional boom, I'm so frustrated right 
now.


The in operator in d returns a pointer to the element found or 
null.
This might be a little confusing at first* but it makes sense for 
efficiency reasons. There is often a lot overlap between the work 
needed to test for presence and the work needed to fetch an 
element.


For types where fetching elements is a significant extra cost you 
can always define a `bool contains(K key) { /* ... */ }` so a 
user can avoid this cost when appropriate.



*although to be honest it's just a different reading:
`b in c` can be read as the b in c or is b in c?


Re: D JSON (WAT?!)

2014-07-24 Thread Justin Whear via Digitalmars-d-learn
On Thu, 24 Jul 2014 16:04:01 +, Pavel wrote:
 
 Thanks to all you folks who explained in operator for me. My bad.
 Let's focus on the real problem, which is JSON wrapper class. Is it
 needed? Wouldn't it be better to get AA from parseJSON?

The following are valid JSON:

auto json1 = parseJSON(`1`);
auto json2 = parseJSON(`foo`);
auto json3 = parseJSON(`[1, 2, 3]`);

None of these fit naturally into an JSONValue[string] return type.


Passing an array by reference?

2014-07-24 Thread Rishub Nagpal via Digitalmars-d-learn

  1 class Test
  2 {
  3 int[][] array;
  4 this(ref int[][] d)
  5 {
  6 array = d;
  7 }
  8
  9 }
 10
 11 void main()
 12 {
 13 Test t = new Test([[1,1],[1,1]]);   //does not compile
 14 }
 15


what is the best way to pass a literal ([[1,2],[3,4]]) by 
reference? Is using ref the best way? I am still a bit fuzzy with 
in/out and scope




Re: D JSON (WAT?!)

2014-07-24 Thread Pavel via Digitalmars-d-learn
On Thursday, 24 July 2014 at 16:02:12 UTC, H. S. Teoh via 
Digitalmars-d-learn wrote:
On Thu, Jul 24, 2014 at 03:54:20PM +, Pavel via 
Digitalmars-d-learn wrote:

[...]

Guess what, here's a new snippet:

import std.stdio;
import std.json;

void main() {
  scope(failure) writeln(FaILED!!);
  string jsonStr = `{ name: 1, type: r }`;
  auto parsed = parseJSON(jsonStr).object;
  writeln(fail in parsed);
}

Output is:
null

WAT?!

Ofcourse, writing like:

writeln(cast(bool)(fail in parsed));

Produces false... but why on earth boolean expression would 
output null?


It's not a boolean expression. The 'in' operator returns a 
pointer.

Rationale: avoid double lookups, for example:

if (auto ptr = key in assocArray) {
doSomething(*ptr);
}


T


Thanks once again. Now I finally get this thing done with code 
like this:


import std.stdio;
import std.json;

void main() {
  scope(failure) writeln(Failure!!);
  string jsonStr = `{ name: 1, type: r }`;
  auto parsed = parseJSON(jsonStr).object;
  auto found = fail in parsed;
  if (found !is null) {
string s = found.str;
writeln(s);
  } else {
writeln(No such key);
  }
}

Still focus on wrapper class discussion :)


Re: D JSON (WAT?!)

2014-07-24 Thread Pavel via Digitalmars-d-learn

On Thursday, 24 July 2014 at 16:09:25 UTC, Justin Whear wrote:

On Thu, 24 Jul 2014 16:04:01 +, Pavel wrote:


Thanks to all you folks who explained in operator for me. My 
bad.
Let's focus on the real problem, which is JSON wrapper class. 
Is it

needed? Wouldn't it be better to get AA from parseJSON?


The following are valid JSON:

auto json1 = parseJSON(`1`);
auto json2 = parseJSON(`foo`);
auto json3 = parseJSON(`[1, 2, 3]`);

None of these fit naturally into an JSONValue[string] return 
type.


Oh, man! You're wrong!!! Read: http://www.json.org/, and try 
putting 1 or foo as JSON string here: http://jsonlint.com/


Re: Passing an array by reference?

2014-07-24 Thread John Colvin via Digitalmars-d-learn

On Thursday, 24 July 2014 at 16:06:00 UTC, Rishub Nagpal wrote:

  1 class Test
  2 {
  3 int[][] array;
  4 this(ref int[][] d)
  5 {
  6 array = d;
  7 }
  8
  9 }
 10
 11 void main()
 12 {
 13 Test t = new Test([[1,1],[1,1]]);   //does not compile
 14 }
 15


what is the best way to pass a literal ([[1,2],[3,4]]) by 
reference? Is using ref the best way? I am still a bit fuzzy 
with in/out and scope


Why do you need to pass the array by reference? D's slices are 
just windows on to memory, they don't copy the contents when you 
pass them around.


Anyway, if you do need ref, the problem is that [[1,1],[1,1]] is 
a temporary, an rvalue, and ref can't take rvalues.


Re: D JSON (WAT?!)

2014-07-24 Thread Ary Borenszweig via Digitalmars-d-learn

On 7/24/14, 1:09 PM, Justin Whear wrote:

On Thu, 24 Jul 2014 16:04:01 +, Pavel wrote:


Thanks to all you folks who explained in operator for me. My bad.
Let's focus on the real problem, which is JSON wrapper class. Is it
needed? Wouldn't it be better to get AA from parseJSON?


The following are valid JSON:

auto json1 = parseJSON(`1`);
auto json2 = parseJSON(`foo`);
auto json3 = parseJSON(`[1, 2, 3]`);

None of these fit naturally into an JSONValue[string] return type.


Nope, a JSON can only be an array or an object (hash).

In Crystal we have this definition:

alias JsonType = Nil | Bool | Int64 | Float64 | String | Array(JsonType) 
| Hash(String, JsonType)


(note that this is a recursive type definition)

Then when you do Json.parse you get a value whose type is 
Array(JsonType) | Hash(String, JsonType).


The good thing about this is that Json.parse gives you types that 
already exist: Array, Hash, Int64, etc. No need to define extra types 
and no need for users to learn a new API with new types.


Wouldn't something like this be better to do in D? That is, return 
something that is an array or an associative array...


Re: D JSON (WAT?!)

2014-07-24 Thread Justin Whear via Digitalmars-d-learn
On Thu, 24 Jul 2014 13:49:27 -0300, Ary Borenszweig wrote:

 Nope, a JSON can only be an array or an object (hash).

Ary, can you point out the place in the spec where this is specified?  
Not to be pedantic, but the spec only seems to define a JSON value, not 
a JSON document.


Re: D JSON (WAT?!)

2014-07-24 Thread Justin Whear via Digitalmars-d-learn
On Thu, 24 Jul 2014 16:14:15 +, Pavel wrote:

 On Thursday, 24 July 2014 at 16:09:25 UTC, Justin Whear wrote:
 On Thu, 24 Jul 2014 16:04:01 +, Pavel wrote:
 
 Thanks to all you folks who explained in operator for me. My bad.
 Let's focus on the real problem, which is JSON wrapper class. Is it
 needed? Wouldn't it be better to get AA from parseJSON?

 The following are valid JSON:

 auto json1 = parseJSON(`1`);
 auto json2 = parseJSON(`foo`);
 auto json3 = parseJSON(`[1, 2, 3]`);

 None of these fit naturally into an JSONValue[string] return type.
 
 Oh, man! You're wrong!!! Read: http://www.json.org/, and try putting 1
 or foo as JSON string here: http://jsonlint.com/

Nope, while the spec calls out objects and arrays as the structural 
elements of JSON, it never requires (anywhere that I can find) that a 
complete JSON document have one of these at the root.  A valid JSON value 
is defined as

A JSON value can be an object, array, number, string, true, false, or 
null[1]

Thus the parseJSON function is defined as parsing as JSONValue.

1 http://www.ecma-international.org/publications/files/ECMA-ST/
ECMA-404.pdf, p2


Re: How to copy an object to separate allocated memory?

2014-07-24 Thread Justin Whear via Digitalmars-d-learn
On Thu, 24 Jul 2014 17:05:17 +, Gary Willoughby wrote:

 I was reading Ali's book (http://ddili.org/ders/d.en/index.html)
 and saw this piece of code on how to get the true size of an object:
 
 MyClass* buffer = cast(MyClass*)GC.calloc(__traits(classInstanceSize,
 MyClass) * 10);
 
 That got me thinking, how would i actually 'fill' this memory with
 instances of that class?

std.conv.emplace: http://dlang.org/phobos/std_conv.html#.emplace


How to copy an object to separate allocated memory?

2014-07-24 Thread Gary Willoughby via Digitalmars-d-learn
I was reading Ali's book (http://ddili.org/ders/d.en/index.html) 
and saw this piece of code on how to get the true size of an 
object:


MyClass* buffer = 
cast(MyClass*)GC.calloc(__traits(classInstanceSize, MyClass) * 
10);


That got me thinking, how would i actually 'fill' this memory 
with instances of that class?


Re: How to copy an object to separate allocated memory?

2014-07-24 Thread Daniel Gibson via Digitalmars-d-learn

Am 24.07.2014 19:05, schrieb Gary Willoughby:

I was reading Ali's book (http://ddili.org/ders/d.en/index.html) and saw
this piece of code on how to get the true size of an object:

MyClass* buffer = cast(MyClass*)GC.calloc(__traits(classInstanceSize,
MyClass) * 10);

That got me thinking, how would i actually 'fill' this memory with
instances of that class?


std.conv.emplace()


Re: How to copy an object to separate allocated memory?

2014-07-24 Thread John Colvin via Digitalmars-d-learn

On Thursday, 24 July 2014 at 17:05:18 UTC, Gary Willoughby wrote:
I was reading Ali's book 
(http://ddili.org/ders/d.en/index.html) and saw this piece of 
code on how to get the true size of an object:


MyClass* buffer = 
cast(MyClass*)GC.calloc(__traits(classInstanceSize, MyClass) * 
10);


That got me thinking, how would i actually 'fill' this memory 
with instances of that class?


std.conv.emplace


Re: How to copy an object to separate allocated memory?

2014-07-24 Thread Justin Whear via Digitalmars-d-learn
On Thu, 24 Jul 2014 17:07:29 +, Justin Whear wrote:

 On Thu, 24 Jul 2014 17:05:17 +, Gary Willoughby wrote:
 
 I was reading Ali's book (http://ddili.org/ders/d.en/index.html)
 and saw this piece of code on how to get the true size of an object:
 
 MyClass* buffer = cast(MyClass*)GC.calloc(__traits(classInstanceSize,
 MyClass) * 10);
 
 That got me thinking, how would i actually 'fill' this memory with
 instances of that class?
 
 std.conv.emplace: http://dlang.org/phobos/std_conv.html#.emplace

Wow, the ninja'ing is strong today.


Mocking serial device

2014-07-24 Thread Alfredo Palhares via Digitalmars-d-learn

Hello,

I am writing an application that connects to a serial device in 
/dev/ttyUSB0 and trows some binary data back and forth.



How can i mock and run some unit testing without having to 
connect to the device every time?


--
Regards,
Alfredo Palhares


dual with statement

2014-07-24 Thread Jay Norwood via Digitalmars-d-learn
I was playing around with use of the dual WITH statement.   I 
like the idea, since it makes the code within the with cleaner.   
Also, I got the impression from one of the conference 
presentations ... maybe the one on the ARM debug ... that there 
are some additional optimizations available that the compiler 
processes the WITH statement block.


Anyway, a problem I ran into was if two structures had the same 
member names, for example struct ar.r and ar.psm in this case 
below.   In this case, there was no way for the compiler to 
determine from which structure to get the member.


void calc_per_sec_met(ref All ar){

   with (ar.r) with(ar.psm) {
  double per_sec = proc_cyc/ref_clock;
  d = (a+c)*per_sec;
  e = (c==0)?0:(a+b)/c;
   }
}

ok, so I guess I could make all the member names unique in the 
different structures, but that's kind of ugly.


Also, what happens if using two structs of the same type in a 
WITH statement.
Seems like something like this would help, which I believe I've 
seen used in database queries ...


 with (ar.r1 as r1) with (ar.r2 as r2){
   auto sum = r1.a + r2.a;
 }




Re: Mocking serial device

2014-07-24 Thread Justin Whear via Digitalmars-d-learn
On Thu, 24 Jul 2014 17:15:02 +, Alfredo Palhares wrote:

 Hello,
 
 I am writing an application that connects to a serial device in
 /dev/ttyUSB0 and trows some binary data back and forth.
 
 
 How can i mock and run some unit testing without having to connect to
 the device every time?

How about capturing some data from the device and writing it to a file?  
When you want to test, open the test data file instead of the device file.


Re: Mocking serial device

2014-07-24 Thread Alfredo Palhares via Digitalmars-d-learn


Hello,

How about capturing some data from the device and writing it to 
a file?
When you want to test, open the test data file instead of the 
device file.


That would not work since the data is two way, for the device to 
even trow data at me I need to send some values to it.


--
Regards,
Alfredo Palhares


Appender.put return value

2014-07-24 Thread JR via Digitalmars-d-learn

Is there a big reason why Appender.put doesn't return this?

http://dpaste.dzfl.pl/bb840e3e349e

It would allow for convenient chaining. :


Re: Appender.put return value

2014-07-24 Thread Temtaime via Digitalmars-d-learn

Offtop
It's better to return this and have return type ref auto i 
think.


Re: D JSON (WAT?!)

2014-07-24 Thread Ary Borenszweig via Digitalmars-d-learn

On 7/24/14, 1:58 PM, Justin Whear wrote:

On Thu, 24 Jul 2014 13:49:27 -0300, Ary Borenszweig wrote:


Nope, a JSON can only be an array or an object (hash).


Ary, can you point out the place in the spec where this is specified?
Not to be pedantic, but the spec only seems to define a JSON value, not
a JSON document.



You are right, my bad. According to Wikipedia (which has links to RFCs):

Early versions of JSON (such as specified by RFC 4627) required that a 
valid JSON document must consist of only an object or an array 
type—though they could contain other types within them. This restriction 
was relaxed starting with RFC 7158, so that a JSON document may consist 
entirely of any possible JSON typed value.


Create a general array

2014-07-24 Thread Robert Rimoczi via Digitalmars-d-learn

Hi!

Can I somehow make a general array where I can store everykind of 
object? doubles, ints, float, class objects? Or is there any 
method for it?