Re: Tuple poilerplate code

[JG via Digitalmars-d-learn]

On Wednesday, 2 September 2020 at 03:52:55 UTC, JG wrote:

Thank you all for the interesting suggestions.


Still thinking about this from time to time.

Other than the suggestions given, this is what I have
been playing around with.

-
import std.stdio;
import std.typecons : tuple;


mixin template assignTuple(alias vars, alias tupleFunc)
{
 import std.conv : to;
 auto tmp = tupleFunc();
 static foreach (i, var ; vars)
 {
  mixin("auto " ~ var ~ " = tmp[" ~ i.to!string ~ "];");
 }
}

auto f(int n) { return tuple(n, n+1, n+2, "A string here"); }

void main()
{
 mixin assignTuple!(["x","y","z", "str"],()=>f(3));
 writeln(x," ",y," ", z," \'",str,"\'");
}

-
produces
-
3 4 5 'A string here'
-
I have a few questions:

1. Is the above code "bad" for some reason?
2. Is there a way of "hiding" tmp used in the mixin, so that it 
is not visible in main?

Question about linker errors when using slices

[tspike via Digitalmars-d-learn]

I’ve been using D for personal projects for almost a year now and 
I really love it. I recently ran across a linker error that I’m a 
little confused by. Consider the following files:


platform.d:

module platform;

import app;

struct PlatformData
{
AppData a;
}

void main()
{

}

app.d:

module app;

struct AppData
{
//int* items;
int[] items;
}

If you only compile platform.d, the linker will complain about 
“undefined references.” This is true when using dmd and gdc, 
though platform.d compiles just fine when using ldc. But the file 
only fails to compile when the “items” member of AppData is a 
slice; if “items” is an int* platform.d will compile.


The linker spits the following:

platform.o:(.data._D22TypeInfo_S3app7AppData6__initZ+0x30): 
undefined reference to `_D3app7AppData9__xtoHashFNbNeKxSQBeQBdZm'
platform.o:(.data._D22TypeInfo_S3app7AppData6__initZ+0x38): 
undefined reference to 
`_D3app7AppData11__xopEqualsFKxSQBdQBcKxQjZb'


I was just wondering if anyone knows if this behavior is expected 
or if this is a compiler bug. Thank you in advance for your time!


PS: I hope this is the right sub-forum for asking this sort of 
question!

Re: DDoc generation

[James Blachly via Digitalmars-d-learn]

On 9/18/20 9:35 AM, Russel Winder wrote:

On Fri, 2020-09-18 at 09:02 -0400, Steven Schveighoffer via Digitalmars-d-
learn wrote:

[…]


it ddoc files, and compile those along with your
application.

https://dlang.org/spec/ddoc.html#using_ddoc_for_other_documentation



Any small project examples anywhere?



I am also learning about ddoc generation (something that IMO could stand 
to be much better , ahem, documented). A nice example I've found is the 
libmir site:


https://www.libmir.org/
http://mir-algorithm.libmir.org/ (mir-core., mir-random., etc.)

and its documentation generation infrastructure:

https://github.com/libmir/circle-dlang

Re: Building LDC runtime for a microcontroller

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

On Thursday, 17 September 2020 at 09:53:57 UTC, Remi wrote:
My problem here is mostly understanding the __initZ symbol and 
where it comes from.


The compiler generates that when it spits out something that uses 
TypeInfo, which is a lot of things: ~= and ~ operators on built 
in arrays, the new operator, class dynamic casting, exception 
catching, and more. Annoyingly, even having a class member of a 
type will trigger a TypeInfo dependency too. Why? idk, probably 
to do with precise GC hook support.


The error you mentioned in your other message about the order of 
files is interesting.. I suspect that is because the compiler 
creates these symbols when it first sees a need... then tries to 
reuse it, and that must have made the conflict here since it made 
it in the wrong context... or something.


The error says something about constness being different, well, 
why the eff would an init symbol ever be mutable? And ldc is so 
strict about this stuff too where dmd just doesn't care and that 
can be annoying too.


idk this probably doesn't help you much since I don't know why it 
is generating it this way either. It is possible it is actually 
pulling the definition from the original druntime or something.


(on my webassembly.arsdnet.net site btw I made my own little 
on-demand build web service to pass the right args. p convenient 
but also specialized for me and prolly not too general purpose)


I'll keep investigating as I have time, but I do kinda prefer th 
idea of improving the system rather than hacking around it lol


I'll probably try what you describe in your "Zero-runtime 
classes" actually, and hopefully I can get away without the 
string manipulation or replace it with my own version of it.


oh the string manip there is just looking up the symbol, it isn't 
too bad.


The betterC thing also kinda sorta works with classes btw if you 
combine this with extern(C++) class definitions.

Re: vibe.d: How to get the conent of a file upload ?

[mw via Digitalmars-d-learn]

On Friday, 18 September 2020 at 00:07:12 UTC, wjoe wrote:


Are there other frameworks besides vibe that can do what I want?


Just FYI, there is also:

https://code.dlang.org/packages/hunt-framework


I never used myself, you need to investigate.

Re: vibe.d: How to get the conent of a file upload ?

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

On Friday, 18 September 2020 at 22:02:07 UTC, aberba wrote:
In this case you want to get the file(s) in memory...in the 
form of bytes (or buffer) and probably set a file size limit. 
Its all doable through a library but such a library doesn't 
exist in D yet. At least not that I know of.


I actually added *exactly* this to cgi.d in... 2010 if I remember 
right. I even kinda documented it: 
http://dpldocs.info/experimental-docs/arsd.cgi.Cgi.UploadedFile.contentInMemory.html


The threshold where it goes to a file is right now 10 MB and not 
configurable, but I've been meaning to go back and clean up this 
api a little. The max file size it accepts is configurable 
 
but the threshold where it goes from memory to file is not.


Though I should note that if vibe is putting it in a temporary 
file it probably realistically stays in memory anyway this 
whole thing might be about nothing since the OS is pretty good 
about optimizing temp files.


Just I have bigger things to take care of right now (or should I 
say smaller things?!)

Re: vibe.d: How to get the conent of a file upload ?

[aberba via Digitalmars-d-learn]

On Friday, 18 September 2020 at 00:07:12 UTC, wjoe wrote:
On Thursday, 17 September 2020 at 22:33:46 UTC, Steven 
Schveighoffer wrote:

On 9/17/20 6:13 PM, aberba wrote:
On Thursday, 17 September 2020 at 21:57:37 UTC, Steven 
Schveighoffer wrote:

On 9/17/20 1:08 PM, wjoe wrote:

[...]


the `files` property actually does the processing only when 
you call it.


If you access the `bodyReader` property directly, you can 
process that data yourself. You can even register a web 
interface function with an `InputStream` parameter type, and 
it will be bound to the body data.


I'm not sure I understand how to do this and parser the files 
in memory.


So an HTTP request with form data will come in with the 
headers parsed, but the data is still on the network stream.


The first time you access `files`, it processes the stream 
data, and splits it into form data and file data, saves the 
files, and then gives you back the file dictionary so you can 
use them.


