Re: rmdirRecurse - on NFS file system

[Vino via Digitalmars-d-learn]

On Tuesday, 13 February 2018 at 17:01:06 UTC, Seb wrote:

On Tuesday, 13 February 2018 at 16:58:09 UTC, Vino wrote:

On Monday, 12 February 2018 at 06:52:25 UTC, Vino wrote:

[...]


Hi All,

Was able to resolve this issue.


That's great!

BTW I think it would be helpful for future reader who find this 
thread to know how you resolved your problem.


Hi All,

I just modified the below lines of the code,

if (Step == "run" && !dFiles.empty) { dFiles.each!(f => 
rmdirRecurse(f[0])); } return dFiles;



From,
Vino.B

Re: dmd-2.078.2 problems with Ubuntu 17.10 32Bit

[Martin Tschierschke via Digitalmars-d-learn]

On Tuesday, 13 February 2018 at 21:25:44 UTC, Jordi Sayol wrote:
El 13/02/18 a les 08:03, Martin Tschierschke via 
Digitalmars-d-learn ha escrit:

On Monday, 12 February 2018 at 21:18:01 UTC, Jordi Sayol wrote:
El 12/02/18 a les 21:56, Martin Tschierschke via 
Digitalmars-d-learn ha escrit:
I just started to play around with D again on my notebook at 
home and realized,

that I have a broken installation.
Even the minimal D "hello world" throws an error at 
execution.
Speicherzugriffsfehler (Speicherabzug geschrieben) aka. core 
dump


Compiling with ldc2 still works.
Any hint?





d-apt 


After setting ulimit -c unlimited to get the core dumped, I 
took a look with gdb, to find a hint, now realizing, that it 
is probably the same problem as here: 
https://forum.dlang.org/thread/jjaynewwdsyntyehv...@forum.dlang.org?page=1




A fresh install from d-apt on Ubuntu 16.04 32-bit, and 
everything worked fine.




I tried a lot, there is special bug new on ubuntu 17.10 in
/etc/apt/sources.list.d/d-apt.list

!!! I had to change http://... to https://


Before that I imported the key with
sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 
EBCF975E5BA24D5E


I am not sure if this was necessary, probably not.

Than I was able to call

sudo apt-get update && sudo apt-get -y --allow-unauthenticated 
install --reinstall d-apt-keyring && sudo apt-get update


and install with

sudo apt-get install dmd-compiler dub

But unfortunately still the same core dump.

Is there anyone using Ubuntu 17.10 32 Bit?

I will downgrade to 16.04., the dist-upgrade to 17.10 was a 
mistake, resulting in problems with startx and newer kernels so I 
have to use 4.10.

Re: unable to fork: Cannot allocate memory / core.checkedint / gtkd

[Stefan Koch via Digitalmars-d-learn]

On Tuesday, 13 February 2018 at 14:10:44 UTC, number wrote:
Ok, thanks for the info. I guess I'll just use printf then for 
larger enums.


To get the same convince you can use.
the enumToString from:

https://forum.dlang.org/post/pnggoabnnkojdonyz...@forum.dlang.org

and writeln the result oft that.
however it'll cause an error if there are two enum memebrs with 
the same value.

Re: dmd-2.078.2 problems with Ubuntu 17.10 32Bit

[Jordi Sayol via Digitalmars-d-learn]

El 13/02/18 a les 08:03, Martin Tschierschke via Digitalmars-d-learn ha escrit:
> On Monday, 12 February 2018 at 21:18:01 UTC, Jordi Sayol wrote:
>> El 12/02/18 a les 21:56, Martin Tschierschke via Digitalmars-d-learn ha 
>> escrit:
>>> I just started to play around with D again on my notebook at home and 
>>> realized,
>>> that I have a broken installation.
>>> Even the minimal D "hello world" throws an error at execution.
>>> Speicherzugriffsfehler (Speicherabzug geschrieben) aka. core dump
>>>
>>> Compiling with ldc2 still works.
>>> Any hint?
>>>
>>>
>>>
>>
>> d-apt 
> 
> After setting ulimit -c unlimited to get the core dumped, I took a look with 
> gdb,
> to find a hint, now realizing, that it is probably the same problem as here:
> https://forum.dlang.org/thread/jjaynewwdsyntyehv...@forum.dlang.org?page=1
> 

A fresh install from d-apt on Ubuntu 16.04 32-bit, and everything worked fine.

test.d

import std.stdio;

void main()
{
writeln("Hello world!");
}


$ rdmd test.d 
Hello world!

$ dmd -run test.d 
Hello world!

Re: opCast cannot implicitly convert a.opCast of type X to Y

