Re: Embed files into binary.

[rikki cattermole via Digitalmars-d-learn]

On 06/06/2016 5:07 PM, Pie? wrote:

On Monday, 6 June 2016 at 03:23:02 UTC, rikki cattermole wrote:

On 06/06/2016 3:11 PM, Pie? wrote:

On Monday, 6 June 2016 at 02:34:07 UTC, Adam D. Ruppe wrote:

On Monday, 6 June 2016 at 02:05:09 UTC, Pie? wrote:

I believe the essentially converted the file into a ubyte or
something and then wrote that out to a temp file and read in the temp
file... this seems a bit of a kludge to me.


They might do that for certain special cases, but
import("file.whatever") just drops the file content in memory and you
can then access it as an array.


Because D allows such an embedding feature, maybe the file system
should allow working with this concept?


Why do you need it through the file system? If you're writing the
code, just use the array in memory. If it is external, see if the
library offers something like that.

DLL and exe are a special case, most things don't need to be physical
files.


Because, as I said, if I'm working with pre-exiting modules that work
with file, I have to provide a file or modify the source.

e.g., how could I do this easily with your read in your png module? It
takes a file..

/// Easily reads a png file into a MemoryImage
MemoryImage readPng(string filename) {
import std.file;
return imageFromPng(readPng(cast(ubyte[]) read(filename)));

recognize the code?

Of course, like I said, it can be modified in this case, but that means
nothing in general.



ubyte[] theArray = import("...");
MemoryImage img = imageFromPng(readPng(theArray));

And that's just from the snippet you provided.
Yay overloads!


Yes, I figured it could be done because of the MemoryImage, but that
wasn't the point.  You are delving in to code that you might not
normally have access or might not exist.

Adam wrote the MemoryImage that essentially does this but that is not
the general case.

Image if all you access to was readPng(string filename), then what would
you say? That was my point of posting the code, I didn't mean for you to
go look and see if it was possible to achieve what I was saying in
arsd(Formally known as Adam Druppe) git repository ;)


Then I would say go get a new image library as that one isn't a very 
good one.


..snip..

Right got rid of all that text.
If you want to make the filesystem appear to have files it doesn't, 
you'll need a virtual file system library.


Welcome to the next issue, getting libraries to support it ;)

Re: Why I can't catch the exception?

[Piotrek via Digitalmars-d-learn]

On Sunday, 5 June 2016 at 18:20:12 UTC, Era Scarecrow wrote:
 The assertion is being thrown in the storage.d and 
backtracking it basically points to line 115 (usersCollection), 
so am going to guess based on error messages alone that you are 
passing a struct/class that doesn't match inputs that it is 
expecting for one of the elements it needs to store.


 So my advice is to look at the User struct/class, and then 
look at the DB's User table. But this is just a far thrown 
guess at the problem.


You are very close. This is just a limitation of the current 
database code which can only handle the simplest structs.


https://gitlab.com/PiotrekDlang/DraftLib/issues/4

Piotrek

Re: Embed files into binary.

[Pie? via Digitalmars-d-learn]

On Monday, 6 June 2016 at 03:23:02 UTC, rikki cattermole wrote:

On 06/06/2016 3:11 PM, Pie? wrote:

On Monday, 6 June 2016 at 02:34:07 UTC, Adam D. Ruppe wrote:

On Monday, 6 June 2016 at 02:05:09 UTC, Pie? wrote:

I believe the essentially converted the file into a ubyte or
something and then wrote that out to a temp file and read in 
the temp

file... this seems a bit of a kludge to me.


They might do that for certain special cases, but
import("file.whatever") just drops the file content in memory 
and you

can then access it as an array.

Because D allows such an embedding feature, maybe the file 
system

should allow working with this concept?


Why do you need it through the file system? If you're writing 
the
code, just use the array in memory. If it is external, see if 
the

library offers something like that.

DLL and exe are a special case, most things don't need to be 
physical

files.


Because, as I said, if I'm working with pre-exiting modules 
that work

with file, I have to provide a file or modify the source.

e.g., how could I do this easily with your read in your png 
module? It

takes a file..

/// Easily reads a png file into a MemoryImage
MemoryImage readPng(string filename) {
import std.file;
return imageFromPng(readPng(cast(ubyte[]) read(filename)));

recognize the code?

Of course, like I said, it can be modified in this case, but 
that means

nothing in general.



ubyte[] theArray = import("...");
MemoryImage img = imageFromPng(readPng(theArray));

And that's just from the snippet you provided.
Yay overloads!


Yes, I figured it could be done because of the MemoryImage, but 
that wasn't the point.  You are delving in to code that you might 
not normally have access or might not exist.


Adam wrote the MemoryImage that essentially does this but that is 
not the general case.


Image if all you access to was readPng(string filename), then 
what would you say? That was my point of posting the code, I 
didn't mean for you to go look and see if it was possible to 
achieve what I was saying in arsd(Formally known as Adam Druppe) 
git repository ;)