If instead, you access `bodyReader`, YOU get to process the 
form data and file data.




I've done this with my REST interface, though that's not 
form data.


That's not a great API, though. I would love to see vibe.d 
allow a direct call to vibe.inet.webform.parseFormData with 
a specific handler for files and form data.
Can we file an issue for this? Because I'm very interested in 
having this resolved


You can always file an issue! 
https://github.com/vibe-d/vibe.d/issues


There may already be one in there.

There's potential to results in out of memory condition. Its 
a know issues. A complete parser (like multer in nodejs) 
allowance you to limit file size as well for error handling.


Meh, this is D :) we should be able to just process the data 
and do whatever we want with it. What I would like to see is 
vibe provide the parsing of form data, and just give me the 
data as it comes (kind of like a SAX parser). Maybe just a 
property in the HTTPServerRequest that I can set that says 
"use this callback when you get Form File data".


I've done this with my REST interface, though that's not 
form data.


Can you share your code for this?


Heh, this is not form data, it's just file data, raw on the 
stream. So I have a function like:


```
class FileRestImpl
{
@path(":cat/:id/:uuid/upload")
@getAuth
void postUpload(HTTPServerResponse res, string _cat, int 
_id, string _uuid, InputStream stream, Nullable!string md5sum, 
NRMAuthInfo _authInfo)

{
...
}
}
```

You can see, I take an InputStream as a parameter -- the data 
comes in there. I just read it and save it to a file (in the 
correct location) anyway, verifying the md5sum is valid.


-Steve


Not a reply to this post in particular but to all the ones I've 
read so far.


If I understand correctly. Vibe parses the form data and writes 
all files to disk. Where to ?
Can I configure it ? I don't want libraries to just write data 
to my file systems without me setting this up. Nowhere did I 
find this behavior described in the docs.
And if not, how is data processed with a 10mb file upload 
followed by a few number fields ?
It needs to read all of the file data to get to the other data 
fields, doesn't it ?


I'm sorry this is completely counter intuitive. I can 
understand the memory/security risks and all but I have no 
intention to hack, DOS or however else disrupt my private 
server in my private network with garbage data. I just want to 
get the data in a byte[].


That's what I was trying to answer. When Steve said meh, he 
probably didn't get what I said. Probably its because of my typos.


This sort of convenience and productivity benefit is part of why 
I use Node.Js in the job when I need to get things doneand 
not D yet. There are several pieces and bits you can't write 
yourself when working on projects.


In this case you want to get the file(s) in memory...in the form 
of bytes (or buffer) and probably set a file size limit. Its all 
doable through a library but such a library doesn't exist in D 
yet. At least not that I know of.


Its why I mentioned that multer[1] in Node.Js able to do 
that...hence the advantage. Its built for the express 
framework...meaning such library can be built to work with 
vibe.d. Not everything can be built into vibe.d..and I think 
that'll even make it bloated for other uses case. Its need an 
ecosystem of third-party libraries.


In the case of the vibe.d form, data and files are handled using 
this implementation[2] so its a reference to such a form parser 
implementation...with support for a storage parameter for either 
a MemoryStore or SessionStore. Multer does it pretty cleanly.


1. Multer: https://www.npmjs.com/package/multer
2. 
https://github.com/vibe-d/vibe.d/blob/ebebfa827f568cc9bced4bec2b66edc043a8adf7/inet/vibe/inet/webform.d





Why does the lib not simply reject files that are unreasonably 
(configurable) big ?
Writing files to disk in order to then needing to copy them 
somewhere else or to read 

Re: Why is BOM required to use unicode in tokens?

[Patrick Schluter via Digitalmars-d-learn]

On Wednesday, 16 September 2020 at 00:22:15 UTC, Steven 
Schveighoffer wrote:

On 9/15/20 8:10 PM, James Blachly wrote:

On 9/15/20 10:59 AM, Steven Schveighoffer wrote:

[...]


Steve: It sounds as if the spec is correct but the glyph 
(codepoint?) range is outdated. If this is the case, it would 
be a worthwhile update. Do you really think it would be 
rejected out of hand?




I don't really know the answer, as I'm not a unicode expert.

Someone should verify that the character you want to use for a 
symbol name is actually considered a letter or not. Using 
phobos to prove this is kind of self-defeating, as I'm pretty 
sure it would be in league with DMD if there is a bug.


I checked, it's not a letter. None of the math symbols are.



But if it's not a letter, then it would take more than just 
updating the range. It would be a change in the philosophy of 
what constitutes an identifier name.

Re: Why is dtor called for lazy parameter?

[Simen Kjærås via Digitalmars-d-learn]

On Friday, 18 September 2020 at 14:14:31 UTC, Andrey Zherikov 
wrote:
It seems that dtor is called at exit from lazy delegate, not at 
exit form create():

==
create()
.do_something()
.do_lazy()
.do_something();
==
Output:
==
-> void test.main()
-> test.do_lazy(lazy S s)
-> test.create()
1 S test.S.this(int n)
<- test.create()
-> 1 test.do_something(S s)
<- 1 test.do_something(S s)
1 void test.S.~this()
===-1
<- test.do_lazy(lazy S s)
-> 1703096 test.do_something(S s)
<- 1703096 test.do_something(S s)
<- void test.main()
==

This doesn't even allow me to copy the value of 's' in 
do_lazy().


You're right, I missed a step: do_lazy() takes a S, not a 
scoped!S, so the conversion from scoped!S to S happens after 
create() has returned and before the value is used in do_lazy. 
This explains my confusion earlier.


D's lazy is essentially the same as a delegate or function, so 
you could* rewrite to this (writelns omitted for clarity):


S do_lazy(S function() s) {
return s();
}

void main() {
(() => cast(S)create()) // Here
.do_lazy()
.do_something();
}

On the marked line, the cast from scoped!S to S happens, the 
scoped!S goes out of scope and the destructor is called.


*There may be differences, but for this discussion these are not 
important.


--
  Simen

Re: How to convert member function to free function?

[Andrey Zherikov via Digitalmars-d-learn]

On Friday, 18 September 2020 at 18:20:41 UTC, Andrey Zherikov 
wrote:
How can I rewrite foo() function as a free-function that won't 
cause struct copying?


I found solution:

struct S
{
int i = -1;
this(int n) {i=n;writeln(," ",i," 
",__PRETTY_FUNCTION__);}
this(ref return scope inout S rhs) inout 
{i=rhs.i+1;writeln(," ",i," ",__PRETTY_FUNCTION__);}

~this() {writeln(," ",i," ",__PRETTY_FUNCTION__);}
ref auto getRef() return
{
writeln(," ",i," ",__PRETTY_FUNCTION__);
return this;
}
}

ref auto foo(return ref S s)
{
writeln(," ",s.i," ",__PRETTY_FUNCTION__);
return s;
}

void main()
{
S(5).getRef().foo().foo().foo();
}


Output confirms that there is no copying happens:

7FFDE98BDDF0 5 S onlineapp.S.this(int n) ref
7FFDE98BDDF0 5 onlineapp.S.getRef() ref return
7FFDE98BDDF0 5 onlineapp.foo(return ref S s) ref @system
7FFDE98BDDF0 5 onlineapp.foo(return ref S s) ref @system
7FFDE98BDDF0 5 onlineapp.foo(return ref S s) ref @system
7FFDE98BDDF0 5 void onlineapp.S.~this()

Re: How to convert member function to free function?

[Andrey Zherikov via Digitalmars-d-learn]

On Friday, 18 September 2020 at 18:43:38 UTC, H. S. Teoh wrote:

Why can't you return by ref, which would also avoid the copying?

ref S foo(return ref S s) { return s; }


Compiler errors out:
onlineapp.d(9): Error: function onlineapp.foo(return ref S s) is 
not callable using argument types (S)
onlineapp.d(9):cannot pass rvalue argument S() of type S 
to parameter return ref S s

Re: How to convert member function to free function?

[H. S. Teoh via Digitalmars-d-learn]

On Fri, Sep 18, 2020 at 06:20:41PM +, Andrey Zherikov via 
Digitalmars-d-learn wrote:
> How can I rewrite foo() function as a free-function that won't cause
> struct copying? My simplified code is:
> 
> struct S
> {
> ref S foo() return
> {
> return this;
> }
> }
> 
> void main()
> {
> S().foo().foo().foo();
> }
> 
> If I write it like "auto foo(S s) { return s; }" then statement in
> main() will copy value of S three times and I want to avoid this.

Why can't you return by ref, which would also avoid the copying?

ref S foo(return ref S s) { return s; }


T

-- 
Let's not fight disease by killing the patient. -- Sean 'Shaleh' Perry

How to convert member function to free function?

[Andrey Zherikov via Digitalmars-d-learn]

How can I rewrite foo() function as a free-function that won't 
cause struct copying? My simplified code is:


struct S
{
ref S foo() return
{
return this;
}
}

void main()
{
S().foo().foo().foo();
}

If I write it like "auto foo(S s) { return s; }" then statement 
in main() will copy value of S three times and I want to avoid 
this.

Re: Why is BOM required to use unicode in tokens?

[GK via Digitalmars-d-learn]

On Tuesday, 15 September 2020 at 16:23:01 UTC, Jon Degenhardt 
wrote:



# The 'Ш' and 'ä' characters are fine.
$ echo $'import std.stdio; void Шä() { writeln("Hello World!"); 
} void main() { Шä(); }' | dmd -run -

Hello World!

# But not '∂'
$ echo $'import std.stdio; void x∂() { writeln("Hello World!"); 
} void main() { x∂(); }' | dmd -run -

__stdin.d(1): Error: char 0x2202 not allowed in identifier


Yes. The same troubles for widely used Greek symbols (Sigma, 
alpha and some other). Unfortunally...

Re: dub: Is it possible to have a library target and depend on it in the same dub config?

[wjoe via Digitalmars-d-learn]

On Friday, 18 September 2020 at 14:15:27 UTC, Steven 
Schveighoffer wrote:

On 9/18/20 7:38 AM, wjoe wrote:

[...]


There are other options.

for instance dub (the project) has a library and an 
application. the config looks like this:


configuration "application" {
targetType "executable"
mainSourceFile "source/app.d"
libs "curl"
versions "DubUseCurl" "DubApplication"
}

configuration "library" {
targetType "library"
excludedSourceFiles "source/app.d"
	copyFiles "bin/libcurl.dll" "bin/libeay32.dll" 
"bin/ssleay32.dll" platform="windows"

versions "DubUseCurl"
}

You can also build a subproject in the same repository. In that 
case, you would probably want the app to be the main project, 
and you then depend on the library project via "foo:lib"


-Steve


A subproject. Interesting. this sounds like what I want to do.

Re: dub: Is it possible to have a library target and depend on it in the same dub config?

[wjoe via Digitalmars-d-learn]

On Friday, 18 September 2020 at 14:01:55 UTC, Mike Parker wrote:

On Friday, 18 September 2020 at 12:28:30 UTC, wjoe wrote:


2 issues though.
- It doesn't build the library automatically, and


You'll have to invoke dub once for each config. Just slap both 
commands in a script.



- Linking fails because error: ld: cannot find -llib

Built it manually via dub --config=lib and it lives inside the 
lib directory.
Then added lflags "-Llib" to the "app" configuration but that 
didn't help. ld still can't find the file.

Then I passed the absolute path and ld still complains.

Any ideas as to why ?


It's just a matter of getting the configuration right and 
making the linker happy. I don't think I've ever linked with 
anything other than system libraries on Linux, so I really 
don't know what it expects when linking with a custom shared 
library outside of the system path.


I usually either specify the target as a dependency in meson and 
it just works, or I install the library and provide a pkconfig 
file.
I'm only using dub because of vibe and I hope it would just work 
;)


Make sure that your library foo.so is named `libfoo.so`, when 
you pass the lib path along in dflags via -L, then make sure to 
change `libs "lib/foo"` to `libs "foo"`.


This did the trick.

The initial failure may be because of the path in the library 
name. I remember reading somewhere long ago that if you're 
passing a path in the library name (instead of using the -L 
flag), then you have to specify the full file name, e.g. 
lib/libfoo.so. I don't know if dub will pass that along 
correctly though.


Whatever the case, trying adding -v to your dub command line so 
you can see exactly what's dub is calling the compiler with. 
That may give you a hint.


It links correctly now, thanks a lot :)

The only issue left is that I need to build the library manually.

Re: Proper way to exit with specific exit code?

[H. S. Teoh via Digitalmars-d-learn]

On Fri, Sep 18, 2020 at 08:20:59AM +, IGotD- via Digitalmars-d-learn wrote:
> On Friday, 18 September 2020 at 05:02:21 UTC, H. S. Teoh wrote:
> > 
> > That's the obvious solution, except that actually implementing it is not
> > so simple.  When you have multiple threads listening for each other
> > and/or doing work, there is no 100% guaranteed way of cleanly shutting
> > all of them down at the same time.  You can't just clean up the calling
> > thread and leave the others running, because the other threads might
> > hold references to your data, etc..  But there's no universal protocol
> > for shutting down the other threads too -- they could be in a busy loop
> > with some long-running computation, or they may not be checking for
> > thread messages, or they could be in a server loop that is designed to
> > keep running, etc..  It's one of those annoying things that reduce to
> > the halting problem in the general case.
[...]
> I think a pragmatic solution is just to mutex protect the D exit
> function in case several threads tries to use simultaneously. Then if
> more threads call exit, it will do nothing as the first one that
> called exit actually do the tear down.

That does not solve the problem.  If thread 1 calls exit but thread 2 is
still running and processing data via a shared reference with thread 1's
data, you absolutely do not want to run dtors and tear-down code until
thread 2 is done, otherwise you have a problem.

OTOH, waiting for thread 2 to finish first comes with its own problems:
what if thread 2 never calls exit?  Then no cleanup will be done, which
may not be desirable either (maybe you had thread 1 call exit because
you wanted to release unused resources).