[aliak via Digitalmars-d-learn]

On Tuesday, 13 February 2018 at 12:12:30 UTC, Nathan S. wrote:

On Monday, 12 February 2018 at 02:05:16 UTC, aliak wrote:

struct B(T) {
T t;
}

struct A(T) {
T t;
auto opCast(U)() {
return B!U(cast(U)t);
}
}

void main() {
auto a = A!int(3);
auto b = cast(float)a; // error
}


Having the result of "cast(float) a" not be a float would be 
evil.


Ya :p dunno what I was thinking.

Re: dpq2: spurious error message

[Nicholas Wilson via Digitalmars-d-learn]

On Tuesday, 13 February 2018 at 17:17:41 UTC, Nicholas Wilson 
wrote:
On Tuesday, 13 February 2018 at 17:08:24 UTC, Nicholas Wilson 
wrote:
Is this a problem with the library or me? Can I work around 
it? How?


Thanks
Nic


So digging around in the library code, commenting it out seems 
to work for now as I don't use UUIDs. Error didn't originate 
from my code because it wasn't a template. I'm still surprised 
that it built and then errored in my code.


Ahh it requires vibe.d 0.8.2

Re: dpq2: spurious error message

[Nicholas Wilson via Digitalmars-d-learn]

On Tuesday, 13 February 2018 at 17:08:24 UTC, Nicholas Wilson 
wrote:
Is this a problem with the library or me? Can I work around it? 
How?


Thanks
Nic


So digging around in the library code, commenting it out seems to 
work for now as I don't use UUIDs. Error didn't originate from my 
code because it wasn't a template. I'm still surprised that it 
built and then errored in my code.

dpq2: spurious error message

[Nicholas Wilson via Digitalmars-d-learn]

import vibe.vibe;
import vibe.db.postgresql;

QueryParams p;
p.sqlCommand = "select 
title,url,url_title,messagebody,generationtime from items order 
by generationtime;";

auto _items = conn.execParams(p);

struct Range
{
 immutable Answer a;
  size_t i;
  immutable(Row) front() { return a[i]; }
  @property void popFront() { i++; }
  bool empty() { return i == a.length; }
}
auto items = Range(_items,0);
res.render!("items.dt", items); // usual vibe.d function

//items.dt
- import std.datetime.date;
- import dpq2.conv.time;
- import dpq2.conv.to_d_types;
- foreach(i; items)
item
title= i["title"].as!string
link= i["url"].as!string
description= i["messagebody"].as!string
pubDate= 
DateTimeToRfc822String(i["generationTime"].as!DateTime)


I get the following _two_ lots of the following error (between 
the ):

Compiling Diet HTML template rss.dt...
-
dpq2-1.0.0-alpha.7/dpq2/src/dpq2/conv/to_bson.d(143,23): Error: 
none of the overloads of '__ctor' are callable using argument 
types (UUID), candidates are:
vibe-d-0.7.32/vibe-d/source/vibe/data/bson.d(148,2):
vibe.data.bson.Bson.this(Type type, immutable(ubyte)[] data)
vibe-d-0.7.32/vibe-d/source/vibe/data/bson.d(185,2):
vibe.data.bson.Bson.this(double value)
vibe-d-0.7.32/vibe-d/source/vibe/data/bson.d(187,2):
vibe.data.bson.Bson.this(string value, Type type = 
cast(Type)cast(ubyte)2u)
vibe-d-0.7.32/vibe-d/source/vibe/data/bson.d(194,2):
vibe.data.bson.Bson.this(const(Bson[string]) value)
vibe-d-0.7.32/vibe-d/source/vibe/data/bson.d(196,2):
vibe.data.bson.Bson.this(const(Bson[]) value)
dpq2-1.0.0-alpha.7/dpq2/src/dpq2/conv/to_bson.d(143,23):
... (10 more, -v to show) ...

-
const(ubyte[]) Is not tested in integration tests!
UUID Is not tested in integration tests!
TTimeStamp!false Is not tested in integration tests!
Json Is not tested in integration tests!


Is this a problem with the library or me? Can I work around it? 
How?


Thanks
Nic

Re: rmdirRecurse - on NFS file system

[Seb via Digitalmars-d-learn]

On Tuesday, 13 February 2018 at 16:58:09 UTC, Vino wrote:

On Monday, 12 February 2018 at 06:52:25 UTC, Vino wrote:

[...]


Hi All,

Was able to resolve this issue.


That's great!

BTW I think it would be helpful for future reader who find this 
thread to know how you resolved your problem.

Re: rmdirRecurse - on NFS file system