If that was the case I would have titled this something similar 
not but maybe not exactly equivalent(Just being pedantic since we 
seem to be having a communications gap in how accurate and 
precise our expressions are to be interpreted): "Possible to get 
arsd(Formally known as Adam Druppe) readpng lib to read from 
import(filename)?".


Since I was desiring to arrive at a more general solution to 
potential future programming goals, I phrased my question in more 
general terms. I assumed that this would be understood. (i.e., 
vague questions generally gets/desires vague results, intelligent 
questions generally get/desires intelligent results, etc.)


In fact, I posted the most generic(and possibly vague) question I 
could:


"Embed files into binary."  I stated, but not exclaimed or 
questioned(as these are in theory, mutually exclusive), in the 
subject line!


But this is no question! It is a riddle my friend! By stating it 
in such a way as to only imply the logical consequent "How to use 
embedded files in the binary"[Of course, with an infinite number 
of assumptions mixed in for spice]!


Why is this a necessary forgone conclusion, as Einstein would 
some times say(not to me in particular, mind you)?  Because there 
is no point to embed files in a binary if one can not use them!!!


Naturally, this is why I further said, in a round about way, why 
exporting them to temp files is not really an option. This was 
further to exclude, if you are keeping track with your Venn 
Diagram, something akin to the infinite monkey theorem... or a 
breach in the space time continuum or just several responses 
about along the lines "...save the data to a temp file and use 
that".


Note my retort:

" Because D allows such an embedding feature, maybe the file

system
should allow working with this concept?"


Asking about future events and possibly space-time paradoxes!

For example, what if I derive some source code from some 
unexpected places and they have some complex way of using D's 
std.file routines and offers no interface to use memory arrays as 
an input? Suppose further that it is very contorted and only 
Steven Hawkins has figured out how to unravel the complexities of 
the law of import/export. We are not privy to his knowledge or 
intellectual properties. Would it not be intelligent and 
forthright, mimicking Steven Hawkins in a sort of motherly 
daughterly bond kind of way, to see that we must write new code 
to solve the problem... this timing mimicking God himself as he 
bought forth the earth and heaven?



Does that make sense?

Re: Embed files into binary.

[Adam D. Ruppe via Digitalmars-d-learn]

On Monday, 6 June 2016 at 03:11:32 UTC, Pie? wrote:
e.g., how could I do this easily with your read in your png 
module? It takes a file..