> Also, it should be responsibility of the program to ensure that its
> tear down code runs before calling the D exit function. That's the
> only way I can think of because waiting for all other threads to
> release their resources and exit isn't really realistic either as that
> might do that the program exit never happens. Whatever you do you, you
> have to resort to some "manual" solution".
[...]

If you're prepared to do manual teardown, then you do not need a
D-specific exit function. Just call core.sys.stdc.stdlib.exit and call
it a day. :-)


T

-- 
Never trust an operating system you don't have source for! -- Martin Schulze

Re: get element index when using each!(x)

[Jacob Carlborg via Digitalmars-d-learn]

On 2020-09-17 05:16, Paul Backus wrote:

Worth knowing that the tuples you get from enumerate actually have named 
members, so you can write:


     s.enumerate.each!(x => writeln(x.index, ":", x.value));


It actually works out of the box for `each`:

s.each!((index, value) => writeln(index, ":", value));

https://dlang.org/phobos/std_algorithm_iteration.html#.each

--
/Jacob Carlborg

Re: dub: Is it possible to have a library target and depend on it in the same dub config?

[Steven Schveighoffer via Digitalmars-d-learn]

On 9/18/20 7:38 AM, wjoe wrote:

Something like this:

configuration "lib" {
   targetType "dynamicLibrary"
   sourceDir "source/lib/"
}

configuration "app" {
   targetType "executable"
   sourceFiles "source/app.d"
   linkWith "lib"
}

I found subConfiguration in the docs but that seems to be related to 
external dependencies.


app.d merely provides a CLI to the library as well as an option to run 
as a server. I don't want to have the overhead of an entire git repo and 
such for something that is a single file and also closely related to the 
library.




There are other options.

for instance dub (the project) has a library and an application. the 
config looks like this:


configuration "application" {
targetType "executable"
mainSourceFile "source/app.d"
libs "curl"
versions "DubUseCurl" "DubApplication"
}

configuration "library" {
targetType "library"
excludedSourceFiles "source/app.d"
	copyFiles "bin/libcurl.dll" "bin/libeay32.dll" "bin/ssleay32.dll" 
platform="windows"

versions "DubUseCurl"
}

You can also build a subproject in the same repository. In that case, 
you would probably want the app to be the main project, and you then 
depend on the library project via "foo:lib"


-Steve

Re: Why is dtor called for lazy parameter?

[Andrey Zherikov via Digitalmars-d-learn]

On Friday, 18 September 2020 at 13:28:39 UTC, Simen Kjærås wrote:
Indeed. As we can see from the output, first do_lazy() is 
called from test.main, then create() is called (this happens 
inside do_lazy, as s is lazy). When create() returns, the 
scoped!S you created goes out of scope and is destroyed.


It seems that dtor is called at exit from lazy delegate, not at 
exit form create():

==
create()
.do_something()
.do_lazy()
.do_something();
==
Output:
==
-> void test.main()
-> test.do_lazy(lazy S s)
-> test.create()
1 S test.S.this(int n)
<- test.create()
-> 1 test.do_something(S s)
<- 1 test.do_something(S s)
1 void test.S.~this()
===-1
<- test.do_lazy(lazy S s)
-> 1703096 test.do_something(S s)
<- 1703096 test.do_something(S s)
<- void test.main()
==

This doesn't even allow me to copy the value of 's' in do_lazy().

Re: dub: Is it possible to have a library target and depend on it in the same dub config?

[Mike Parker via Digitalmars-d-learn]

On Friday, 18 September 2020 at 12:28:30 UTC, wjoe wrote:


2 issues though.
- It doesn't build the library automatically, and


You'll have to invoke dub once for each config. Just slap both 
commands in a script.



- Linking fails because error: ld: cannot find -llib

Built it manually via dub --config=lib and it lives inside the 
lib directory.
Then added lflags "-Llib" to the "app" configuration but that 
didn't help. ld still can't find the file.

Then I passed the absolute path and ld still complains.

Any ideas as to why ?


It's just a matter of getting the configuration right and making 
the linker happy. I don't think I've ever linked with anything 
other than system libraries on Linux, so I really don't know what 
it expects when linking with a custom shared library outside of 
the system path.


Make sure that your library foo.so is named `libfoo.so`, when you 
pass the lib path along in dflags via -L, then make sure to 
change `libs "lib/foo"` to `libs "foo"`.


The initial failure may be because of the path in the library 
name. I remember reading somewhere long ago that if you're 
passing a path in the library name (instead of using the -L 
flag), then you have to specify the full file name, e.g. 
lib/libfoo.so. I don't know if dub will pass that along correctly 
though.


Whatever the case, trying adding -v to your dub command line so 
you can see exactly what's dub is calling the compiler with. That 
may give you a hint.

Re: Neater "not version (...)" ?

[Jacob Carlborg via Digitalmars-d-learn]

On 2020-09-16 21:04, Vladimirs Nordholm wrote:

Ah, I guess it boils down to this then. Doesn't really make it "neater", 
but thank you for the tip!


You only need to declare the enums ones.

--
/Jacob Carlborg

Re: Why is dtor called for lazy parameter?

[drug via Digitalmars-d-learn]

On 9/18/20 4:30 PM, drug wrote:

Can't you put a var on the stack?
```
auto instance = create();
instance
     .do_lazy()
     .do_something();
```


Ah, I totally missed your point. Now I see you can't...

Re: DDoc generation

[Russel Winder via Digitalmars-d-learn]

On Fri, 2020-09-18 at 09:02 -0400, Steven Schveighoffer via Digitalmars-d-
learn wrote:

[…]
> 
> it ddoc files, and compile those along with your 
> application.
> 
> https://dlang.org/spec/ddoc.html#using_ddoc_for_other_documentation
> 

Any small project examples anywhere?

-- 
Russel.
===
Dr Russel Winder  t: +44 20 7585 2200
41 Buckmaster Roadm: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk



signature.asc
Description: This is a digitally signed message part

Re: Why is dtor called for lazy parameter?

[drug via Digitalmars-d-learn]

Can't you put a var on the stack?
```
auto instance = create();
instance
.do_lazy()
.do_something();
```

Re: Why is dtor called for lazy parameter?

[Simen Kjærås via Digitalmars-d-learn]

On Friday, 18 September 2020 at 12:32:49 UTC, Andrey Zherikov 
wrote:

==
The output is:
==
-> void test.main()
-> test.do_lazy(lazy S s)
-> test.create()
1 S test.S.this(int n)
<- test.create()
1 void test.S.~this()
===-1  (2)
<- test.do_lazy(lazy S s)
-> 1703096 test.do_something(S s)
<- 1703096 test.do_something(S s)
<- void test.main()
==

As you can see, dtor is called before writeln on (1) and s1.i 
is -1 (2)


Indeed. As we can see from the output, first do_lazy() is called 
from test.main, then create() is called (this happens inside 
do_lazy, as s is lazy). When create() returns, the scoped!S you 
created goes out of scope and is destroyed. scoped's destructor 
overwrites the memory with S.init, which is why s.i is -1 at that 
point. Then the memory is overwritten by subsequent function 
calls, as that stack space is now considered vacant. That's why 
the output changes from -1 to 1703096.