[Vino via Digitalmars-d-learn]

On Monday, 12 February 2018 at 06:52:25 UTC, Vino wrote:

Hi All,

   Request your help, the below code works find on normal File 
system, bu if the file system is a NFS file system the below 
code, is not working


if Step = dryrun( Display Only) : Works for both NFS and normal 
file system.
if Step = run (Delete folder) : Does not work on NFS file 
system but works on normal file system.

No error message.

auto coAgedDirClean (string FFs, string Step, int AgeSize) {
auto cAges = AgeSize
auto dFiles = Array!(Tuple!(string, SysTime))(dirEntries(FFs, 
SpanMode.shallow).filter!(a => a.isDir && 
!globMatch(a.baseName, "*DND*") && a.timeCreated < 
cAges).map!(a => tuple(a.name, a.timeCreated)));
if (Step == "run") { dFiles.each!(f => f[0].rmdirRecurse); } 
return dFiles;

}

From,
Vino.B


Hi All,

Was able to resolve this issue.

Re: import strangeness with std.stdio.write

[Seb via Digitalmars-d-learn]

On Tuesday, 13 February 2018 at 16:55:10 UTC, ixid wrote:
On Tuesday, 13 February 2018 at 13:52:37 UTC, rikki cattermole 
wrote:

write exists in both, writeln exists only in std.stdio.

Use named imports to pick which write you want.


It does seem a little silly to have a name clash with such a 
commonly used function. Would it not be better to rename 
std.file.write to something like writeFile and deprecate the 
current name?


Yes, I think it would be worthwhile.
Especially that we will allow importing all of Phobos at once in 
2.079:



https://dlang.org/changelog/pending.html#std-experimental-scripting

Re: import strangeness with std.stdio.write

[ixid via Digitalmars-d-learn]

On Tuesday, 13 February 2018 at 13:52:37 UTC, rikki cattermole 
wrote:

write exists in both, writeln exists only in std.stdio.

Use named imports to pick which write you want.


It does seem a little silly to have a name clash with such a 
commonly used function. Would it not be better to rename 
std.file.write to something like writeFile and deprecate the 
current name?

Re: inout question

[Steven Schveighoffer via Digitalmars-d-learn]

On 2/12/18 12:33 AM, Norm wrote:

Hi,

I'm new to D so can someone explain to me what is happening here?


void func(const char* s, char** e) {
     import core.stdc.stdlib;
     auto result = strtod(s, e);
}

Error: function core.stdc.stdlib.strtod (scope inout(char)* nptr, scope 
inout(char)** endptr) is not callable using argument types 
(const(char*), char**)


I've found I have to use the following:

void func(inout (char)* s, inout(char)** e)


I thought inout was supposed to take const or non-const variants, so 
expected the original const char* s to work.




A way to think about inout, when you don't understand why you can't call 
it, is to think what inout *should* resolve to, and then see if you can 
assign the existing data to the parameter type.


For example, in this case, you are calling:

strtod(inout(char)* nptr, inout(char)** endptr) with const char *, and 
char **.


Since const char * and char ** vary on mutability, the compiler is going 
to try const in place of inout.


So try it out:

// replace inout with const
const(char)* nptr = s; // ok
const(char)** endptr = e; // Error

I wish the error message was more specific, it would have made things 
obvious. But due to overloading, it's really hard to create errors that 
are good explanations, but not too verbose.


-Steve

Re: import strangeness with std.stdio.write

[psychoticRabbit via Digitalmars-d-learn]

On Tuesday, 13 February 2018 at 14:21:31 UTC, bauss wrote:


What you can do is use aliases to use both functions.

import io = std.stdio;

void main()
{
import file = std.file;

file.write("hello");
io.writeln("hello again");
}


that's a nice simple solution.

thanks.

Re: import strangeness with std.stdio.write

[bauss via Digitalmars-d-learn]

On Tuesday, 13 February 2018 at 13:56:17 UTC, psychoticRabbit 
wrote:
On Tuesday, 13 February 2018 at 13:52:37 UTC, rikki cattermole 
wrote:

On 13/02/2018 1:46 PM, psychoticRabbit wrote:

So, strange problem below.

The commented-out line will not compile (if I un-comment it), 
unless I either move std.stdio into main, or, move std.file 
out of main.


Whereas writeln works just fine as is.

-
module test;

import std.stdio;

void main()
{
     import std.file;

     //write("hello");
     writeln("hello again");
}
---


write exists in both, writeln exists only in std.stdio.

Use named imports to pick which write you want.


oh..you must have posted as I why posting ;-)

That makes sense then. Thanks for clearing that up.