/// Easily reads a png file into a MemoryImage
MemoryImage readPng(string filename) {
import std.file;
return imageFromPng(readPng(cast(ubyte[]) read(filename)));

recognize the code?



The string version just forwards to the byte array version. So 
you can use it directly with the array by just casting to ubyte[].


rikki cattermole got it right, except I *think* the cast(ubyte[]) 
needs to be explicit on the import line, so


ubyte[] theArray = cast(ubyte[]) import("...");

(Actually, the string one is an afterthought, I originally wrote 
it to only work with arrays (well, technically, input ranges of 
bytes), leaving the file reading to an outside function, but 
since loading a file from a filename is so common, I added the 
overload for it.)

Re: Embed files into binary.

[rikki cattermole via Digitalmars-d-learn]

On 06/06/2016 3:11 PM, Pie? wrote:

On Monday, 6 June 2016 at 02:34:07 UTC, Adam D. Ruppe wrote:

On Monday, 6 June 2016 at 02:05:09 UTC, Pie? wrote:

I believe the essentially converted the file into a ubyte or
something and then wrote that out to a temp file and read in the temp
file... this seems a bit of a kludge to me.


They might do that for certain special cases, but
import("file.whatever") just drops the file content in memory and you
can then access it as an array.


Because D allows such an embedding feature, maybe the file system
should allow working with this concept?


Why do you need it through the file system? If you're writing the
code, just use the array in memory. If it is external, see if the
library offers something like that.

DLL and exe are a special case, most things don't need to be physical
files.


Because, as I said, if I'm working with pre-exiting modules that work
with file, I have to provide a file or modify the source.

e.g., how could I do this easily with your read in your png module? It
takes a file..

/// Easily reads a png file into a MemoryImage
MemoryImage readPng(string filename) {
import std.file;
return imageFromPng(readPng(cast(ubyte[]) read(filename)));

recognize the code?

Of course, like I said, it can be modified in this case, but that means
nothing in general.



ubyte[] theArray = import("...");
MemoryImage img = imageFromPng(readPng(theArray));

And that's just from the snippet you provided.
Yay overloads!

Re: Linker error

[Anonymous via Digitalmars-d-learn]

On Monday, 6 June 2016 at 02:21:03 UTC, docandrew wrote:

On Sunday, 5 June 2016 at 21:26:56 UTC, Anonymous wrote:

On Sunday, 5 June 2016 at 21:16:36 UTC, Andrej Mitrovic wrote:
On 6/5/16, Anonymous via Digitalmars-d-learn 
 wrote:

[...]


You can report it here: https://issues.dlang.org


[...]


null is simpler from a reader's perspective. :)


[...]


Interesting that they would use such code in the book. Which 
chapter is it?


Thanks. I agree it's simpler and switched to `null`.

The example is in chapter 3.


That it works on OSX but not on Windows makes me think it 
should definitely be reported as a bug.


-Jon


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

Re: Embed files into binary.

[Pie? via Digitalmars-d-learn]

On Monday, 6 June 2016 at 02:34:07 UTC, Adam D. Ruppe wrote:

On Monday, 6 June 2016 at 02:05:09 UTC, Pie? wrote:
I believe the essentially converted the file into a ubyte or 
something and then wrote that out to a temp file and read in 
the temp file... this seems a bit of a kludge to me.


They might do that for certain special cases, but 
import("file.whatever") just drops the file content in memory 
and you can then access it as an array.


Because D allows such an embedding feature, maybe the file 
system should allow working with this concept?


Why do you need it through the file system? If you're writing 
the code, just use the array in memory. If it is external, see 
if the library offers something like that.


DLL and exe are a special case, most things don't need to be 
physical files.


Because, as I said, if I'm working with pre-exiting modules that 
work with file, I have to provide a file or modify the source.


e.g., how could I do this easily with your read in your png 
module? It takes a file..


/// Easily reads a png file into a MemoryImage
MemoryImage readPng(string filename) {
import std.file;
return imageFromPng(readPng(cast(ubyte[]) read(filename)));

recognize the code?

Of course, like I said, it can be modified in this case, but that 
means nothing in general.

Re: Embed files into binary.

[Adam D. Ruppe via Digitalmars-d-learn]

On Monday, 6 June 2016 at 02:05:09 UTC, Pie? wrote:
I believe the essentially converted the file into a ubyte or 
something and then wrote that out to a temp file and read in 
the temp file... this seems a bit of a kludge to me.


They might do that for certain special cases, but 
import("file.whatever") just drops the file content in memory and 
you can then access it as an array.


Because D allows such an embedding feature, maybe the file 
system should allow working with this concept?


Why do you need it through the file system? If you're writing the 
code, just use the array in memory. If it is external, see if the 
library offers something like that.


DLL and exe are a special case, most things don't need to be 
physical files.

Re: Embed files into binary.

[Pie? via Digitalmars-d-learn]

On Monday, 6 June 2016 at 02:18:48 UTC, docandrew wrote:

On Monday, 6 June 2016 at 02:05:09 UTC, Pie? wrote:
I saw somewhere someone explaining how to embed resources into 
a binary using the import keyword.


I believe the essentially converted the file into a ubyte or 
something and then wrote that out to a temp file and read in 
the temp file... this seems a bit of a kludge to me.


Is it possible to do the same, but create a sort of "in 
memory" file layout?


While I can modify my own routines to read the "file" from 
memory, I can't do that easily with outside code(I could 
modify the binaries).


Basically reading a file has to read it to memory, and if the 
file data already exists in memory, there is no point to read, 
just get it direct.


Any thoughts on this?

Because D allows such an embedding feature, maybe the file 
system should allow working with this concept? That way, it 
becomes VERY easy to embed files into the binary and work with 
them like they wernt. Also, going between the two different 
versions(embedded vs not) could be done with version (Release).


I'm not sure about import, but one option is to put the 
external files directly in your binary as part of the linker 
step. Check out:


http://www.linuxjournal.com/content/embedding-file-executable-aka-hello-world-version-5967

On Windows I think there's a way to embed files in .DLLs and 
then link those into your executable, but I'm ignorant of the 
steps/tools required.


-Jon


Check out https://p0nce.github.io/d-idioms/ for embedding dll's.

It's much easier than using the link you give.

The problem is the same though, How to use the in memory data 
rather than re-reading it? It's not a problem of embedding but 
that the routines that use the data expect files, not memory 
backed virtual files.

Re: Linker error

[docandrew via Digitalmars-d-learn]

On Sunday, 5 June 2016 at 21:26:56 UTC, Anonymous wrote:

On Sunday, 5 June 2016 at 21:16:36 UTC, Andrej Mitrovic wrote:
On 6/5/16, Anonymous via Digitalmars-d-learn 
 wrote:
Should I report this as a dmd bug then? Not sure where / how 
to do that.


You can report it here: https://issues.dlang.org

I think I'll just let it go; I was able to work passed it 
anyway using "static Note[] empty;", and `null` works too. Is 
either one better?


null is simpler from a reader's perspective. :)

By the way, this is from an example I found in "D Web 
Development" by Kai Nacke.


Interesting that they would use such code in the book. Which 
chapter is it?


Thanks. I agree it's simpler and switched to `null`.

The example is in chapter 3.


That it works on OSX but not on Windows makes me think it should 
definitely be reported as a bug.


-Jon

Re: Embed files into binary.

[docandrew via Digitalmars-d-learn]

On Monday, 6 June 2016 at 02:05:09 UTC, Pie? wrote:
I saw somewhere someone explaining how to embed resources into 
a binary using the import keyword.


I believe the essentially converted the file into a ubyte or 
something and then wrote that out to a temp file and read in 
the temp file... this seems a bit of a kludge to me.


Is it possible to do the same, but create a sort of "in memory" 
file layout?


While I can modify my own routines to read the "file" from 
memory, I can't do that easily with outside code(I could modify 
the binaries).


Basically reading a file has to read it to memory, and if the 
file data already exists in memory, there is no point to read, 
just get it direct.


Any thoughts on this?

Because D allows such an embedding feature, maybe the file 
system should allow working with this concept? That way, it 
becomes VERY easy to embed files into the binary and work with 
them like they wernt. Also, going between the two different 
versions(embedded vs not) could be done with version (Release).


I'm not sure about import, but one option is to put the external 
files directly in your binary as part of the linker step. Check 
out:


http://www.linuxjournal.com/content/embedding-file-executable-aka-hello-world-version-5967

On Windows I think there's a way to embed files in .DLLs and then 
link those into your executable, but I'm ignorant of the 
steps/tools required.


-Jon

Embed files into binary.

[Pie? via Digitalmars-d-learn]

I saw somewhere someone explaining how to embed resources into a 
binary using the import keyword.


I believe the essentially converted the file into a ubyte or 
something and then wrote that out to a temp file and read in the 
temp file... this seems a bit of a kludge to me.


Is it possible to do the same, but create a sort of "in memory" 
file layout?


While I can modify my own routines to read the "file" from 
memory, I can't do that easily with outside code(I could modify 
the binaries).