A bit interesting is the fact that <- test.create() is printed 
before ~this(). I expected the order to be opposite, but there 
may be sensible reasons why it's not.


scoped!S is only valid inside the scope its variable exists in, 
and when that scope is exited, it refers to random stack data. 
It's a lot like this code:


int* fun() {
int a;
int* p = 
return p;
}

Note that return  does not compile, with a warning about 
escaping a reference to a local variable. That's exactly the same 
thing that's happening with scoped!S, but since scoped is more 
complex, the compiler has a hard time keeping track of things, 
and code that in a perfect world would not compile, does. It may 
be that D's scope tracking functionality has become good enough 
to catch this error now, if the functions are properly marked. 
Even if this is the case, then they are obviously not properly 
marked. :p



Now, this begets the question: *when* should I use scoped!T?

Short answer: Basically never.

Longer answer:

1) When the lifetime of one object needs to be a strict subset of 
another. That is, the class instance you created only exists as 
long as the function create() is on the stack. When scoped!T is a 
member of another class or struct, it continues to live as long 
as that object exists. In most cases, you don't mind that it 
stays around for longer, and can let the GC handle the cleanup. 
If you really do care, you can use scoped!T, or explicitly 
destroy the object when you're done with it.


2) scoped!T may be used as a performance hack, letting you avoid 
the GC. If you have instrumented your code and found that this is 
the culprit, scoped!T might help. Even if GC is the problem, 
you'll still need #1 to be true.


There may be other cases, but I believe those are the main two 
reasons to use scoped!T.


--
  Simen

Re: vibe.d: How to get the conent of a file upload ?

[wjoe via Digitalmars-d-learn]

On Friday, 18 September 2020 at 12:58:29 UTC, Steven 
Schveighoffer wrote:

On 9/18/20 8:39 AM, Steven Schveighoffer wrote:
But again, solved with an enhancement that allows you to 
process the data in your code. I'll file the enhancement 
request for you, as I think it's a nice addition.


https://github.com/vibe-d/vibe.d/issues/2478

-Steve


Awesome! Thanks a ton :)

Re: vibe.d: How to get the conent of a file upload ?

[wjoe via Digitalmars-d-learn]

On Friday, 18 September 2020 at 12:39:43 UTC, Steven 
Schveighoffer wrote:

On 9/17/20 8:07 PM, wjoe wrote:

[...]


See the code here: 
https://github.com/vibe-d/vibe.d/blob/ebebfa827f568cc9bced4bec2b66edc043a8adf7/inet/vibe/inet/webform.d#L311



[...]


No, not at the moment. Which is why I was saying, it could be 
an enhancement request to vibe.



[...]


All the data is processed before the accessor to the form data 
or the file data. It HAS to be this way, as the data is still 
on the incoming network socket.



[...]


Yes


[...]


Again, enhancement request needed. The code currently is 
hard-coded to write to disk.



[...]


If you had 1000 requests being processed simultaneously, and 
each of those requests provided 10MB files, then you now need 
potentially 10GB of RAM to hold those requests. This doesn't 
scale when the application is unknown to vibe.


But again, solved with an enhancement that allows you to 
process the data in your code. I'll file the enhancement 
request for you, as I think it's a nice addition.



[...]


Agreed. In my case, it was an actual copy, as the location of 
the stored data was on a different filesystem than the 
temporary files.



[...]


Yep, it's a waste in that case.


[...]


Agreed.


[...]


In D, I'm not sure what the other frameworks do. I believe 
there are others if you search on code.dlang.org, you should be 
able to find some.



[...]


web development sucks in general ;) Yet, we all still do it.

-Steve


I was a little tired yesterday when I read the replies. After a 
couple hours of sleep and reading them again it makes a lot more 
sense to me.


Also your suggestion about a direct call to 
vibe.inet.webform.parseFormData with a specific handler for files 
and form data is a lot better than access via byte[].


Thanks for your help. Very much appreciated :)

Re: DDoc generation

[Steven Schveighoffer via Digitalmars-d-learn]

On 9/18/20 7:41 AM, Russel Winder wrote:

Hi,

I am trying to get to grips with DDoc for documenting an application. Getting
the individual module HTML files seems to be the easy bit. The question is how
to get an index.html (or equivalent) so as to have an application level entry
point to the generated documentation.
  



You can make explicit ddoc files, and compile those along with your 
application.


https://dlang.org/spec/ddoc.html#using_ddoc_for_other_documentation

-Steve

Re: vibe.d: How to get the conent of a file upload ?

[Steven Schveighoffer via Digitalmars-d-learn]

On 9/18/20 8:39 AM, Steven Schveighoffer wrote:
But again, solved with an enhancement that allows you to process the 
data in your code. I'll file the enhancement request for you, as I think 
it's a nice addition.


https://github.com/vibe-d/vibe.d/issues/2478

-Steve

Re: vibe.d: How to get the conent of a file upload ?

[Steven Schveighoffer via Digitalmars-d-learn]

On 9/17/20 8:07 PM, wjoe wrote:


Not a reply to this post in particular but to all the ones I've read so 
far.


If I understand correctly. Vibe parses the form data and writes all 
files to disk. Where to ?


See the code here: 
https://github.com/vibe-d/vibe.d/blob/ebebfa827f568cc9bced4bec2b66edc043a8adf7/inet/vibe/inet/webform.d#L311


Can I configure it ? I don't want libraries to just write data to my 
file systems without me setting this up. Nowhere did I find this 
behavior described in the docs.


No, not at the moment. Which is why I was saying, it could be an 
enhancement request to vibe.


And if not, how is data processed with a 10mb file upload followed by a 
few number fields ?


All the data is processed before the accessor to the form data or the 
file data. It HAS to be this way, as the data is still on the incoming 
network socket.


It needs to read all of the file data to get to the other data fields, 
doesn't it ?


Yes



I'm sorry this is completely counter intuitive. I can understand the 
memory/security risks and all but I have no intention to hack, DOS or 
however else disrupt my private server in my private network with 
garbage data. I just want to get the data in a byte[].


Again, enhancement request needed. The code currently is hard-coded to 
write to disk.




Why does the lib not simply reject files that are unreasonably 
(configurable) big ?


If you had 1000 requests being processed simultaneously, and each of 
those requests provided 10MB files, then you now need potentially 10GB 
of RAM to hold those requests. This doesn't scale when the application 
is unknown to vibe.


But again, solved with an enhancement that allows you to process the 
data in your code. I'll file the enhancement request for you, as I think 
it's a nice addition.


Writing files to disk in order to then needing to copy them somewhere 
else or to read them back into memory for further processing sounds, 
above all else, incredibly inefficient.


Agreed. In my case, it was an actual copy, as the location of the stored 
data was on a different filesystem than the temporary files.



I might not even want to keep the file and drop it.


Yep, it's a waste in that case.



I guess it's no problem to parse the data myself, but then what's the 
point in using a framework ?


Agreed.


Are there other frameworks besides vibe that can do what I want ?