And I should have read the compiler message more clearly..cause 
the answer was in that error message (more or less)


What you can do is use aliases to use both functions.

import io = std.stdio;

void main()
{
import file = std.file;

file.write("hello");
io.writeln("hello again");
}

Re: import strangeness with std.stdio.write

[psychoticRabbit via Digitalmars-d-learn]

On Tuesday, 13 February 2018 at 14:18:05 UTC, ketmar wrote:

psychoticRabbit wrote:

Also, if I do this below, how does the compiler choose the 
correct write function?


import std.stdio;
import std.file;

void main()
{
 write("hello");
 writeln("hello again");
}


it's easy: just take a look at `std.file.write()`. first, it 
require two arguments. this is enough to rule 
`stf.file.write()` out in your case.


oh..function overloading..makes sense.

thanks again.

Re: import strangeness with std.stdio.write

[ketmar via Digitalmars-d-learn]

psychoticRabbit wrote:

Also, if I do this below, how does the compiler choose the correct write 
function?


import std.stdio;
import std.file;

void main()
{
 write("hello");
 writeln("hello again");
}


it's easy: just take a look at `std.file.write()`. first, it require two 
arguments. this is enough to rule `stf.file.write()` out in your case.

Re: import strangeness with std.stdio.write

[psychoticRabbit via Digitalmars-d-learn]

On Tuesday, 13 February 2018 at 13:57:38 UTC, ketmar wrote:
`std.file` has function named `write()` too. and local import 
completely shadows global imports (i.e. it removes global 
imports from overload set for the given scope), hence 
`std.stdio.write()` is not available there.


"..local import completely shadows global imports"

oh... I didn't realised imports are subject to scope rules in 
that way.


This new knowledge will certainly prevent some ongoing confusion 
;-)


thanks.

Also, if I do this below, how does the compiler choose the 
correct write function?


import std.stdio;
import std.file;

void main()
{
write("hello");
writeln("hello again");
}

Re: unable to fork: Cannot allocate memory / core.checkedint / gtkd

[number via Digitalmars-d-learn]

On Tuesday, 13 February 2018 at 12:32:58 UTC, Stefan Koch wrote:

On Tuesday, 13 February 2018 at 12:17:31 UTC, number wrote:



I just tried again.
compiling the following code eats up my 4GB of RAM and fails. 
Please copy the enumeration
from: 
https://github.com/gtkd-developers/GtkD/blob/master/generated/gtkd/gdk/Keysyms.d

into the code.


import std.stdio;

void main()
{
writeln(GdkKeysyms.GDK_Escape);
}

public enum GdkKeysyms
{
...
}


Reducing the number of enum entries step by step finally will 
make the compilation succeed. Is it normal that it needs so 
much memory?


Yes unfortunately std.conv approaches the problem of printing 
enums with recursive templates  , which eat a ton of memory.


Ok, thanks for the info. I guess I'll just use printf then for 
larger enums.

Re: import strangeness with std.stdio.write

[psychoticRabbit via Digitalmars-d-learn]

On Tuesday, 13 February 2018 at 13:52:37 UTC, rikki cattermole 
wrote:

On 13/02/2018 1:46 PM, psychoticRabbit wrote:

So, strange problem below.

The commented-out line will not compile (if I un-comment it), 
unless I either move std.stdio into main, or, move std.file 
out of main.


Whereas writeln works just fine as is.

-
module test;

import std.stdio;

void main()
{
     import std.file;

     //write("hello");
     writeln("hello again");
}
---


write exists in both, writeln exists only in std.stdio.

Use named imports to pick which write you want.


oh..you must have posted as I why posting ;-)

That makes sense then. Thanks for clearing that up.

And I should have read the compiler message more clearly..cause 
the answer was in that error message (more or less)

Re: import strangeness with std.stdio.write

[ketmar via Digitalmars-d-learn]

psychoticRabbit wrote:


So, strange problem below.

The commented-out line will not compile (if I un-comment it), unless I 
either move std.stdio into main, or, move std.file out of main.


Whereas writeln works just fine as is.

-
module test;

import std.stdio;

void main()
{
 import std.file;

 //write("hello");
 writeln("hello again");
}
---


`std.file` has function named `write()` too. and local import completely 
shadows global imports (i.e. it removes global imports from overload set 
for the given scope), hence `std.stdio.write()` is not available there.


this is done by purpose, so your code won't accidentally use wrong 
function. you can bring `std.stdio` functions back by adding local `import 
std.stdio;`, for example.

Re: import strangeness with std.stdio.write

[rikki cattermole via Digitalmars-d-learn]