Basically reading a file has to read it to memory, and if the 
file data already exists in memory, there is no point to read, 
just get it direct.


Any thoughts on this?

Because D allows such an embedding feature, maybe the file system 
should allow working with this concept? That way, it becomes VERY 
easy to embed files into the binary and work with them like they 
wernt. Also, going between the two different versions(embedded vs 
not) could be done with version (Release).

Re: How to enable feedback for AssertError?

[Ali Çehreli via Digitalmars-d-learn]

On 06/05/2016 07:39 AM, your_name wrote:

> The problem I have is whenever an assert in my debug build fails the
> program or thread is just killed silently.

That's strange. When an assertion fails, the stack trace is printed and 
the program is terminated. For example:


void fun(int i) {
assert(i == 7);
}

void main() {
fun(42);
}

That program fails loudly :) with something similar to the following:

core.exception.AssertError@deneme.d(2): Assertion failure

??:? _d_assert [0x422b9b]
??:? void deneme.__assert(int) [0x422acc]
??:? void deneme.fun(int) [0x422a62]
??:? _Dmain [0x422a75]
??:? _D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZ9__lambda1MFZv 
[0x423012]
??:? void rt.dmain2._d_run_main(int, char**, extern (C) int 
function(char[][])*).tryExec(scope void delegate()) [0x422f5c]
??:? void rt.dmain2._d_run_main(int, char**, extern (C) int 
function(char[][])*).runAll() [0x422fce]
??:? void rt.dmain2._d_run_main(int, char**, extern (C) int 
function(char[][])*).tryExec(scope void delegate()) [0x422f5c]

??:? _d_run_main [0x422ecd]
??:? main [0x422b05]
??:? __libc_start_main [0x30ea082f]

If you want to prevent termination, it is possible but not recommended 
to catch and swallow AssertError (or Error, or Throwable):