In D, I'm not sure what the other frameworks do. I believe there are 
others if you search on code.dlang.org, you should be able to find some.


I'm sorry for the rant, developing this kind of software is a pain in 
the drain and stresses me out to no end. It sucked hard in the past with 
php and decades later with python, ruby, D, you name it it still sucks ;)


web development sucks in general ;) Yet, we all still do it.

-Steve

Re: Why is dtor called for lazy parameter?

[Andrey Zherikov via Digitalmars-d-learn]

On Friday, 18 September 2020 at 11:31:39 UTC, Simen Kjærås wrote:
On Friday, 18 September 2020 at 10:43:47 UTC, Andrey Zherikov 
wrote:
Why is dtor called before returning from do_lazy function - 
see (1)? It seems cause uninitialized parameter in 
do_something call after it in (2)-(3).


As ikod mentions, it's because of scoped!S. As for why it does 
this, yeah, this is kinda egregious. The documentation[0] of 
scoped mentions this issue:


This facility is unsafe; it is the responsibility of the user 
to not escape a reference to the object outside the scope.


As the name implies, scoped!T limits the valid scope of a 
reference to the scope of the variable holding it. You're 
putting it on the stack, so the moment the variable goes off 
the stack (when do_lazy returns), the reference is destructed.


--
  Simen

[0]: https://dlang.org/library/std/typecons/scoped.html


I modified do_lazy in this way:
==
auto do_lazy(lazy S s)
{
writeln("-> ",__PRETTY_FUNCTION__);
scope(exit) writeln("<- ",__PRETTY_FUNCTION__);

auto s1 = s;
writeln("===",s1.i);   (1)

return s1;
}
==
The output is:
==
-> void test.main()
-> test.do_lazy(lazy S s)
-> test.create()
1 S test.S.this(int n)
<- test.create()
1 void test.S.~this()
===-1  (2)
<- test.do_lazy(lazy S s)
-> 1703096 test.do_something(S s)
<- 1703096 test.do_something(S s)
<- void test.main()
==

As you can see, dtor is called before writeln on (1) and s1.i is 
-1 (2)

Re: dub: Is it possible to have a library target and depend on it in the same dub config?

[wjoe via Digitalmars-d-learn]

On Friday, 18 September 2020 at 12:03:45 UTC, Mike Parker wrote:

On Friday, 18 September 2020 at 11:38:14 UTC, wjoe wrote:

Something like this:

configuration "lib" {
  targetType "dynamicLibrary"
  sourceDir "source/lib/"
}

configuration "app" {
  targetType "executable"
  sourceFiles "source/app.d"
  linkWith "lib"
}

I found subConfiguration in the docs but that seems to be 
related to external dependencies.


app.d merely provides a CLI to the library as well as an 
option to run as a server. I don't want to have the overhead 
of an entire git repo and such for something that is a single 
file and also closely related to the library.


Yes, this is possible. Should be something like this:

configuration "lib" {
   targetType "dynamicLibrary"
   targetPath "lib"
   sourcePaths "source/lib/"
   excludedSourceFiles "source/app.d"
}

configuration "app" {
   targetType "executable"
   mainSourceFile "source/app.d"
   excludedSourceFiles "source/lib/*.d"
   importPaths "source/lib"
   libs "lib/libName"
}


Awesome. Thanks. And Danny to you, too.

2 issues though.
- It doesn't build the library automatically, and
- Linking fails because error: ld: cannot find -llib

Built it manually via dub --config=lib and it lives inside the 
lib directory.
Then added lflags "-Llib" to the "app" configuration but that 
didn't help. ld still can't find the file.

Then I passed the absolute path and ld still complains.

Any ideas as to why ?

Re: Why is dtor called for lazy parameter?

[Andrey Zherikov via Digitalmars-d-learn]

On Friday, 18 September 2020 at 10:54:41 UTC, ikod wrote:
On Friday, 18 September 2020 at 10:43:47 UTC, Andrey Zherikov 
wrote:

I have this code:
==
class S

...



auto create()
{
writeln("-> ",__PRETTY_FUNCTION__);
scope(exit) writeln("<- ",__PRETTY_FUNCTION__);

return scoped!S(1);
}


If you replace this line with "return new S(1)" it should work 
as you expect.


This works here, but doesn't meet my intention in main(). I want 
something to be called automatically as a final step when 
"create().do_lazy().do_something();" is done and I see two ways 
to do this: either use struct as return type (this unfortunately 
forces copy struct value for every function call) or use 
scoped!(class) - so dtor is called right after the expression.

In case of "new S(1)" dtor is called after exit from main().

Re: dub: Is it possible to have a library target and depend on it in the same dub config?

[Mike Parker via Digitalmars-d-learn]

On Friday, 18 September 2020 at 11:38:14 UTC, wjoe wrote:

Something like this:

configuration "lib" {
  targetType "dynamicLibrary"
  sourceDir "source/lib/"
}

configuration "app" {
  targetType "executable"
  sourceFiles "source/app.d"
  linkWith "lib"
}

I found subConfiguration in the docs but that seems to be 
related to external dependencies.


app.d merely provides a CLI to the library as well as an option 
to run as a server. I don't want to have the overhead of an 
entire git repo and such for something that is a single file 
and also closely related to the library.


Yes, this is possible. Should be something like this:

configuration "lib" {
   targetType "dynamicLibrary"
   targetPath "lib"
   sourcePaths "source/lib/"
   excludedSourceFiles "source/app.d"
}

configuration "app" {
   targetType "executable"
   mainSourceFile "source/app.d"
   excludedSourceFiles "source/lib/*.d"
   importPaths "source/lib"
   libs "lib/libName"
}

Re: dub: Is it possible to have a library target and depend on it in the same dub config?

[Danny Arends via Digitalmars-d-learn]

On Friday, 18 September 2020 at 11:38:14 UTC, wjoe wrote:

Something like this:

configuration "lib" {
  targetType "dynamicLibrary"
  sourceDir "source/lib/"
}

configuration "app" {
  targetType "executable"
  sourceFiles "source/app.d"
  linkWith "lib"
}

I found subConfiguration in the docs but that seems to be 
related to external dependencies.


app.d merely provides a CLI to the library as well as an option 
to run as a server. I don't want to have the overhead of an 
entire git repo and such for something that is a single file 
and also closely related to the library.


yes just add 2 configurations, use mainSourceFile to specify the 
file with main()



"configurations": [
{
"name": "default",
"targetPath": "bin",
"targetType": "executable",
"mainSourceFile": "main/main.d"
"sourcePaths": ["src/"],
},{
"name": "lib",
"targetType": "dynamicLibrary",
"sourcePaths": ["src/"],
}]

Re: vibe.d: How to get the conent of a file upload ?

[wjoe via Digitalmars-d-learn]

On Friday, 18 September 2020 at 11:44:39 UTC, Atwork wrote:

On Friday, 18 September 2020 at 00:07:12 UTC, wjoe wrote:
And if not, how is data processed with a 10mb file upload 
followed by a few number fields ?
It needs to read all of the file data to get to the other data 
fields, doesn't it ?