On 13/02/2018 1:46 PM, psychoticRabbit wrote:

So, strange problem below.

The commented-out line will not compile (if I un-comment it), unless I 
either move std.stdio into main, or, move std.file out of main.


Whereas writeln works just fine as is.

-
module test;

import std.stdio;

void main()
{
     import std.file;

     //write("hello");
     writeln("hello again");
}
---


write exists in both, writeln exists only in std.stdio.

Use named imports to pick which write you want.

Re: import strangeness with std.stdio.write

[psychoticRabbit via Digitalmars-d-learn]

On Tuesday, 13 February 2018 at 13:46:11 UTC, psychoticRabbit 
wrote:

So, strange problem below.

The commented-out line will not compile (if I un-comment it), 
unless I either move std.stdio into main, or, move std.file out 
of main.


Whereas writeln works just fine as is.

-
module test;

import std.stdio;

void main()
{
import std.file;

//write("hello");
writeln("hello again");
}
---


I should add, that this problem seems directly related to 
std.file.


i.e. if I replace std.file, with say, std.conv, then the write 
function (once uncommented) will compile ok.

import strangeness with std.stdio.write

[psychoticRabbit via Digitalmars-d-learn]

So, strange problem below.

The commented-out line will not compile (if I un-comment it), 
unless I either move std.stdio into main, or, move std.file out 
of main.


Whereas writeln works just fine as is.

-
module test;

import std.stdio;

void main()
{
import std.file;

//write("hello");
writeln("hello again");
}
---

Re: unable to fork: Cannot allocate memory / core.checkedint / gtkd

[Stefan Koch via Digitalmars-d-learn]

On Tuesday, 13 February 2018 at 12:17:31 UTC, number wrote:

On Sunday, 11 February 2018 at 15:05:26 UTC, number wrote:

On Sunday, 11 February 2018 at 13:17:13 UTC, number wrote:

unable to fork: Cannot allocate memory

if i comment-out the line..
writeln(GdkKeysyms.GDK_Escape);

then it compiles/links/runs fine.




I just tried again.
compiling the following code eats up my 4GB of RAM and fails. 
Please copy the enumeration
from: 
https://github.com/gtkd-developers/GtkD/blob/master/generated/gtkd/gdk/Keysyms.d

into the code.


import std.stdio;

void main()
{
writeln(GdkKeysyms.GDK_Escape);
}

public enum GdkKeysyms
{
...
}


Reducing the number of enum entries step by step finally will 
make the compilation succeed. Is it normal that it needs so 
much memory?


Yes unfortunately std.conv approaches the problem of printing 
enums with recursive templates  , which eat a ton of memory.

Re: unable to fork: Cannot allocate memory / core.checkedint / gtkd

[number via Digitalmars-d-learn]

On Sunday, 11 February 2018 at 15:05:26 UTC, number wrote:

On Sunday, 11 February 2018 at 13:17:13 UTC, number wrote:

unable to fork: Cannot allocate memory

if i comment-out the line..
writeln(GdkKeysyms.GDK_Escape);

then it compiles/links/runs fine.




I just tried again.
compiling the following code eats up my 4GB of RAM and fails. 
Please copy the enumeration
from: 
https://github.com/gtkd-developers/GtkD/blob/master/generated/gtkd/gdk/Keysyms.d

into the code.


import std.stdio;

void main()
{
writeln(GdkKeysyms.GDK_Escape);
}

public enum GdkKeysyms
{
...
}


Reducing the number of enum entries step by step finally will 
make the compilation succeed. Is it normal that it needs so much 
memory?

Re: opCast cannot implicitly convert a.opCast of type X to Y

[Nathan S. via Digitalmars-d-learn]

On Monday, 12 February 2018 at 02:05:16 UTC, aliak wrote:

struct B(T) {
T t;
}

struct A(T) {
T t;
auto opCast(U)() {
return B!U(cast(U)t);
}
}

void main() {
auto a = A!int(3);
auto b = cast(float)a; // error
}


Having the result of "cast(float) a" not be a float would be evil.

Re: No error message in DMD 2.078.2

[ag0aep6g via Digitalmars-d-learn]

On 02/13/2018 06:51 AM, Domain wrote:

module main;

void main ()
{
     writeln("Hello");
}

Of course, this won't compile, but error message is confused:

C:\Git\hello\source>dmd app.d
app.d(5): Error:
object.Error@(0): Access Violation


This is issue 18403. You should see an error message with some 
highlighted code, but dmd crashes when it tries to print that. You can 
invoke dmd with `-color=off` to work around the issue, or go back to 
2.078.1 until we get a release with the fix.


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