import core.exception;

void fun(int i) {
assert(i == 7);
}

void main() {
try {
fun(42);

} catch (AssertError) {
// Something bad happened. We can't trust the state
// of this program any more.
}
}

As noted, when an Error is thrown, you can't know whether the program 
can do anything correctly any more.


Ali

Re: Linker error

[Anonymous via Digitalmars-d-learn]

On Sunday, 5 June 2016 at 21:16:36 UTC, Andrej Mitrovic wrote:
On 6/5/16, Anonymous via Digitalmars-d-learn 
 wrote:
Should I report this as a dmd bug then? Not sure where / how 
to do that.


You can report it here: https://issues.dlang.org

I think I'll just let it go; I was able to work passed it 
anyway using "static Note[] empty;", and `null` works too. Is 
either one better?


null is simpler from a reader's perspective. :)

By the way, this is from an example I found in "D Web 
Development" by Kai Nacke.


Interesting that they would use such code in the book. Which 
chapter is it?


Thanks. I agree it's simpler and switched to `null`.

The example is in chapter 3.

Re: Speed up `dub`.

[Andrej Mitrovic via Digitalmars-d-learn]

On Thursday, 2 June 2016 at 13:04:00 UTC, ciechowoj wrote:
and found that an assert from `std/path.d:3168` (`globMatch`) 
contributes a major amount to the running time of dub.


```
assert(balancedParens(pattern, '[', ']', 0));
assert(balancedParens(pattern, '{', '}', 0));
```


Hmm.. that sounds like the dub binary that's distributed is 
running its unittests at start. If that's true I don't think they 
should be part of the released binary..

Re: Linker error

[Andrej Mitrovic via Digitalmars-d-learn]

On 6/5/16, Anonymous via Digitalmars-d-learn
 wrote:
> Should I report this as a dmd bug then? Not sure where / how to
> do that.

You can report it here: https://issues.dlang.org

> I think I'll just let it go; I was able to work passed it anyway
> using "static Note[] empty;", and `null` works too. Is either one
> better?

null is simpler from a reader's perspective. :)

> By the way, this is from an example I found in "D Web
> Development" by Kai Nacke.

Interesting that they would use such code in the book. Which chapter is it?

Re: Linker error

[Anonymous via Digitalmars-d-learn]

On Sunday, 5 June 2016 at 20:16:54 UTC, Andrej Mitrovic wrote:
On 6/5/16, Anonymous via Digitalmars-d-learn 
 wrote:

static Note[0] empty;

Note[] getNotes(string id)
{
return (id in store) ? store[id] : empty;
}


It's likely an accepts-invalid bug, meaning it should be a 
compiler error instead. I don't think it makes sense that the 
compiler tries to slice a fixed-length array of length zero.. 
tho perhaps it should just equate that to returning null.


In any case you can return `null` instead of "empty". 
Fixed-length arrays of length zero aren't really all that 
well-defined. Some would say they make no sense, but there is a 
weird benefit to them when used with the built-in hashmaps (a 
void[0] value type wouldn't allocate memory, AFAIR and if that 
is still true).


Should I report this as a dmd bug then? Not sure where / how to 
do that.


I think I'll just let it go; I was able to work passed it anyway 
using "static Note[] empty;", and `null` works too. Is either one 
better?


By the way, this is from an example I found in "D Web 
Development" by Kai Nacke.

Re: Linker error

[Andrej Mitrovic via Digitalmars-d-learn]

On 6/5/16, Anonymous via Digitalmars-d-learn
 wrote:
>   static Note[0] empty;
>   
>   Note[] getNotes(string id)
>   {
>   return (id in store) ? store[id] : empty;
>   }   

It's likely an accepts-invalid bug, meaning it should be a compiler
error instead. I don't think it makes sense that the compiler tries to
slice a fixed-length array of length zero.. tho perhaps it should just
equate that to returning null.

In any case you can return `null` instead of "empty". Fixed-length
arrays of length zero aren't really all that well-defined. Some would
say they make no sense, but there is a weird benefit to them when used
with the built-in hashmaps (a void[0] value type wouldn't allocate
memory, AFAIR and if that is still true).

Re: Linker error

[Anonymous via Digitalmars-d-learn]

On Sunday, 5 June 2016 at 18:45:36 UTC, docandrew wrote:

On Sunday, 5 June 2016 at 18:36:13 UTC, Anonymous wrote:

On Sunday, 5 June 2016 at 18:30:25 UTC, Anonymous wrote:

[...]


Should have included:

OPTLINK (R) for Win32  Release 8.00.17
Copyright (C) Digital Mars 1989-2013  All rights reserved.
http://www.digitalmars.com/ctg/optlink.html
ns.obj(ns)  Offset 0BA0AH Record Type 009D
 Error 16: Index Range
--- errorlevel 1


Hmm, on OSX w/ dmd v2.071.0 I'm unable to duplicate. Can you 
try upgrading to v2.071 and see if that works?


-Jon


I upgraded, but I still get the same error:

dmd ns.d

 OPTLINK (R) for Win32  Release 8.00.17
 Copyright (C) Digital Mars 1989-2013  All rights reserved.
 http://www.digitalmars.com/ctg/optlink.html
 ns.obj(ns)  Offset 00678H Record Type 009D
  Error 16: Index Range
 --- errorlevel 1

dmd --version
DMD32 D Compiler v2.071.0
Copyright (c) 1999-2015 by Digital Mars written by Walter Bright

Re: Linker error

[docandrew via Digitalmars-d-learn]

On Sunday, 5 June 2016 at 18:36:13 UTC, Anonymous wrote:

On Sunday, 5 June 2016 at 18:30:25 UTC, Anonymous wrote:

[...]


Should have included:

OPTLINK (R) for Win32  Release 8.00.17
Copyright (C) Digital Mars 1989-2013  All rights reserved.
http://www.digitalmars.com/ctg/optlink.html
ns.obj(ns)  Offset 0BA0AH Record Type 009D
 Error 16: Index Range
--- errorlevel 1


Hmm, on OSX w/ dmd v2.071.0 I'm unable to duplicate. Can you try 
upgrading to v2.071 and see if that works?


-Jon

Re: Linker error

[Anonymous via Digitalmars-d-learn]

On Sunday, 5 June 2016 at 18:30:25 UTC, Anonymous wrote:

Why does the following give a linker error?

If I change static Note[0] empty; to static Note[] empty;, all 
is well.
Or if I leave it as Note[0] empty; and don't use it in 
getNotes, all is well.


struct Note
{
string topic;
string content;
}

class NoteStore
{   

Note[][string] store;

static Note[0] empty;

Note[] getNotes(string id)
{
return (id in store) ? store[id] : empty;
}   
}

void main() {}

dmd --version
DMD32 D Compiler v2.070.0
Windows 10


Should have included:

OPTLINK (R) for Win32  Release 8.00.17
Copyright (C) Digital Mars 1989-2013  All rights reserved.
http://www.digitalmars.com/ctg/optlink.html
ns.obj(ns)  Offset 0BA0AH Record Type 009D
 Error 16: Index Range
--- errorlevel 1

Linker error

[Anonymous via Digitalmars-d-learn]

Why does the following give a linker error?

If I change static Note[0] empty; to static Note[] empty;, all is 
well.
Or if I leave it as Note[0] empty; and don't use it in getNotes, 
all is well.


struct Note
{
string topic;
string content;
}

class NoteStore
{   

Note[][string] store;

static Note[0] empty;

Note[] getNotes(string id)
{
return (id in store) ? store[id] : empty;
}   
}

void main() {}

dmd --version
DMD32 D Compiler v2.070.0
Windows 10

Re: Why I can't catch the exception?

[Era Scarecrow via Digitalmars-d-learn]

On Sunday, 5 June 2016 at 18:15:47 UTC, Adam D. Ruppe wrote:

On Sunday, 5 June 2016 at 18:02:12 UTC, Suliman wrote:
I really can't understand why try-catch block do not handle 
exception.
digit 1 is printing, so exception is accrue after it, but why 
nothing in catch block?


http://img.ctrlv.in/img/16/06/05/57546861d8e81.png

catch(Exception e)



You are catching Exception, but it is throwing Error. They are 
two separate things.


You shouldn't typically catch Error, instead try to fix the bug 
it indicates. But you can if you want by catch(Error e)



 The assertion is being thrown in the storage.d and backtracking 
it basically points to line 115 (usersCollection), so am going to 
guess based on error messages alone that you are passing a 
struct/class that doesn't match inputs that it is expecting for 
one of the elements it needs to store.


 So my advice is to look at the User struct/class, and then look 
at the DB's User table. But this is just a far thrown guess at 
the problem.

Re: Why I can't catch the exception?

[ag0aep6g via Digitalmars-d-learn]

On 06/05/2016 08:02 PM, Suliman wrote:

I really can't understand why try-catch block do not handle exception.
digit 1 is printing, so exception is accrue after it, but why nothing in
catch block?

http://img.ctrlv.in/img/16/06/05/57546861d8e81.png