Yes and no


Consider this:

~$ curl -F "temperature_log=@/var/log/temperatures.log" -F 
"field1=a" -F "field2+foo" 192.168.1.1:20222/temperature_upload



~$ nc -l 127.0.0.1 20222

POST /temperature_upload HTTP/1.1
Host: 192.168.1.1:20222
User-Agent: curl/7.72.0
Accept: */*
Content-Length: 10486005
Content-Type: multipart/form-data; 
boundary=c73c71472ff9e7d5


--c73c71472ff9e7d5
Content-Disposition: form-data; name="temperature_log"; 
filename="/var/log/temperatures.log"

Content-Type: application/octet-stream

temp_1=22;temp_2=28
temp_1=21;temp_2=25

[ ... 10 MB of data ... ]

--c73c71472ff9e7d5
Content-Disposition: form-data; name="field1"

a
--c73c71472ff9e7d5
Content-Disposition: form-data; name="field2"

foo
--c73c71472ff9e7d5--


How is vibe going to extract field1 and field2 without processing 
the temperature_log field ?

Re: vibe.d: How to get the conent of a file upload ?

[Atwork via Digitalmars-d-learn]

On Friday, 18 September 2020 at 00:07:12 UTC, wjoe wrote:
And if not, how is data processed with a 10mb file upload 
followed by a few number fields ?
It needs to read all of the file data to get to the other data 
fields, doesn't it ?


Yes and no

dub: Is it possible to extend or specialize configurations ?

[wjoe via Digitalmars-d-learn]

configuration "app" {
  versions "CLI"
  target "executable"
  ...
}

configuration "guiapp" : "app" {
  versions "GUI"
  sourceFiles "source/gui.d"
}

The guiapp should basically inherit the "app" configuration and 
extend/override whatever else is needed/different.

DDoc generation

[Russel Winder via Digitalmars-d-learn]

Hi,

I am trying to get to grips with DDoc for documenting an application. Getting
the individual module HTML files seems to be the easy bit. The question is how
to get an index.html (or equivalent) so as to have an application level entry
point to the generated documentation.
 
-- 
Russel.
===
Dr Russel Winder  t: +44 20 7585 2200
41 Buckmaster Roadm: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk



signature.asc
Description: This is a digitally signed message part

dub: Is it possible to have a library target and depend on it in the same dub config?

[wjoe via Digitalmars-d-learn]

Something like this:

configuration "lib" {
  targetType "dynamicLibrary"
  sourceDir "source/lib/"
}

configuration "app" {
  targetType "executable"
  sourceFiles "source/app.d"
  linkWith "lib"
}

I found subConfiguration in the docs but that seems to be related 
to external dependencies.


app.d merely provides a CLI to the library as well as an option 
to run as a server. I don't want to have the overhead of an 
entire git repo and such for something that is a single file and 
also closely related to the library.

Re: Why is dtor called for lazy parameter?

[Simen Kjærås via Digitalmars-d-learn]

On Friday, 18 September 2020 at 10:43:47 UTC, Andrey Zherikov 
wrote:
Why is dtor called before returning from do_lazy function - see 
(1)? It seems cause uninitialized parameter in do_something 
call after it in (2)-(3).


As ikod mentions, it's because of scoped!S. As for why it does 
this, yeah, this is kinda egregious. The documentation[0] of 
scoped mentions this issue:


This facility is unsafe; it is the responsibility of the user 
to not escape a reference to the object outside the scope.


As the name implies, scoped!T limits the valid scope of a 
reference to the scope of the variable holding it. You're putting 
it on the stack, so the moment the variable goes off the stack 
(when do_lazy returns), the reference is destructed.


--
  Simen

[0]: https://dlang.org/library/std/typecons/scoped.html

DDoc Web page

[Russel Winder via Digitalmars-d-learn]

I see that:

https://dlang.org/spec/ddoc.html

refers to:

https://docs.oracle.com/javase/7/docs/technotes/guides/javadoc/index.html

which is really rather ancient and definitely out of date. Should change this
to:

https://docs.oracle.com/en/java/javase/15/javadoc/index.html


-- 
Russel.
===
Dr Russel Winder  t: +44 20 7585 2200
41 Buckmaster Roadm: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk



signature.asc
Description: This is a digitally signed message part

Re: Why is dtor called for lazy parameter?

[ikod via Digitalmars-d-learn]

On Friday, 18 September 2020 at 10:43:47 UTC, Andrey Zherikov 
wrote:

I have this code:
==
class S

...



auto create()
{
writeln("-> ",__PRETTY_FUNCTION__);
scope(exit) writeln("<- ",__PRETTY_FUNCTION__);

return scoped!S(1);
}


If you replace this line with "return new S(1)" it should work as 
you expect.

Why is dtor called for lazy parameter?

[Andrey Zherikov via Digitalmars-d-learn]

I have this code:
==
class S
{
int i = -1;

this(int n) { i = n; writeln(i," ",__PRETTY_FUNCTION__); }
~this() { writeln(i," ",__PRETTY_FUNCTION__); }
}


auto create()
{
writeln("-> ",__PRETTY_FUNCTION__);
scope(exit) writeln("<- ",__PRETTY_FUNCTION__);

return scoped!S(1);
}

auto do_something(S s)
{
writeln("-> ",s.i," ",__PRETTY_FUNCTION__);
scope(exit) writeln("<- ",s.i," ",__PRETTY_FUNCTION__);

return s;
}

auto do_lazy(lazy S s)
{
writeln("-> ",__PRETTY_FUNCTION__);
scope(exit) writeln("<- ",__PRETTY_FUNCTION__);

return s;
}

void main()
{
writeln("-> ",__PRETTY_FUNCTION__);
scope(exit) writeln("<- ",__PRETTY_FUNCTION__);

create()
.do_lazy()
.do_something();
}
==
This is the output:
==
-> void test.main()
-> test.do_lazy(lazy S s)
-> test.create()
1 S test.S.this(int n)
<- test.create()
1 void test.S.~this()(1)
<- test.do_lazy(lazy S s)
-> 1703096 test.do_something(S s)(2)
<- 1703104 test.do_something(S s)(3)
<- void test.main()
==

Why is dtor called before returning from do_lazy function - see 
(1)? It seems cause uninitialized parameter in do_something call 
after it in (2)-(3).

Re: Type inference for constructors

[data pulverizer via Digitalmars-d-learn]

On Friday, 18 September 2020 at 06:43:12 UTC, Simen Kjærås wrote:

On Friday, 18 September 2020 at 05:43:56 UTC, data pulverizer

That's issue 1997: https://issues.dlang.org/show_bug.cgi?id=1997

D's templates are turing complete, and there may be arbitrary 
amounts of logic obscuring the mapping between type template 
parameters and the specific argument types of the type's 
constructor, so the problem is intractable in the general case. 
E.g:


template Foo(T) {
static if (is(T == int)) {
struct Foo {
this(int i) {}
// int-specific code
}
} else {
struct Foo {
this(T t) {}
// generic code
}
}
}

The above example is a simple one, yet mapping from a 
constructor call to the correct template parameters is 
difficult.




Thank you for the explanation and the reference.



That's a template this parameter 
(https://dlang.org/spec/template.html#template_this_parameter). 
It takes on the type of 'this' at the point of instantiation. 
That is:


struct S {
void fun(this T)() { pragma(msg, T); }
}

unittest {
S s;
const S sc;
immutable S si;
shared S ss;
s.fun();  // prints S
sc.fun(); // prints const(S)
si.fun(); // prints immutable(S)
ss.fun(); // prints shared(S)
}

This allows the return type to have the same constness as 
'this', or for specific code to be executed when operating on 
e.g. a non-mutable instance, where lazy initialization couldn't 
be performed. In many cases, this is better served by using 
inout:


https://dlang.org/spec/function.html#inout-functions


After reading your explanation and looking at the part of the 
manual you referred to, it looks as if this pattern could have a 
lot of utility, the `Addable` example in the manual looks like 
polymorphism with dynamic dispatch but retains static type a bit 
like Rust's (runtime) traits.


Many thanks.

Re: Proper way to exit with specific exit code?

[IGotD- via Digitalmars-d-learn]

On Friday, 18 September 2020 at 05:02:21 UTC, H. S. Teoh wrote:


That's the obvious solution, except that actually implementing 
it is not so simple.  When you have multiple threads listening 
for each other and/or doing work, there is no 100% guaranteed 
way of cleanly shutting all of them down at the same time.  You 
can't just clean up the calling thread and leave the others 
running, because the other threads might hold references to 
your data, etc..  But there's no universal protocol for 
shutting down the other threads too -- they could be in a busy 
loop with some long-running computation, or they may not be 
checking for thread messages, or they could be in a server loop 
that is designed to keep running, etc..  It's one of those 
annoying things that reduce to the halting problem in the 
general case.


Unless we adopt some kind of exit protocol that will apply to 
*all* threads in *all* D programs, I don't see any way to 
implement something that will work in the general case.



T


I think a pragmatic solution is just to mutex protect the D exit 
function in case several threads tries to use simultaneously. 
Then if more threads call exit, it will do nothing as the first 
one that called exit actually do the tear down.


Also, it should be responsibility of the program to ensure that 
its tear down code runs before calling the D exit function. 
That's the only way I can think of because waiting for all other 
threads to release their resources and exit isn't really 
realistic either as that might do that the program exit never 
happens. Whatever you do you, you have to resort to some "manual" 
solution".


I suggest keeping it simple and stupid.

Re: enum and const or immutable ‘variable’ whose value is known at compile time

[claptrap via Digitalmars-d-learn]

On Friday, 18 September 2020 at 02:49:30 UTC, Mike Parker wrote:

On Thursday, 17 September 2020 at 22:25:47 UTC, claptrap wrote:

If enum means manifiest constant, or compile time constant, 
then it makes more sense, as you allude to in a later post. 
But 'enum' is a terrible name for that and I dont think my 
brain will ever stop finding it incongruous.


And in my mind, what is a single-member enum if not a 
compile-time constant? This is why naming is hard.


Yes all enum members are compile time constants, but not all 
compile time constants are enum members. The later is a subset of 
the former, but the reverse is not true. So the name implies the 
subset but the feature implements the superset.

Re: Building LDC runtime for a microcontroller

[Dylan Graham via Digitalmars-d-learn]

On Monday, 7 September 2020 at 19:12:59 UTC, aberba wrote:

On Monday, 7 September 2020 at 16:18:00 UTC, IGotD- wrote:
On Monday, 7 September 2020 at 15:23:28 UTC, Severin Teona 
wrote:

[...]


Use betterC, which is much better suited for microcontrollers 
than the full D. The disadvantage is that many great features 
are disabled in betterC.


[...]


How about an alternative runtime + standard library for 
embedded systems...with a least bare minimum. I've seen a 
number of efforts to get D to run in those environments but 
almost none of them is packaged for others to consume.


I use D in an automotive environment (it controls parts of the 
powertrain, so yeah there are cars running around on D) on 
various types of ARM Cortex M CPUs, I think this will be the best 
way to extend D to those platforms.


The existing runtime is PC-oriented. Embedded stuff doesn't need 
a GC or some of the more advanced features, but having things 
like classes, interfaces, dynamic arrays would make the 
development workload a lot easier.


A lot of embedded stuff is done with RTOSs now that provide 
memory management and threading support, so having a flexible 
lightweight runtime with a generic backend (mem allocation, 
threads) that I can hook to the RTOS' libraries would be great.

Re: Building LDC runtime for a microcontroller

[Remi via Digitalmars-d-learn]

On Thursday, 17 September 2020 at 19:27:41 UTC, Adam D. Ruppe 
wrote:
fyi my baby was just born i'll come back to this but it might 
be a day or two


Oh probably most unexpected answer! Congratulations!

Had 4 weeks myself, take care of your family, everything else can 
wait ;)

Re: Type inference for constructors

[Simen Kjærås via Digitalmars-d-learn]

On Friday, 18 September 2020 at 05:43:56 UTC, data pulverizer 
wrote:
I’d like to know if constructors of classes and structs can 
have type inference. So far, I am using a separate function for 
this purpose, for example:


```
import std.stdio: writeln;

struct Pair(T, U)
{
  T first;
  U second;
  this(T first, U second)
  {
this.first = first;
this.second = second;
  }
}

Pair!(T, U) pair(T, U)(T first, U second)
{
  return Pair!(T, U)(first, second);
}

void main()
{
  auto mp = pair("Michael", 32);//standard function inference 
works
  //auto m0 = Pair("Michael", 32); //I’d like to be able to do 
this

  writeln("pair: ", mp);
}
```


That's issue 1997: https://issues.dlang.org/show_bug.cgi?id=1997

D's templates are turing complete, and there may be arbitrary 
amounts of logic obscuring the mapping between type template 
parameters and the specific argument types of the type's 
constructor, so the problem is intractable in the general case. 
E.g:


template Foo(T) {
static if (is(T == int)) {
struct Foo {
this(int i) {}
// int-specific code
}
} else {
struct Foo {
this(T t) {}
// generic code
}
}
}

The above example is a simple one, yet mapping from a constructor 
call to the correct template parameters is difficult.




[I] wondered what `this` in the code below does:

```
 auto ref opIndex(this X, D...)(auto ref D i) { return a[i]; }
```


That's a template this parameter 
(https://dlang.org/spec/template.html#template_this_parameter). 
It takes on the type of 'this' at the point of instantiation. 
That is:


struct S {
void fun(this T)() { pragma(msg, T); }
}

unittest {
S s;
const S sc;
immutable S si;
shared S ss;
s.fun();  // prints S
sc.fun(); // prints const(S)
si.fun(); // prints immutable(S)
ss.fun(); // prints shared(S)
}

This allows the return type to have the same constness as 'this', 
or for specific code to be executed when operating on e.g. a 
non-mutable instance, where lazy initialization couldn't be 
performed. In many cases, this is better served by using inout:


https://dlang.org/spec/function.html#inout-functions

--
  Simen