Here is my code:

void dbSetup()
{
 try
 {

[...]

 }

 catch(Exception e)
 {
 writeln("Can't setup DB");
 writeln(e.msg);
 }

}


An AssertError is not an Exception (in the narrow sense) [1], but an 
Error. Both Exception and Error [2] derive from Throwable [3].


An Error signals an unrecoverable problem. You should not try to catch 
and handle them.


An AssertError in particular is thrown when an `assert` fails. In your 
case the assert is in database\storage.d, line 312. A failing assert 
signals means that there's an error in the program. A condition is not 
met that should be met at all times.


The compiler will let you catch Error and Throwable, but you really 
shouldn't do that. Instead fix your code so that it doesn't fail the assert.



[1] http://dlang.org/phobos/object.html#.Exception
[2] http://dlang.org/phobos/object.html#.Error
[3] http://dlang.org/phobos/object.html#.Throwable

Re: Why I can't catch the exception?

[Adam D. Ruppe via Digitalmars-d-learn]

On Sunday, 5 June 2016 at 18:02:12 UTC, Suliman wrote:
I really can't understand why try-catch block do not handle 
exception.
digit 1 is printing, so exception is accrue after it, but why 
nothing in catch block?


http://img.ctrlv.in/img/16/06/05/57546861d8e81.png



catch(Exception e)



You are catching Exception, but it is throwing Error. They are 
two separate things.


You shouldn't typically catch Error, instead try to fix the bug 
it indicates. But you can if you want by catch(Error e)

Why I can't catch the exception?

[Suliman via Digitalmars-d-learn]

I really can't understand why try-catch block do not handle 
exception.
digit 1 is printing, so exception is accrue after it, but why 
nothing in catch block?


http://img.ctrlv.in/img/16/06/05/57546861d8e81.png

Here is my code:

void dbSetup()
{
try
{
//getcwd do not return correct path if run from task 
shoulder
string dbpath = 
buildPath((thisExePath[0..((thisExePath.lastIndexOf("\\"))+1)]), 
dbname);

if(!dbpath.exists)
{
writeln("It's seems you are runnining Application 
first time\n You should set up admin password");

auto db = DataBase(dbname);
writeln("1");
auto usersCollection = db.collection!User("Users", 
true); // base on struct User
usersCollection.put(User(0, "admin", "123", 
"admins")); // defaults

writeln("2");
writeln("[INFO] db with default credentials created");
}

else
{
writeln("[INFO] db exists");
return;
}
}

catch(Exception e)
{
writeln("Can't setup DB");
writeln(e.msg);
}

}

I am using https://gitlab.com/PiotrekDlang/DraftLib/

How to enable feedback for AssertError?

[your_name via Digitalmars-d-learn]

Hello,

thanks for reading this.

The problem I have is whenever an assert in my debug build fails 
the program or thread is just killed silently.


How can I change this behavior to something akin to SIGSEGV ?

Thanks!

Re: throw Exception with custom message in nogc code

[HubCool via Digitalmars-d-learn]

On Sunday, 5 June 2016 at 10:37:49 UTC, poliklosio wrote:

On Sunday, 5 June 2016 at 06:25:28 UTC, HubCool wrote:
Can you elaborate on how to dispose the exception?
I'm partilularly interested in the code you would write in 
place of the /*can dispose here too...*/ comment.


I don't know from where this idea came, I've never seen this, is 
it allowed ?


If so, dispose is not @nogc but since exceptions are quite simple 
classes they can be cleaned by hand without calling the ctor 
(since there's no ctor...). just Malloc.instance.dispose() would 
be enough. Even the size is not required (though it can also be 
retrieved with typeid().initializer.length.

Re: throw Exception with custom message in nogc code

[poliklosio via Digitalmars-d-learn]

On Sunday, 5 June 2016 at 10:37:49 UTC, poliklosio wrote:
Also, exceptions are not necessarily for bugs. There may be 
used sometimes for bug handling when other things like static 
typing and assertions are not enough, but bug handling is not 
the core reason for havi ng exceptions in languages.


Actually, in D, things like assertions already behave like 
exceptions jumping up the call stack and generating stack traces 
so there should be no reason to ever use normal exceptions to 
handle programmer mistakes. I like this language a little bit 
more every day I use it.

Re: throw Exception with custom message in nogc code

[poliklosio via Digitalmars-d-learn]

On Sunday, 5 June 2016 at 06:25:28 UTC, HubCool wrote:

(...)
But I'd say that the leak doesn't matter. Either the soft has a 
very small problem that happens once eventually, otherwise it's 
a big bug and new exceptions will come so often that the 
program has to be killed immediatly.


+--+
auto leakAnoGcException(T, A...)(A a) @nogc
if (is(T: Exception))
{
import std.experimental.allocator.mallocator;
import std.experimental.allocator;
return make!T(Mallocator.instance, a);
// eventually stores them ona stack that you can free in 
static ~this()

}

void main() @nogc
{
bool ouch;
class MyException: Exception {this(string m) @nogc 
{super(m);}}

try throw leakAnoGcException!MyException("ouch");
catch (Exception e) {ouch = true;/*can dispose here 
too...*/}

assert(ouch);
}
+--+


I like your solution, as it doesn't force to allocate exception 
objects statically, which is a step forward.


On the other hand I don't think that the leak doesn't matter. 
This would only be the case if one could guarantee that only a 
small, constant number of exceptions is thrown during program 
execution. This is not generally the case. Also, exceptions are 
not necessarily for bugs. There may be used sometimes for bug 
handling when other things like static typing and assertions are 
not enough, but bug handling is not the core reason for havi ng 
exceptions in languages.
Exceptions is a control flow construct for use in events which 
occur rarely (relative to normal execution of surrounding code) 
and require jumping many levels up the call stack. That's all 
there is to them. Its not some philosophical concept that depends 
on the definition of errors or bugs.


Can you elaborate on how to dispose the exception?
I'm partilularly interested in the code you would write in place 
of the /*can dispose here too...*/ comment.

Re: Speed up `dub`.

[Jacob Carlborg via Digitalmars-d-learn]

On 04/06/16 10:04, Russel Winder via Digitalmars-d-learn wrote:


Dub must check all dependencies before starting a build, the question
is whether is should download and build them or just fail.


Yeah, I meant check online.

--
/Jacob Carlborg

Re: Object.factory fails for static libraries

[Andre Pany via Digitalmars-d-learn]

On Sunday, 5 June 2016 at 08:40:18 UTC, Andre Pany wrote:

On Saturday, 4 June 2016 at 16:12:04 UTC, Andre Pany wrote:

Hi,

I try to create objects by using the factory method in a 
static library scenario.


...
I just validated, the same issue also occurs on ubuntu linux 
with the recent dmd compiler.
The api for Object.factory does neither say whether this should 
work or not.


Kind regards
André


Issue https://issues.dlang.org/show_bug.cgi?id=16124 created.

Kind regards
André

Re: Object.factory fails for static libraries

[Andre Pany via Digitalmars-d-learn]

On Saturday, 4 June 2016 at 16:12:04 UTC, Andre Pany wrote:

Hi,

I try to create objects by using the factory method in a static 
library scenario.


...
My windows batch file looks like this:
dmd base -lib
dmd child -lib base.lib
dmd main base.lib child.lib
main
PAUSE

All assertions fails. Should this work, or is this a restriction
of object.factory?

Kind regards
André


I just validated, the same issue also occurs on ubuntu linux with 
the recent dmd compiler.
The api for Object.factory does neither say whether this should 
work or not.


Kind regards
André

Re: throw Exception with custom message in nogc code

[HubCool via Digitalmars-d-learn]

On Sunday, 5 June 2016 at 00:05:15 UTC, poliklosio wrote:
I need to throw some exceptions in my code, but I don't want to 
ever care about the garbage collector.


I have seen some solutions to throwing exceptions in nogc code, 
but only toy examples, like

https://p0nce.github.io/d-idioms/#Throwing-despite-@nogc

The solution sort of works, but doesn't show how to pass a 
custom string to the exception, and the text says "This trick 
is a dirty Proof Of Concept. Just never do it.".

Is there a solution?


You can also "make!TheExceptionType(Mallocator.instance, 
message)" And you stores them in a fixed length stack. On program 
termination you free them.


But I'd say that the leak doesn't matter. Either the soft has a 
very small problem that happens once eventually, otherwise it's a 
big bug and new exceptions will come so often that the program 
has to be killed immediatly.


+--+
auto leakAnoGcException(T, A...)(A a) @nogc
if (is(T: Exception))
{
import std.experimental.allocator.mallocator;
import std.experimental.allocator;
return make!T(Mallocator.instance, a);
// eventually stores them ona stack that you can free in 
static ~this()

}

void main() @nogc
{
bool ouch;
class MyException: Exception {this(string m) @nogc 
{super(m);}}

try throw leakAnoGcException!MyException("ouch");
catch (Exception e) {ouch = true;/*can dispose here too...*/}
assert(ouch);
}
+--+