Store any callable in an array

[wjoe via Digitalmars-d-learn]

I have a class that I want to be able to register callbacks and 
I'd like to be able to register any callable - functions, 
delegates, lambdas, anything.


Is there another way to do it besides converting those 
toDelegate, which states a bug with @safe functions?


Or better store each type in their own array ?

Cheers!

Re: Windows to Linux Porting - timeCreated and timeLastAccessed

[wjoe via Digitalmars-d-learn]

On Friday, 4 May 2018 at 15:30:26 UTC, Vino wrote:

On Friday, 4 May 2018 at 15:16:23 UTC, wjoe wrote:

[...]


Hi Wjoe,

  Thank you very much, but what i am expecting is something 
like OS switch, based of OS type switch the funciton eg:


If OS is windows use the funciton timeCreated else if the OS is 
linux use the function timeLastAccessed in the below example 
program, something similar as stated in the link


https://dlang.org/spec/declaration.html#alias

Eg1:
version (Win32)
{
alias myfoo = win32.foo;
}
version (linux)
{
alias myfoo = linux.bar;
}



auto clogClean (string LogDir ) {
Array!(Tuple!(string, SysTime)) dFiles;


version (Windows) {  alias sTimeStamp = 
std.file.DirEntry.timeCreated;} else version (linux) { alias 
sTimeStamp = std.file.DirEntry.timeLastAccessed; }



dFiles.insert(dirEntries(LogDir, SpanMode.shallow).filter!(a => 
a.isFile).map!(a => tuple(a.name, a.sTimeStamp)));

 return dFiles;
}

From,
Vino.B


I think that's not possible. You can't query information that 
hasn't been stored.


Your best bet in a Change-Function-Name-Port would probably be to 
use access time and mount the file system with options that won't 
touch that anymore after creation. But me thinks such a solution 
would be rather unreliable and not worth the time investment.

Re: Windows to Linux Porting - timeCreated and timeLastAccessed

[wjoe via Digitalmars-d-learn]

On Friday, 4 May 2018 at 14:24:36 UTC, Vino wrote:

On Friday, 4 May 2018 at 14:02:24 UTC, Jonathan M Davis wrote:
On Friday, May 04, 2018 13:17:36 Vino via Digitalmars-d-learn 
wrote:

On Friday, 4 May 2018 at 12:38:07 UTC, Adam D. Ruppe wrote:
> What are you actually trying to do with it? These functions 
> are probably the wholly wrong approach.


Hi Adam,

  The existing program in Windows do few task's eg: Delete 
files
older that certain days, and now we are trying to port to 
Linux,
and above was just a example, hence asked the right approach 
for

porting.


Linux does not keep track of the creation time of a file. So, 
it will not work to have a program on Linux ask a file how 
long it's been since the file was created. If you want that 
information, you'll have to store it elsewhere somehow (and 
that generally only works if you created the file in the first 
place).


The modification time of the file is the time that the file 
was last changed (which would be the creation time if it were 
only ever written to once, but in the general case, it has no 
relation to the creation time at all). So, you could use 
std.file.timeLastModified to find out if a file has been 
changed within the last x number of days, but there is no way 
to find out the creation time of a file by asking the 
filesystem.


- Jonathan M Davis


Hi Jonathan,

  Thank you,  i got your point from the other forum topic which 
was raised by me earlier, hence decided to use modification 
time, the request is on how and the best approach to port the 
code from windows to Linux eg program below


Example Code:
import std.stdio: writeln;
import std.container.array;
import std.file: dirEntries,isFile, SpanMode;
import std.algorithm: filter, map;
import std.typecons: Tuple, tuple;
import std.datetime.systime: SysTime;


version (Windows) { alias sTimeStamp = timeCreated; } else 
version (linux) { alias sTimeStamp = timeLastAccessed; }


auto clogClean (string LogDir ) {
Array!(Tuple!(string, SysTime)) dFiles;
 dFiles.insert(dirEntries(LogDir, SpanMode.shallow).filter!(a 
=> a.isFile).map!(a => tuple(a.name, a.sTimeStamp)));

 return dFiles;
}

void main () {
string LogDir;
LogDir = "//DScript/Test";   //  Error: undefined 
identifier timeLastAccessed on Linux
LogDir = "C:\\DScript\\Others";  //  Error: undefined 
identifier timeCreated on Windows.

writeln(clogClean(LogDir));
}

From,
Vino.B


Unlike NTFS for Windows there's a plethora of different file 
systems available to use for Linux, one of which doesn't even 
support deletion of files. You also have to keep in mind that 
even if the same file system is used, there is no guarantee that 
you have the same set of metadata available for a mount point 
each and every time.
Consider a file system that's mounted with the 'noatime' option, 
for instance, which doesn't log access times.


As far as I understand you are globing files, check times and 
then act upon that.
If I were to port this to Linux, or any other OS for that matter, 
I wouldn't depend on a feature of an OS.
Instead, since you have to look at a file either way to get the 
meta data (which you query with the stat family of functions), I 
would build my own database or cache with that information.
Glob the directory and add files not yet present with the current 
date (and any other meta data you might need).
Then query all the files of interest and do whatever you want to 
do with them and remove the entry.


Downside is you have possibly another dependency. On the plus 
side you could easily query all files older than X days or 
whatever with a single select and batch process them.

Re: Store any callable in an array

[wjoe via Digitalmars-d-learn]

Thanks for replying.

On Friday, 4 May 2018 at 19:12:16 UTC, ag0aep6g wrote:

On 05/04/2018 06:33 PM, Neia Neutuladh wrote:

auto asDelegate(TFunc)(TFunc func) @trusted
{
     import std.functional : toDelegate;
     return toDelegate(func);
}

The "@trusted" means that you promise this thing is safe, even 
if the compiler can't be certain.


If toDelegate isn't (always) @safe, how can you be sure that 
your wrapper is? Also, TFunc may have an unsafe destructor.


That's not good use of `@trusted`.


Could you elaborate on the unsafe destructor please? Are there 
any other gotchas ?

Re: Store any callable in an array

[wjoe via Digitalmars-d-learn]

Thanks for replying.

On Saturday, 5 May 2018 at 00:30:35 UTC, Neia Neutuladh wrote:

On Friday, 4 May 2018 at 19:12:16 UTC, ag0aep6g wrote:
[...] If it's a user-defined type with opCall, that's something 
to pay attention to, but it's beyond the scope of the original 
question.


Actually it's not. Callable structs/classes are use cases I'm 
asking about as well.

Re: Store any callable in an array

[wjoe via Digitalmars-d-learn]

On Monday, 7 May 2018 at 10:20:22 UTC, ag0aep6g wrote:

On 05/07/2018 04:41 AM, wjoe wrote:

Could you elaborate on the unsafe destructor please?


If TFunc has an unsafe destructor, asDelegate is also not safe 
and can't be @trusted.


An example of how that can break safety:


auto asDelegate(TFunc)(TFunc func) @trusted
{
 import std.functional : toDelegate;
 return toDelegate(func);
}

int* ptr;
size_t length;

struct S
{
void opCall() {}
~this() @system
{
ptr[length - 1] = 13;
}
}

void main() @safe
{
ptr = new int;
length = 5; /* Whoops, got the length wrong. */
immutable int* imm = new int(42);
auto dg = asDelegate(S.init);
assert(*imm == 42); /* Fails. Immutability has been broken. 
*/

}


The program has undefined behavior, which means it's invalid. 
And it's the fault of the wrong @trusted.



Are there any other gotchas ?


The postblit function `this(this)` is also commonly overlooked 
with regards to @trusted. It might not be a problem here, 
though, because toDelegate has a `ref` parameter.


An unsafe `alias this` would be another problem. Example:

/* ... asDelegate, ptr, length, main as above ... */
struct S
{
@property T t() @system
{
ptr[length - 1] = 13;
return T.init;
}
alias t this;
}
struct T
{
void opCall() {}
}


Those are the things I can see happening in asDelegate.

Additionally, you'd have to check what the toDelegate call does 
exactly before trusting it. And if it turns out that the call 
can be trusted, then you can probably just mark toDelegate 
itself as @trusted. And then there would be no need for 
asDelegate anymore.


Thank you for taking the time to write up this reply and widen my 
horizon. Very much appreciated.


After further investigation I found a post where someone asked 
about the differences of function/delegate and one of the replies 
explained that functions converted to a delegate occur a 
considerable performance impact.


This and since toDelegate has a bug with @safe functions, and 
slapping a @trusted on to it sounds like more headache than it's 
worth, I will handle these cases separately.


Thanks everybody for all the replies.

Re: Windows to Linux Porting - timeCreated and timeLastAccessed

[wjoe via Digitalmars-d-learn]

On Friday, 4 May 2018 at 15:42:56 UTC, wjoe wrote:
I think that's not possible. You can't query information that 
hasn't been stored.


I stand corrected.

As Russel Winder points out there are file systems that store 
this information and since Linux 4.11 you can query it via 
statx(2).

Re: What is the point of nothrow?

[wjoe via Digitalmars-d-learn]

On Saturday, 16 June 2018 at 21:25:01 UTC, Jonathan M Davis wrote:
On Saturday, June 16, 2018 18:45:53 wjoe via 
Digitalmars-d-learn wrote:

What you said earlier:

On Monday, 11 June 2018 at 00:47:27 UTC, Jonathan M Davis 
wrote:

> [...]
>
> 2. If the compiler knows that a function can't throw an 
> Exception, then it doesn't have to insert any of the 
> Exception handling mechanism stuff [...] So, the fact that a 
> function is nothrow gives you a performance benefit, [...]

>
> - Jonathan M Davis

made me believe that performance is one of the major reasons 
to use it. No?


 From the betterC page https://dlang.org/spec/betterc.html 
section

40.2:
---
Not Available

D features not available with BetterC:

 Garbage Collection
 TypeInfo and ModuleInfo
 Classes
 Built-in threading (e.g. core.thread)
 Dynamic arrays (though slices of static arrays work) and
associative arrays
 Exceptions
 switch with strings
 final switch
 synchronized and core.sync
 Static module constructors or destructors
 Struct destructors
 unittest (testing can be done without the -betterC flag)
---
Apart from a few convenience features lost this list reads 
like a shopping list for performance gain over full fledged D, 
in the spirit of nothrow omitting exception handling 
mechanism, to me. You gain from no garbage collection 
overhead, no vtable overhead, no RTTI overhead, no exception 
overhead, etc, etc, ...


Back in the late 90ies I used to write the lion's share of 
code in Pascal and implement mission critical algorithms in 
asm. Worked back then why wouldn't it work today, except that 
I wouldn't use asm anymore but something like C or betterC.


Thus, people who need this kind of performance boost can 
benefit

2 fold from using betterC.
1. They get to keep most of D's awesomeness, including compile
time features, scope statements, RAII, lack of a pre processor,
memory safety protections and complete meta programming, are 
just

_some_ of the highlights. And on the other hand
2. they gain by getting rid of a lot the 'performance hogs' 
like

GC, exceptions and more, right?
And, with no exceptions altogether they do not need to worry
about it at all.

I'm sold!


The _entire_ point of betterC is to be able to call D code from 
C code without having to deal with druntime (you can call D 
code from C code even without betterC, but then you have to 
worry about initializing and shutting down druntime). Basically


BetterC sounds like a C language with tons of features from.. 
well actually...it sounds like a C language that fixes C's 
shortcomings.
To get that point across it should maybe be called C2D Easy 
Interop Language.


every feature that you can't use in betterC is considered a 
loss, and efforts are being made to make more of them work. 
There's always going to be a limit to that, and some D features 
just plain require druntime (just like some of C++'s features 
require a runtime), but it was never the point of betterC to 
strip out a bunch of D features. That's just the natural


It is what it is and if what it is is the best tool to fix a 
problem I would not hesitate to use it to that end.


But you make it sound like betterC _should only_ work if actual D 
code is called otherwise stick with good old C. From the POV of a 
C programmer most of what betterC offers is a net gain and 
nothing is a loss because what are they losing by upgrading from 
C? And in general not paying for something you don't use or need 
is considered a gain, no?


consequence of the goal of being callable from C code without 
needing to worry about druntime.
All of those features that betterC can't use can be avoided in 
normal D code if you don't want them for whatever reason. 
nothrow is actually one of the few cases where you have to 
explicitly do something in order to avoid that list of features 
that you have there. In the other cases, you just don't use the 
feature, and the only cost you're paying is the startup and 
shutdown time for druntime and the few resources that it uses.


Please tell me. How would I disable just the Error mechanism, for 
example ?
As far as I can tell it's not sufficient that I don't use nothrow 
in my code because if it was used in phobos or druntime or some 
other D code I'd have to deal with it.


But I know the answer to that. It's not possible because it was 
never considered because why would anyone want to do that and 
have the program just crash.


Let's say I don't want to deal with OutOfMemoryError. That means 
essentially I'm losing the GC. Which sucks big time as it is 
_the_ selling point for me to use D over C.


Let's say I didn't agree with RangeError for assoc. Arrays. I 
imagine it allocates dynamically and hence has a dependency on 
the GC so I have to consider the OutOfMemoryError headache even 
if I would agree to RangeError. Solution again don't use it and 
implement my own.


Really, I don't see the diff

Re: What is the point of nothrow?

[wjoe via Digitalmars-d-learn]

On Tuesday, 12 June 2018 at 18:41:07 UTC, Jonathan M Davis wrote:
On Tuesday, June 12, 2018 17:38:07 wjoe via Digitalmars-d-learn 
wrote:
On Monday, 11 June 2018 at 00:47:27 UTC, Jonathan M Davis 
wrote:
> On Sunday, June 10, 2018 23:59:17 Bauss via 
> Digitalmars-d-learn

> wrote:
> Errors are supposed to kill the program, not get caught. As
> such, why does it matter if it can throw an Error?
>
> Now, personally, I'm increasingly of the opinion that the 
> fact that we have Errors is kind of dumb given that if it's 
> going to kill the program, and it's not safe to do clean-up 
> at that point, because the program is in an invalid state, 
> then why not just print the message and stack trace right 
> there and then kill the program instead of throwing 
> anything? But unforntunately, that's not what happens, which 
> does put things in the weird state where code can catch an 
> Error even though it shouldn't be doing that.


Sorry for off topic but this means that I should revoke a 
private key every time a server crashes because it's not 
possible to erase secrets from RAM ?


The fact that an Error was thrown means that either the program 
ran out of a resource that it requires to do it's job and 
assumes is available such that it can't continue without it 
(e.g. failed memory allocation) and/or that the program logic 
is faulty. At that point, the program is in an invalid state, 
and by definition can't be trusted to do the right thing. Once


If memory serves a failure to malloc in C can easily be checked 
for success by comparing the returned pointer to null prior to 
accessing it. If the pointer is null this only means that memory 
allocation for the requested size failed. I fail to see how this 
attempt at malloc could have corrupted the entire program state 
invalid.
Why would it be inherently unsafe to free memory and try to 
malloc again.

But maybe it's an optional feature and could just be disabled.
But maybe it does mean that the program cannot continue.
I still don't see a need to force quit without the opportunity to 
decide whether it's an error to abort or an error that can be 
fixed during run time.


the program is in an invalid state, running destructors, scope 
statements, etc. could actually make things much worse. They 
could easily be operating on invalid data and do entirely the 
wrong thing. Yes, there are cases where someone could look at


could. Like erasing the hard drive ? But that could have happened 
already. Could be the reason of the error, in the first place. 
Destructors, scope statements etc. could also still work 
flawlessly and it could become worse because of not exiting 
gracefully. Data not synced to disk, rollback not executed, vital 
shutdown commands omitted.


what's happening and determine that based on what exactly went 
wrong, some amount of clean-up is safe, but without knowing 
exactly what went wrong and why, that's not possible.




But Errors have names, or codes. So it should be possible to 
figure out what or why. No?
In case of an out of memory error, maybe the error could be 
resolved by running the GC and retry.


I'm afraid I really can't grasp the idea why it's the end of the 
world because an Error was thrown.


And remember that regardless of what happens with Errors, other 
things can kill your program (e.g. segfaults), so if you want a 
robust server application, you have to deal with crashes 
regardless. You can't rely on your program always exiting 
cleanly or doing any proper clean-up, much as you want it to 
exit cleanly normally. Either way, if your program is crashing


it is possible to install a signal handler for almost every 
signal on POSIX, including segfault. The only signal you can't 
catch is signal 9 - sigkill if memory serves.
So I could for instance install a clean up handler on a segfault 
via memset, or a for loop, and then terminate.


If program state, and not necessarily just my own programs but 
any programs that store secrets in RAM, is to be considered 
invalid on a thrown Error, and I cannot rely on proper clean up, 
I must consider a secret leaked as soon as it is stored in RAM at 
the same time an Error is thrown.


Therefore the only conclusion is that such a language is not safe 
to use for applications that handle sensitive information, such 
as encrypted email, digital signing, secure IM or anything that 
requires secrets to perform it's work.
This is really sad because I want to think that improved 
technology is actually better than it's precursors.
What I would hope for is a mechanism to help the developer to 
safely handle these error conditions, or at least gracefully 
terminate. Now I understand that nothing can be done about 
program state actually messed up beyond repair and the program 
terminated by the OS but just assuming all is FUBAR because of 
throw Error is cheap.


frequently enough that the lack of clean-up poses a real 
problem, the

Re: What is the point of nothrow?

[wjoe via Digitalmars-d-learn]

On Wednesday, 13 June 2018 at 03:14:33 UTC, Jonathan M Davis 
wrote:
Most programs do not handle the case where they run out of 
memory and cannot continue at that point. For better or worse, 
D's GC was designed with that in mind, and it treats failed 
allocations as an Error. In the vast majority of cases, this is 
desirable behavior. In those cases when it isn't, alternate 
memory allocation schemes such as malloc can be used. But


But manual memory management sucks and is a huge waste of 
everyone's time and I was hoping to get the best from both worlds 
:)


regardless of whether the decision to treat failed memory 
allocations as an Error was a good one or not, the fact remains 
that as soon as an Error is thrown, you lose the ability to 
deal with things cleanly, because full clean up is not done 
when an Error is thrown (and can't be due to things like how 
nothrow works). So, regardless of whether a failed memory 
allocation is a condition that can be recovered from in 
principle, the way that D handles GC allocations make it 
unrecoverable in practice - at least as far as GC-allocated 
memory is concerned.




Did I get that right?
You say when an error is thrown destructors, scope statements, 
etc. are not executed - if declared as nothrow because the 
exception handler mechanism stuff is missing, is that correct?
And it does execute if not declared as nothrow but can't be 
relied upon because some other  nothrow functions could have 
omitted some of those statements?


So I shoot myself in the foot with nothrow and if I don't use it 
I'm still in a world of hurt?


I understand the idea that an Error is not supposed to be caught 
but why would such a 'feature' be desirable? Where's the benefit 
if nothing can be relied upon ?


If all errors would be treated like an exception, the developer 
could decide whether it is an error which needs to terminate 
right away or be able to handle the issue and continue or 
gracefully shutdown. Could even set a break point or force a core 
dump right there.
If the exception would be ignored the program will crash 
regardless but at least there would be a stack trace that I could 
rely upon instead of this unreliable and possibly corrupt state 
which is good for nothing.


This concept is a bit like color everyone with the same brush or 
one shoe fits all. Where in reality it depends on the 
circumstances whether it is an error or an exception.
But maybe I feel that way because currently there's a bit of a 
blur regarding what's defined as Errors and Exceptions.


Anyways I took a lot from your awesome explanations so far. 
Thanks a ton!

Re: What is the point of nothrow?

[wjoe via Digitalmars-d-learn]

On Wednesday, 13 June 2018 at 13:05:44 UTC, Kagamin wrote:

On Wednesday, 13 June 2018 at 10:56:41 UTC, wjoe wrote:
I understand the idea that an Error is not supposed to be 
caught but why would such a 'feature' be desirable? Where's 
the benefit if nothing can be relied upon ?


It's a debugging facility for development stage that allows to 
print the error message and stack trace instead of silent 
termination. Because it still needs to be caught for this, 
explicit catch still works, but other cleanup mechanisms don't.


My question was more like what's the benefit of having thrown 
Errors corrupt your program state  rendering it useless for 
debugging ?

Re: What is the point of nothrow?

[wjoe via Digitalmars-d-learn]

On Wednesday, 13 June 2018 at 12:59:27 UTC, Kagamin wrote:

On Wednesday, 13 June 2018 at 02:02:54 UTC, wjoe wrote:
it is possible to install a signal handler for almost every 
signal on POSIX, including segfault. The only signal you can't 
catch is signal 9 - sigkill if memory serves.
So I could for instance install a clean up handler on a 
segfault via memset, or a for loop, and then terminate.


What will you do with this? 
https://github.com/dlang/druntime/blob/master/src/core/internal/abort.d


Are you asking what I would do in case sigabrt is received by my 
program instead of sigsegv ?


I would install the same cleanup functionality in this handler. 
Zero out memory, send a signal to stop an engine or whatever 
mandatory clean up is required and return from the handler. Then 
let the OS take care of the rest, i.e. terminate the process.

Re: What is the point of nothrow?

[wjoe via Digitalmars-d-learn]

On Tuesday, 12 June 2018 at 15:48:58 UTC, Bauss wrote:


Ex.

int a = array[400];

Could yield a warning stating a possible a out of bounds error.

Where:

int a = array.length >= 401 ? array[400] : 0;



looks to me like a crash guard. Similar to something like this

void fn(Foo* foo)
{
  if (foo)
//do stuff
}

program now crashes somewhere else when foo is null or invalid.

Re: What is the point of nothrow?

[wjoe via Digitalmars-d-learn]

On Monday, 11 June 2018 at 00:47:27 UTC, Jonathan M Davis wrote:
On Sunday, June 10, 2018 23:59:17 Bauss via Digitalmars-d-learn 
wrote:
Errors are supposed to kill the program, not get caught. As 
such, why does it matter if it can throw an Error?


Now, personally, I'm increasingly of the opinion that the fact 
that we have Errors is kind of dumb given that if it's going to 
kill the program, and it's not safe to do clean-up at that 
point, because the program is in an invalid state, then why not 
just print the message and stack trace right there and then 
kill the program instead of throwing anything? But 
unforntunately, that's not what happens, which does put things 
in the weird state where code can catch an Error even though it 
shouldn't be doing that.


Sorry for off topic but this means that I should revoke a private 
key every time a server crashes because it's not possible to 
erase secrets from RAM ?

Re: What is the point of nothrow?

[wjoe via Digitalmars-d-learn]

On Wednesday, 13 June 2018 at 20:08:06 UTC, Jonathan M Davis 
wrote:
On Wednesday, June 13, 2018 10:56:41 wjoe via 
Digitalmars-d-learn wrote:

On Wednesday, 13 June 2018 at 03:14:33 UTC, Jonathan M Davis
> regardless of whether the decision to treat failed memory 
> allocations as an Error was a good one or not, the fact 
> remains that as soon as an Error is thrown, you lose the 
> ability to deal with things cleanly, because full clean up 
> is not done when an Error is thrown (and can't be due to 
> things like how nothrow works). So, regardless of whether a 
> failed memory allocation is a condition that can be 
> recovered from in principle, the way that D handles GC 
> allocations make it unrecoverable in practice - at least as 
> far as GC-allocated memory is concerned.


Did I get that right?
You say when an error is thrown destructors, scope statements,
etc. are not executed - if declared as nothrow because the
exception handler mechanism stuff is missing, is that correct?
And it does execute if not declared as nothrow but can't be
relied upon because some other  nothrow functions could have
omitted some of those statements?


Yes, and there's no guarantee that clean-up will occur even if 
nothing is nothrow. While the current implementation will do


Good to know. The thought crossed my mind to remove nothrow from 
all functions... ;)


clean-up in those cases, it didn't used to, and Walter has 
repeatedly stated that it is not guaranteed to do so. Errors 
are _not_ intended to be caught and recovered from. They're 
essentially a segfault that prints a message and stack trace 
but which for some reason uses the exception throwing mechanism 
to get to the code that prints the message and exits the 
program.




So the program is in a stable enough state to run the exception 
handling mechanism to print a message and die, but not stable 
enough to run a memset or writePin(11,0) before continuing 
trampling forward to where the printing and dying happens ?


So I shoot myself in the foot with nothrow and if I don't use 
it I'm still in a world of hurt?


I understand the idea that an Error is not supposed to be 
caught but why would such a 'feature' be desirable? Where's 
the benefit if nothing can be relied upon ?


If all errors would be treated like an exception, the 
developer could decide whether it is an error which needs to 
terminate right away or be able to handle the issue and 
continue or gracefully shutdown.


The idea is that because your program is in an invalid state, 
attempting a graceful shutdown is unsafe. But regardless of 
whether you agree with that, the fact that nothrow doesn't do 
clean-up pretty much ensures that it isn't safe in the general 
case, and nothrow can't do clean-up without negating one of the 
main reasons that it exists in the first place - which is to



that fact also means that a program which threw an Error cannot 
be debugged anymore; because of invalid state you can neither 
know, nor assume, that what you see in your debugger or core dump 
is actually the state which led to the throw.



improve performance by not emitting exception-handling code.


if performance matters so much I would use betterC.

'Improving' performance without profiling and such a trade-off is 
a bad idea. If it were opt in - yes, I know I will get 
undebuggable code on error thrown but I want or need the 
performance gain, fair enough. But instead you are a victim of 
that implementation whether you like it or not and you might not 
even be aware about it.





Could even set a break point or force a core
dump right there.


The fact that Errors don't immediately kill the program and 
instead sort of unwind the stack is a definite problem for 
getting good debug information on crashes. I suspect that 
Walter doesn't quite understand the issues here, because 
whenever anyone raises issues related to stuff like this, he 
has a tendancy to basically tell people to rerun their program 
- which works fantastically in the world he typically programs 
in (compilers) but doesn't work very well with stuff like OSes 
or server programs where you frequently have no clue how to 
replicate the problem. My guess is that Errors work they do in 
part because he's not used to debugging situations where a 
coredump being created at the point of failure the first time 
it happens (rather than during attempts to reproduce the 
problem) is what you really need.




Or any program which is interactive or where input is non 
deterministic.


Out of curiosity, in case of out of memory, will the program 
crash trying to throw OutOfMemoryError or is it pre-allocated 
along with the memory needed to format and print the message?


And out of curiosity again, where would I find this place where 
the printing and terminating occurs ?



I think that the reasons that this is not a bigger problem than 
it is stem primarily from the fact that Errors are going to be 
very 

Re: What is the point of nothrow?

[wjoe via Digitalmars-d-learn]

On Thursday, 14 June 2018 at 22:27:42 UTC, bauss wrote:
On Thursday, 14 June 2018 at 19:06:07 UTC, Jonathan M Davis 
wrote:
So in case of a thrown Error, you can catch it and log it to a 
database.




No, you can't. Once the Error was thrown the program is in 
invalid state and you can't assume the logging to database will 
succeed.


If I understood Johnathan's explanations correctly, you can't 
even be sure that the Error can be caught, since its only purpose 
is to jump to the print and abort function.


This is exactly what I was asking about. Logging, cleanup, 
executing an emergency stop..not possible.

Re: What is the point of nothrow?

[wjoe via Digitalmars-d-learn]

On Friday, 15 June 2018 at 17:27:13 UTC, bauss wrote:

On Friday, 15 June 2018 at 17:25:18 UTC, wjoe wrote:

On Thursday, 14 June 2018 at 22:27:42 UTC, bauss wrote:
On Thursday, 14 June 2018 at 19:06:07 UTC, Jonathan M Davis 
wrote:
So in case of a thrown Error, you can catch it and log it to 
a database.




No, you can't. Once the Error was thrown the program is in 
invalid state and you can't assume the logging to database 
will succeed.


Sure you can assume it will succeed, BUT in 9/10 cases it will 
and in those cases it's worth it.


I do that and it has proven to work every single time for me.

You can't assume it will succeed writing to a log file either.

In either cases you just have to try and hope for the best.


Casting away const 'works' too, but is undefined behavior and is 
not guaranteed to work in  future implementations.
Likewise, this may work in the current implementation but there's 
no guarantee that's to stay.

At the time of throw Error the program must be considered dead.
It sucks, but even if something was logged to the DB you can't 
rely on this information to be correct.
Please read Jonathan's posts further up, he explained the 
internals and Walter Bright's reasoning in detail.

Re: What is the point of nothrow?

[wjoe via Digitalmars-d-learn]

On Friday, 15 June 2018 at 08:13:44 UTC, Kagamin wrote:

On Wednesday, 13 June 2018 at 17:08:26 UTC, wjoe wrote:
My question was more like what's the benefit of having thrown 
Errors corrupt your program state  rendering it useless for 
debugging ?


D allows various levels of performance and safety. Though I'd 
say Errors not working in debug mode is not intended, the


Intention matters not. By definition all program state is invalid 
at the point an Error was thrown. From there on it is impossible 
to rely on any output, too, because it could be either correct, 
corrupted, or completely invalid.
Your objects might have been destructed, or maybe not or maybe 
just partially.

The only thing safe to assume is that what you've got is useless.


optimization should work in release mode which implies debugged 
code and assumes there are no Errors thrown and you get extra 
optimization for nothrow functions. Errors are a cheap way to 
print diagnostic, because you need to do it for unhandled 
exceptions anyway and it's cross-platform too unlike debugger.


A core dump is created by the OS. In a format that a native 
debugger understands.


Also leaf functions don't know anything about environment and 
can't do meaningful I/O, e.g. realistically you have standard 
output only in console applications and not in other 
applications.


Exactly. You may not have a console at all, like eg. in Windows 
for the most part, or even Linux if you launch the program from a 
toolbar button, and what about headless configurations. What good 
is printing to stderr in these cases ?


The only sensible thing to do in case of an unrecoverable Error 
is to transfer control back to the OS right away and let it 
handle the rest.
A mechanism of Errors thrown like Exceptions is too tempting to 
mess around with.


Scott Meyers wrote in one of his books, I forget which, that your 
design should be easy to use correctly and hard or impossible to 
use incorrectly. This is not true for D Errors.

Re: What is the point of nothrow?

[wjoe via Digitalmars-d-learn]

On Thursday, 14 June 2018 at 19:06:07 UTC, Jonathan M Davis wrote:
On Thursday, June 14, 2018 18:11:20 wjoe via 
Digitalmars-d-learn wrote:
On Wednesday, 13 June 2018 at 20:08:06 UTC, Jonathan M Davis 
wrote:

> On Wednesday, June 13, 2018 10:56:41 wjoe via
> The idea is that because your program is in an invalid state,
> attempting a graceful shutdown is unsafe. But regardless of
> whether you agree with that, the fact that nothrow doesn't do
> clean-up pretty much ensures that it isn't safe in the 
> general
> case, and nothrow can't do clean-up without negating one of 
> the

> main reasons that it exists in the first place - which is to

that fact also means that a program which threw an Error 
cannot be debugged anymore; because of invalid state you can 
neither know, nor assume, that what you see in your debugger 
or core dump is actually the state which led to the throw.


As I said, personally, I think that the program shut just print 
and terminate rather than throwing an Error. Walter seems to 
have designed things from the premise that you could rerun the 
program to reproduce the problem (which in is usually true with 
the programs he works on). And in that case, simply getting the 
error message and stacktrace would be plenty. The problem is 
when you can't simply rerun the program to reproduce the 
problem and is why I'm of the opinion that printing and 
terminating would be better than throwing an Error.



> improve performance by not emitting exception-handling code.

if performance matters so much I would use betterC.

'Improving' performance without profiling and such a trade-off 
is a bad idea. If it were opt in - yes, I know I will get 
undebuggable code on error thrown but I want or need the 
performance gain, fair enough. But instead you are a victim of 
that implementation whether you like it or not and you might 
not even be aware about it.


betterC really has nothing to do with performance. It just has 
to do with avoiding druntime so that you can have C code just 
link in and use the D code as if it were C (though using it 
would avoid the issue of Errors, since the runtime wouldn't be 
there to handle them). And again, Errors are intended for fatal 
cases, so most of the concerns about doing clean-up are 
irrelevant. Attempting to recover from an Error is considered 
to be like attempting to recover from a segfault, which is a 
terrible, terrible idea. And there are plenty of folks who want 
to be able to have their code be more performant when it's not 
using exceptions. So, as long as folks aren't trying to catch 
Errors, the fact that nothrow doesn't emit the exception 
handling code really isn't a problem.




What you said earlier:
On Monday, 11 June 2018 at 00:47:27 UTC, Jonathan M Davis wrote:


[...]

2. If the compiler knows that a function can't throw an 
Exception, then it doesn't have to insert any of the Exception 
handling mechanism stuff [...] So, the fact that a function is 
nothrow gives you a performance benefit, [...]


- Jonathan M Davis


made me believe that performance is one of the major reasons to 
use it. No?


From the betterC page https://dlang.org/spec/betterc.html section 
40.2:

---
Not Available

D features not available with BetterC:

Garbage Collection
TypeInfo and ModuleInfo
Classes
Built-in threading (e.g. core.thread)
Dynamic arrays (though slices of static arrays work) and 
associative arrays

Exceptions
switch with strings
final switch
synchronized and core.sync
Static module constructors or destructors
Struct destructors
unittest (testing can be done without the -betterC flag)
---
Apart from a few convenience features lost this list reads like a 
shopping list for performance gain over full fledged D, in the 
spirit of nothrow omitting exception handling mechanism, to me. 
You gain from no garbage collection overhead, no vtable overhead, 
no RTTI overhead, no exception overhead, etc, etc, ...


Back in the late 90ies I used to write the lion's share of code 
in Pascal and implement mission critical algorithms in asm. 
Worked back then why wouldn't it work today, except that I 
wouldn't use asm anymore but something like C or betterC.


Thus, people who need this kind of performance boost can benefit 
2 fold from using betterC.
1. They get to keep most of D's awesomeness, including compile 
time features, scope statements, RAII, lack of a pre processor, 
memory safety protections and complete meta programming, are just 
_some_ of the highlights. And on the other hand
2. they gain by getting rid of a lot the 'performance hogs' like 
GC, exceptions and more, right?
And, with no exceptions altogether they do not need to worry 
about it at all.


I'm sold!


And out of curiosity again, where would I find this place 
where the printing and terminating occurs ?


I'd have to go digging in druntime. I don't know. I've probably 
seen it before, but it's not code that

How to force DUB to make and use a dynamic library

[wjoe via Digitalmars-d-learn]

Hello,

I'm not sure if this belongs here, so, sorry if it doesn't.

The problem I have is this as follows:
given...
...a C library, let's call it libfoo, which implements an API
...a D library, libbar, which wraps the libfoo API and provides 
some additional convenience functions; in the DUB config I 
specify target dynamicLibrary

...a D program which links against libbar

If I add libbar in the program's dub config like so:

dependency "libbar" version\"~master" path\"./libbar"

DUB will create a dynamic library if I invoke it in the library 
directory but will make a static library if it's invoked from the 
program directory, link against it and fail because it can't find 
symbols from libfoo


if I specify a subPackage like so:
subPackage {
  name "bar"
  targetType "dynamicLibrary"
  sourcePaths "./libbar/source/"
  dflags "-I./libbar/source/"
}

and add it like so:

dependency ":bar" version="*"

DUB still only builds a static library and linking fails because 
of missing libfoo  symbols.


If I add a linker option to also link against libfoo it still 
doesn't work, with the same symbols, even when libfoo is added 
after libbar.


But even if that would work that's not the point.

The question is how do I have DUB honor the dynamicLibrary target 
and create and link against libbar dynamically, which links to 
libfoo dynamically.


Extra question - is there something like CMake to replace DUB?
I'm really not fond of DUB, at all.
Like any 1 click solution it's great when it works and when it 
doesn't it's a major PITA.
Verbose output sucks because it's hard to read because it's 
flooding dozens of pages with several lines long paths containing 
UUIDs and a thousand times nested paths.
Also it's inconvenient that there are no man pages for DUB so I 
need to go online whenever I need to refer to the manual. Sooo 
annoying.


I appreciate the DUB team putting a ton of effort into it and 
making it available for free and my intention is not to call it a 
bad program or something. It's just incompatible with my work 
flow.
So if anyone knows alternatives more in the spirit of make and 
CMake, I'd like to try them...


Anyways, thanks for your time

Re: What is the point of nothrow?

[wjoe via Digitalmars-d-learn]

On Thursday, 21 June 2018 at 19:52:25 UTC, Jonathan M Davis wrote:
On Thursday, June 21, 2018 13:16:28 wjoe via 
Digitalmars-d-learn wrote:

On Wednesday, 20 June 2018 at 12:22:33 UTC, Kagamin wrote:


> Do you know how to extract information from it on an 
> unfamiliar OS? Reading stack trace is easier and 
> self-evident.


Counter question: How do you develop for an unfamiliar OS with
unfamiliar tools in the first place ?
The concept of a debugger and a memory dump is fundamentally 
the
same on every OS I know or care about just as much as the D 
error

implementation doesn't care about niche cases.

Of course you can debug your applications via print to console 
if you feel that this is productive enough and ignore the bugs 
you can't fix that way.


Simply having a stack trace would be plenty in many cases, and 
if you're primarily developing an a different OS from the one 
the user was on when the error occurred, getting a stack trace 
may allow you to see what the problem is and fix it without 
setting up a debugger on the OS that the user was running 
(which could be a huge timesaver if you don't normally use that


That is if that other OS provides the means to print one and the 
user is skilled enough to relay that info to the developer.
There's apparently no other option. Because as I learned here 
that installing your own crash handler, for instance, which 
writes this stack trace to a file and submits a crash report to 
the developer, is not possible.


Additionally, you might end up empty handed in case of a daemon 
since best practice in this domain is to close stdin/out/err to 
prevent them to litter the terminal with output and/or they may 
be runnig headless and this kind of output would never be seen.


OS). That being said, the optimal solution is likely printing 
out the error message and stack trace, and then giving a 
coredump (or the OS' equivalent) at the point of the failure. 
Then if the message and stack trace are enough, you're good to 
go, and if you need the coredump to get more detailed 
information, then you have it.


- Jonathan M Davis


Those who are comfy rarely see the needs of others. My attempt in 
this regard was to show how it feels like not to have that info.

Re: What is the point of nothrow?

[wjoe via Digitalmars-d-learn]

On Tuesday, 19 June 2018 at 12:26:15 UTC, Kagamin wrote:

On Friday, 15 June 2018 at 17:46:02 UTC, wjoe wrote:
D allows various levels of performance and safety. Though I'd 
say Errors not working in debug mode is not intended, the


Intention matters not. By definition all program state is 
invalid at the point an Error was thrown. From there on it is 
impossible to rely on any output, too, because it could be 
either correct, corrupted, or completely invalid.


The program is in invalid state when it hits a bug before Error 
is thrown, this is seen as a property of a buggy algorithm, 
Error is thrown only as a diagnostic of a bug that has happened 
already. The state is invalid in a sense that the program 
shouldn't continue to serve its intended purpose. Even if Error 
was technically correctly unwound, it won't necessarily provide 
a correct cleanup when algorithm doesn't expect an exception.
Though in case of D situation may be not as clear as there is 
safe code, but we just recently had a nasty memory corruption 
bug caused by incorrect trusted code.




I wrote that 4 days ago. I lost some sleep over that matter and 
am long past the idea of trying to correctly clean up in this 
situation. You would know that had you read my more recent posts.


A core dump is created by the OS. In a format that a native 
debugger understands.


Most of the time a stack trace is enough to diagnose the error


I'll say it again. The program must have a console(like) device 
attached. Otherwise you will not have a stack trace - or at least 
it needs to be redirected to a file but that's not very newbie 
friendly either because each shell has their own way of doing it 
and csh, for example, can't even redirect individually. I'm not 
sure about Windows. Even if possible, considering the heavy focus 
on GUI, I doubt it's considered best practices there and is a 
PITA for sure.


But maybe I missed something else and the only purpose of D is to 
make console applications for *NIX like OSs and expect users to 
be professional enough to save that stack trace before they close 
the terminal ?


And how can you be sure that this bug didn't corrupt memory of 
the druntime or anything else related to the stack trace, or even 
that it is a single bug ?


And how useful is a stack trace that shows a back trace to the 
point of the location the Error was thrown compared to a back 
trace to the location of the bug (report)?



and provides a better UX than a core dump (especially to


Please explain. A core dump has everything a printed stack trace 
has and more and is as easy as using the debugger itself.


newbies). I saw gdb crash trying to make sense of a debugged 
program too. Runtime allows to override failure handlers, but 
it's not centralized.


And what guarantee is there that the runtime doesn't crash trying 
to print a stack trace ? Could happen just as likely.

Re: What is the point of nothrow?

[wjoe via Digitalmars-d-learn]

On Wednesday, 20 June 2018 at 12:22:33 UTC, Kagamin wrote:

On Tuesday, 19 June 2018 at 15:03:49 UTC, wjoe wrote:
But maybe I missed something else and the only purpose of D is 
to make console applications for *NIX like OSs and expect 
users to be professional enough to save that stack trace 
before they close the terminal ?


I just read stack trace from console.
Initially D ecosystem focused on windows console applications, 
linux support came later, and compiling windows gui application 
is not straightforward. Simply because console support is the 
first thing to implement.


And how can you be sure that this bug didn't corrupt memory of 
the druntime or anything else related to the stack trace, or 
even that it is a single bug ?


The state is invalid in a sense that program shouldn't continue 
to serve its intended purpose.


Either it is invalid, or if it is safe for the druntime to assume 
that it's safe to do whatever it does, then it's just as safe to 
assume that an installed signal handler called by the OS is doing 
it's thing just fine as well, like stopping a motor.


And how useful is a stack trace that shows a back trace to the 
point of the location the Error was thrown compared to a back 
trace to the location of the bug (report)?


In most cases stack trace is enough to diagnose the error.


In most cases errors are easy to fix, too. I worry about the 
corner cases. The really annoying bugs. The bugs you might only 
get one shot at because you don't know how to reproduce, which 
you can only diagnose and fix via post mortem debugging.





and provides a better UX than a core dump (especially to


Please explain. A core dump has everything a printed stack 
trace has and more and is as easy as using the debugger itself.


Do you know how to extract information from it on an unfamiliar 
OS? Reading stack trace is easier and self-evident.


Counter question: How do you develop for an unfamiliar OS with 
unfamiliar tools in the first place ?
The concept of a debugger and a memory dump is fundamentally the 
same on every OS I know or care about just as much as the D error 
implementation doesn't care about niche cases.


Of course you can debug your applications via print to console if 
you feel that this is productive enough and ignore the bugs you 
can't fix that way.

Re: What is the point of nothrow?

[wjoe via Digitalmars-d-learn]

On Monday, 18 June 2018 at 20:23:48 UTC, Jonathan M Davis wrote:
On Monday, June 18, 2018 15:22:48 wjoe via Digitalmars-d-learn 
wrote:
On Saturday, 16 June 2018 at 21:25:01 UTC, Jonathan M Davis 
wrote:
> every feature that you can't use in betterC is considered a 
> loss, and efforts are being made to make more of them work. 
> There's always going to be a limit to that, and some D 
> features just plain require druntime (just like some of 
> C++'s features require a runtime), but it was never the 
> point of betterC to strip out a bunch of D features. That's 
> just the natural


It is what it is and if what it is is the best tool to fix a 
problem I would not hesitate to use it to that end.


But you make it sound like betterC _should only_ work if 
actual D code is called otherwise stick with good old C. From 
the POV of a C programmer most of what betterC offers is a net 
gain and nothing is a loss because what are they losing by 
upgrading from C? And in general not paying for something you 
don't use or need is considered a gain, no?


I'm saying that -betterC is a subset of D that does not include 
D's runtime, and it includes as many of D's features as it 
currently can without using the runtime. You can choose to use 
it and never use normal D code, but the reason that it was 
created in the first place was so that it would be easier to 
port C code to D. Without -betterC, you tend to be forced to 
port the entire program at once, whereas with it, you can port 
it in pieces and then only switch to normal D once everything 
has been ported over. But there are some folks who elect to 
just write code targetting -betterC and who never intend for it 
to work as normal D code.


That's not how it came across.
It came across like the _entire_ purpose of it is to call D stuff 
without the need to deal with the druntime and nothing else.


Please tell me. How would I disable just the Error mechanism, 
for

example ?
As far as I can tell it's not sufficient that I don't use 
nothrow

in my code because if it was used in phobos or druntime or some
other D code I'd have to deal with it.


As with pretty much every other feature, if you don't want any 
Errors, you just don't use anything that uses it. The same goes 
with the GC and other features that you might choose to avoid. 
In some cases, that can be quite limiting, but it is possible 
to avoid it. It's simply that just like with any feature, 
avoiding it means losing out on features.


So basically everything safe for what is betterC.

The primary difference with nothrow over most other features is 
that the compiler inserts code by default for Exceptions if 
nothrow isn't there. So, using nothrow is required to turn that 
off, whereas for most other features, they only get used if you 
choose to use them (or use something that uses them). But it 
has nothing to do with Errors either way. The only way to avoid 
those is to never use a feature that could throw them (which 
can be done but would be so limiting that it's probably a waste 
of time).


If having the program crash due to an error condition being 
considered fatal is unacceptable to you, then D will be


I never made that claim. Unacceptable to me is the implemented 
mechanism.


unacceptable to you - including with -betterC, since in that 
case, the Errors get turned into failed C assertions that 
aren't compiled out. So, you won't get the stack unwinding, but 
your program will be purposefully killed either way, because it 
encountered an error condition that is considered fatal. You're


yes, it will be terminated via sigabrt. Which is the way it's 
supposed to be.
Not to continue running to a function that prints possibly 
invalid stuff, iff a console like device is attached, and abort 
in a central, completely unrelated, part of the druntime.

If no console is attached, you'll end up with nothing.

Seriously, the entire mechanism is contradicting itself. How can 
it declare program state invalid and unfit to continue at the 
point the Error was detected and thrown but do it regardless ?


free to disagree with that approach, and you're free to 
disagree with which error conditions are considered fatal, but 
it's part of using D. So, you'll either have to learn to live 
with that or use a different language.


- Jonathan M Davis


One could also argue that Exceptions are an integral part of 
using D and there is really never a situation where you need to 
turn it off just like there is never a situation where you would 
catch an Error. Deal with it.


If a programming language doesn't so much as to help the 
developer to be more productive, e.g. by making it easier to 
squash bugs but, by definition i.e. invalid program state, make 
it impossible to troubleshoot them, then this language is at 
least a bad decision from an economic point of view. Which makes 
it a toy language.


I know that much of what can be done actually works in practice 
but that's n

DUB conditional subPackage possible?

[wjoe via Digitalmars-d-learn]

I want to include subPackages depending either on the presence of 
command line options, or the availability of dependencies; think 
Gentoo USE flags.


As far as I can tell it's not possible to specify configurations 
in a modular  way, e.g.


 dub --config=withGUI --config=supportGTK --config=supportOpenGL 
--config=supportPhysFS


And specifying a non-existent dependency halts the build.

"subConfiguration" looks like what I want but I can't really make 
sense of it. There's just a one liner about it in the manual.


Is there a more verbose example ?

Re: What Does @ Mean?

[wjoe via Digitalmars-d-learn]

On Monday, 8 April 2019 at 12:16:13 UTC, Adam D. Ruppe wrote:

On Monday, 8 April 2019 at 11:58:49 UTC, Ron Tarrant wrote:
And while I'm asking, does an underscore have special meaning 
when used either at the beginning or end of a variable name?


Nothing special there, you are allowed to use the _ anywhere in 
a name. Some people use it as a convention on private members, 
unused members, or keyword conflicts (like `body_` so the 
compiler doesn't see it as the keyword `body`).




It's not entirely related but another use of the underscore is to 
make integers more readable. E.g.:


int x = 1_000_000_000_000;

Re: 1 - 17 ms, 553 ╬╝s, and 1 hnsec

[wjoe via Digitalmars-d-learn]

On Thursday, 16 May 2019 at 15:52:05 UTC, Steven Schveighoffer 
wrote:

On 5/16/19 4:27 PM, Vladimir Panteleev wrote:

On Thursday, 16 May 2019 at 15:19:03 UTC, Alex wrote:



What's an hnsec anyways?


Hecto-nano-second, the smallest representable unit of time in 
SysTime and Duration.


The output shouldn't involve the inner workings of the type. It 
should be changed to say 10 ns.


-Steve


It's 100ns. 10ns = 1dans = 1 deka-nano-second.
deka = 10, hecto = 100 [1]

[1] 
https://www.nist.gov/pml/weights-and-measures/metric-si-prefixes

Re: [windows] Can't delete a closed file?

[wjoe via Digitalmars-d-learn]

On Thursday, 9 May 2019 at 10:09:23 UTC, Cym13 wrote:

Hi,

this is likely not related to D itself but hopefully someone 
can help me with this since I'm rather new to windows 
programming, I mainly work on linux. I'm trying to bundle a DLL 
in a binary, write it in a temp folder, use it and remove the 
dangling file.


[...]


That's a windows "feature". You can't delete files that are in 
use. The fact that you close the file in your program isn't a 
guarantee that there's no other open handles around.


For the same reason you have to restart windows after every 
update to apply it.

Re: Setting default values for Main function's args Array

[wjoe via Digitalmars-d-learn]

On Thursday, 27 June 2019 at 17:05:05 UTC, Vaidas wrote:
Is it possible to set the default values for the Main 
function's arguments?

It seems that I'm getting Range error.


import std.stdio : writeln;
void main(string[] args = ["asdsfasdf", "asdklfajsdk", 
"asdfasdfasd"]){


   writeln("", args[1]);
}


Output:

vaidas@vaidas-SATELLITE-L855:~/Desktop$ rdmd newfile.d

core.exception.RangeError@newfile.d(4): Range violation


??:? _d_arrayboundsp [0x555f5b79f8e9]
??:? _Dmain [0x555f5b79e7ee]


consider this:

module d-program;

void main(string[] args)
{
  import std.stdio;
  writeln("args = ", args);
}

---

~/> ./d-program abc def

Output:
args = ["~/d-program", "abc", "def"]

---

~/> ./d-program

Output:

args = ["~/d-program"]

Re: Abstract classes vs interfaces, casting from void*

[wjoe via Digitalmars-d-learn]

On Saturday, 10 August 2019 at 08:20:46 UTC, John Colvin wrote:

On Friday, 9 August 2019 at 13:39:53 UTC, Simen Kjærås wrote:




Thanks for the extra detail.

Is there a solid reason to ever use an interface over an 
abstract class? (Other than multiple inheritance).


I'm such a noob at anything related to OO.


The way I look at it: an interface is a guarantee. By saying

interface A { void foo()}
class B: A {}
class C: A {}

void bar(A a) {}

you guarantee that every class that implements interface A has a 
function foo and

and bar can be called with anything that implements interface A.
This is completely unrelated to inheritance.

An abstract class is an implementation, most likely a base class. 
By saying


abstract class A {void foo()}
class B: A {}
class C: B {}

void bar(A a) {}

you express that you want bar to be called with any subclass of A.

e.g. a bitmap button inherits from button which inherits from 
abstract class widget and implements the signal/slot interfaces.


Another pattern is design by introspection.
An interface defines what something _is_,
by introspection defines what something _CanDo_.
That's to say: I don't care if foo is actually (or inherits from) 
an InputRange as long as it behaves like it.

can DDOC generate files names including the full path ?

[wjoe via Digitalmars-d-learn]

For example if the source tree looks like this:

source/
  foo/
 baz.d
  bar/
 baz.d


and generating the docs with something like this:

 dmd -D -Dd=docs foo/baz.d bar/baz.d


the output looks like this:

docs/
 baz.html


one baz overwrites the other.


I'd like to have something like this:

docs/
   foo.baz.html
   bar.baz.html


There's the  -op  flag, but that litters the source tree with 
html files.
Neither the docs https://dlang.org/spec/ddoc.html nor google 
provided any insight.


Also there's more annoying behavior:

- Documentation generation fails if  -version  s are not provided 
resulting in a rather long command and it's tedious to manually 
keep track of it. Is there a way to make it only honor 
version(none) and treat all other -version s as a given ?


- if the  -o-  isn't provided, dmd complains about missing 
symbols. Why ? -D enables documentation mode, doesn't it?

Re: Desktop app with vibe.d

[wjoe via Digitalmars-d-learn]

On Monday, 12 August 2019 at 10:41:57 UTC, GreatSam4sure wrote:
Pls I want to know if it is possible to build desktop app with 
vibe.d just like nodejs. I am not satisfy with the GUI of Dlang 
such as dlangui and gtkd. I don't think they have good styling 
capabilities like HTML and CSS.


I will be happy if I can build an app in D with fanciful ui. I 
will also be happy if you know any other way to build a 
fanciful ui in D like adobe flex, javafx, etc.


Kai Nacke has a chapter (it's chapter 8) in his book "D Web 
Development / Packt Publishing"

Re: can DDOC generate files names including the full path ?

[wjoe via Digitalmars-d-learn]

On Monday, 19 August 2019 at 04:23:48 UTC, Jonathan M Davis wrote:

[...]


Thanks for the explanation. I'm in quite a dilemma now as I can't 
decide on which to choose :)

Re: What's opIndexAssign supposed to return ?

[wjoe via Digitalmars-d-learn]

On Tuesday, 25 February 2020 at 15:30:19 UTC, Ali Çehreli wrote:
On 2/25/20 3:02 AM, wjoe wrote:> Lets say I've got 3 overloads 
of opIndexAssign:

>
> auto opIndexAssign(T t);

> an internet search which didn't find any useful
> information.

I have examples for non-templatized and templatized versions of 
opIndexAssign here:



http://ddili.org/ders/d.en/operator_overloading.html#ix_operator_overloading.opIndexAssign


http://ddili.org/ders/d.en/templates_more.html#ix_templates_more.opIndexAssign%20template

I used this index to find those:

  http://ddili.org/ders/d.en/ix.html

Ali


This is great! Thank you. Curious why this wasn't found by my 
internet search.

How to dispatch a class function for an object accessed by handle?

[wjoe via Digitalmars-d-learn]

Consider a Factory that creates instances of various different 
resource object instances, all of which have a common interface, 
and returns a handle to them.


class Factory
{
   struct Handle{}

   Handle create(R: Resource, ARGS...)(ARGS args)
   {
  auto r = new R(args);
  //...
  return handle;
}
}

auto f = new Factory;
auto wallpaperhandle = f.create!Bitmap(...);


In order to be able do something with these resources there's a 
function to get the resource instance from a handle:


   auto get(R: Resource)(Handle h) {...};

auto bitmap = f.get!Bitmap(wallpaperhandle);
auto size = bitmap.getSize();
if (condition)
   bitmap.scaleByFactor(2);

I don't like this approach because it exposes the instance 
directly.

What I want instead is something like this

auto size = f.dispatch!(Bitmap, Bitmap.getSize)(wallpaperhandle);
if (condition)
   f.dispatch!(Bitmap, Bitmap.scaleByFactor)(wallpaperhandle, 2);

Implement this for free functions i would do something like this

void dispatch(alias fn, ARGS...)(Handle handle, ARGS args)
{
   fn(handle, args);
}


but how can I call fn in the context of an object instance?

class Factory {
  auto ref dispatch(R: Resource, alias fn, ARGS ...)(Handle 
handle, ARGS args)

  {
 auto r = get!R(handle);
 assert(stuff is valid);

 return r.fn(args); // How can I call class function 'fn' 
using r ?

  }
}

mixin(something) comes to mind, but are there better options ?

Re: How to dispatch a class function for an object accessed by handle?

[wjoe via Digitalmars-d-learn]

On Thursday, 5 March 2020 at 14:46:24 UTC, Steven Schveighoffer 
wrote:

On 3/5/20 9:24 AM, wjoe wrote:



but how can I call fn in the context of an object instance?


You could do it with delegates. But it's ugly:

import std.stdio;
class C
{
void foo() { writeln("Yup");}
}
void main()
{
alias f = C.foo;
auto c = new C;
void delegate() dg;
dg.funcptr = 
dg.ptr = cast(void*)c;
dg(); // prints "Yup"
}

I don't know of a way to call f with c aside from this.

-Steve


I have an ugly implementation with a one liner mixin and I don't 
like it. Your solution
looks interesting but I think that's more code than my current 
solution. Thanks for your reply though.

Re: How to dispatch a class function for an object accessed by handle?

[wjoe via Digitalmars-d-learn]

On Thursday, 5 March 2020 at 18:33:41 UTC, Adam D. Ruppe wrote:

On Thursday, 5 March 2020 at 14:24:33 UTC, wjoe wrote:
Implement this for free functions i would do something like 
this


void dispatch(alias fn, ARGS...)(Handle handle, ARGS args)


Why do you need an `alias fn` like that?

My suggestion would be to just use the `opDispatch` magic 
method that gives you a string, then `__traits(getMember, obj, 
memberName)(args)` to call it.


But if you specifically need the alias param that won't work as 
well. (You could still do `__traits(getMember, obj, 
__traits(identifier, fn))` though, so it isn't ruled out 
entirely, just not as nice. That is also more likely to break 
with overloads btw)


struct Handle {
private Whatever obj;

auto opDispatch(string name, Args...)(Args args) {
  return __traits(getMember, obj, name)(args);
}
}


And the usage would look like:

auto size = f.getSize(wallpaperhandle);


assuming the Handle knows how to store Whatever without being 
told what it is again at the call site (e.g. if you actually 
use an `interface` internally, or an encapsulated tagged union 
or whatever).


If you do need to tell it what it is, a two-level function 
gives that opportunity:



template opDispatch(string name) {
auto opDispatch(T, Args...)(Args args) {
  auto obj = cast(T) o; // or whatever you do to convert
  return __traits(getMember, obj, name)(args);
}
}

then the usage looks like

auto size = f.getSize!Bitmap(wallpaperhandle);


NOTE: opDispatch suppresses internal compile errors, it will 
just say "no such property whatever". you can explicitly 
instantiate with `f.opDispatch!"whatever` to help see better 
errors.


But it depends on what exactly you are doing.


Thanks for your reply:)

I don't need an alias at all. I was trying to figure something 
out with opDispatch first but something like __traits(getMember, 
obj, name)(args); never  occurred to me. Awesome!


The handle knows whether or not it's valid and where to find the 
object and it only makes sense in the context of the factory that 
made it.


The template opDispatch looks like what I was looking for :)

Re: How to dispatch a class function for an object accessed by handle?

[wjoe via Digitalmars-d-learn]

On Thursday, 5 March 2020 at 18:33:41 UTC, Adam D. Ruppe wrote:

On Thursday, 5 March 2020 at 14:24:33 UTC, wjoe wrote:

[...]

template opDispatch(string name) {
auto opDispatch(T, Args...)(Args args) {
   ...
}
}

[...]


NOTE: opDispatch suppresses internal compile errors, it will 
just say "no such property whatever". you can explicitly 
instantiate with `f.opDispatch!"whatever` to help see better 
errors.




Follow-up question:

Calling f.whatever!SomeResource(...); works no problem.
However I can't figure out how to call a function by explicitly 
instantiating opDispatch.


Since f.opDispatch!"load"(handle, "wallpaper.png");
doesn't compile, I refreshed my memory about the shortcut syntax 
and the eponymous syntax and the way I read it is that this is a 
template of a template.


So I tried this: f.opDispatch!"load".opDispatch!Bitmap(handle, 
"path/to/wallpaper.png");


But this doesn't compile either and errors out with:
Error: Cannot resolve type for f.opDispatch(T, 
ARGS...)(ResourceHandle handle, ARGS args)


I don't understand this error message. Which type can't be 
resolved?


Is there a way to look at output of what the compiler generates 
for f.whatever!SomeResource(...); ?

Re: How to dispatch a class function for an object accessed by handle?

[wjoe via Digitalmars-d-learn]

On Friday, 6 March 2020 at 13:55:25 UTC, Steven Schveighoffer 
wrote:

On 3/6/20 6:51 AM, wjoe wrote:

On Thursday, 5 March 2020 at 18:33:41 UTC, Adam D. Ruppe wrote:

On Thursday, 5 March 2020 at 14:24:33 UTC, wjoe wrote:

[...]

template opDispatch(string name) {
    auto opDispatch(T, Args...)(Args args) {
   ...
    }
}

[...]


NOTE: opDispatch suppresses internal compile errors, it will 
just say "no such property whatever". you can explicitly 
instantiate with `f.opDispatch!"whatever` to help see better 
errors.




Follow-up question:

Calling f.whatever!SomeResource(...); works no problem.
However I can't figure out how to call a function by 
explicitly instantiating opDispatch.


Since f.opDispatch!"load"(handle, "wallpaper.png");
doesn't compile, I refreshed my memory about the shortcut 
syntax and the eponymous syntax and the way I read it is that 
this is a template of a template.


So I tried this: f.opDispatch!"load".opDispatch!Bitmap(handle, 
"path/to/wallpaper.png");


This doesn't work, because an eponymous template does not 
provide access to the internals of the template.




But this doesn't compile either and errors out with:
Error: Cannot resolve type for f.opDispatch(T, 
ARGS...)(ResourceHandle handle, ARGS args)


I don't understand this error message. Which type can't be 
resolved?


Is there a way to look at output of what the compiler 
generates for f.whatever!SomeResource(...); ?


You can use -vcg-ast, but this isn't necessarily going to be 
compilable code.


D doesn't allow chained instantiation (i.e. (A!B)!C), so you 
need to use either a mixin or a helper:


import std.meta;

enum fname = "load";

Instantiate!(f.opDispatch!fname, 
Bitmap)("path/to/wallpaper.png")


or

mixin("f." ~ fname ~ "!(Bitmap)(...);");

I'm assuming fname is given to you as a compile-time string and 
that's why you'd need to run opDispatch manually.


-Steve


I tried Instantiate this morning after I found a reply you made 
to someone else who was trying to chain instantiate. But for the 
reason you stated it didn't work.


Funny you mention: mixin("f." ~ fname ~ "!(Bitmap)(...);");
Because that's like my initial implementation :)

As for the the command line switch. My plan wasn't to copy paste. 
Sometimes I have a hard time to comprehend results because it's 
like I've put water, flour and eggs on the table. Then I'm 
presented with a loaf of bread and I'm baffled. Then I want to 
understand what happened between putting the ingredients on the 
table and the ready baked loaf.


Anyways, thanks for your answers.

Re: How to dispatch a class function for an object accessed by handle?

[wjoe via Digitalmars-d-learn]

On Friday, 6 March 2020 at 14:14:04 UTC, Adam D. Ruppe wrote:
On Friday, 6 March 2020 at 14:05:55 UTC, Steven Schveighoffer 
wrote:
Adam's way doesn't work either, because the call doesn't use 
the alias, but just instantiates opDispatch with the new name!'


oh yikes, how did I not notice that?!

so yeah just kinda screwed. I'd probably suggest at tis point 
having the opDispatch be a trivial implementation that just 
forwards to another named method.


struct A {
  template opDispatch(string name) {
 auto opDispatch(T, Args...)(Args args) {
   return other_name!(name, T, Args)(args);
 }
  }

  auto other_name(string name, T, Args...)(Args args) {
  // real implementation
  }
}


and then to test it externally you do

a.other_name!("whatever", Bitmap)(args, here);


This isn't the worst thing to use and since it's just for testing 
it's fine.


I came up with a similar interface like a.other_name!("whatever", 
Bitmap)(args, here); after discarding .opDispatch() and I called 
the thing

 .dispatch(T, string fn, ARGS...)(...).

But didn't like the string part and that's when I introduced the 
alias fn because I figured maybe it's possible to do something 
like:

  factory.dispatch!(Bitmap.load)(handle, path);
and get the Bitmap part from that alias and hence save the 
duplicate Bitmap type in factory.dispatch!(Bitmap, 
Bitmap.load)(...);


Anyways thanks for your help.

What's opIndexAssign supposed to return ?

[wjoe via Digitalmars-d-learn]

Lets say I've got 3 overloads of opIndexAssign:

auto opIndexAssign(T t);
auto opIndexAssign(T t, size_t i); and
auto opIndexAssign(T t, size_t[2] i);

I would assume to return what I would return with opIndex but I'd 
rather not act upon assumptions.
But if yes is it supposed to be the newly assigned values or the 
pre-assignment ones ? By value or by reference ? And if it's the 
new stuff can I just return t ?


The language manual on operator overloading didn't answer that 
question and neither did an internet search which didn't find any 
useful information. Something unrelated and a heads up about 
introducing opIndexAssign from 2004.

Re: What's opIndexAssign supposed to return ?

[wjoe via Digitalmars-d-learn]

On Tuesday, 25 February 2020 at 11:49:50 UTC, Petar Kirov 
[ZombineDev] wrote:

On Tuesday, 25 February 2020 at 11:02:40 UTC, wjoe wrote:

[...]


opIndexAssign is the operator used in the following code:

arr[1] = 8;

It returns the element at index 1 (so 8 in this case) by 
reference.

This allows you to do:

(arr[1] = 8)++;
assert(arr[1] == 9);

Whether or not you want to support this behavior in your custom 
data structure is up to you. It's perfectly valid to return the 
element by value or even return void.


Returning void from any custom assignment operator is always a 
safe choice. It's possible that some algorithms (e.g. in Phobos 
or third-party libraries) may need op*Assign to return 
something, but in that unlikely case you'll get a compile-time 
error, so it will be an easy fix.


Excellent answer ! Thanks for your fast reply :)

Re: How to catch RangeError in unittest?

[wjoe via Digitalmars-d-learn]

On Tuesday, 18 February 2020 at 13:07:35 UTC, wjoe wrote:
I have a function add(index, data) which throws RangeError if 
the index is invalid.




Never mind. For whatever reason RangeError is now caught. Sorry 
for the noise.

How to catch RangeError in unittest?

[wjoe via Digitalmars-d-learn]

I have a function add(index, data) which throws RangeError if the 
index is invalid.


unittest { // is supposed to test that RangeError is thrown on a 
range violation
   assertThrown!RangeError(add(size_t.max, something)); //which 
doesn't work, the test is killed with core.exception.RangeError: 
Range violation


   // this kills the test, too: core.exception.RangeError: Range 
violation

   try {
 add(size_t.max, something);
 assert(false, "Expecting RangeError");
   } catch (RangeError) {}
}

Just for clarification, I do _not_ intend to catch RangeError 
outside of a unittest. What I want is that the test acknowledges 
the correctly thrown RangeError and gracefully reports success.



What are my options?

Re: tuple(...).each error; why does foreach work and std.algorithms.each doesn't ?

[wjoe via Digitalmars-d-learn]

On Tuesday, 11 February 2020 at 18:21:11 UTC, Adam D. Ruppe wrote:

On Tuesday, 11 February 2020 at 18:11:44 UTC, wjoe wrote:
In my mind, if something works with foreach, it should also 
work with std.algorithm.each.


They are very different, the each thing only works for ranges 
whereas foreach works with a variety of things.



How is 1) different from 2) ?


The ARGS... is a compiler list and can have multiple different 
types included. Moreover, it will auto-expand when you use it 
to call a function etc.


You can sometimes do [args] - with the [] around it to turn 
into an array. Then you can .each it and so on. But they must 
already be of compatible types to do that since an array 
elements must all be the same thing.


I would suggest just using foreach for this.


What's a compiler list... is that something like a tuple? or more 
like a macro expansion?
Or is it only valid to use in a foreach to take advantage of each 
item individually and for expansion in a function call ?

Is it possible to partially expand like:

void fn(int, uint) {}
and ARGS(string, int, uint)
and call fn(args[1..$]);

Is that possible?

as for the format function...foreach works as expected so I'll 
just keep that. Thanks for your fast reply :)

tuple(...).each error; why does foreach work and std.algorithms.each doesn't ?

[wjoe via Digitalmars-d-learn]

Consider a function to format the parameters of a function call:

pure nothrow string fmtArgs(ARGS...)(ARGS args)
{
   string result;

   // 1)
   foreach(a; args) {
  result ~= a.to!string;
   }

   // 2)
   args.each!(a => result ~= a.to!string);

   return result;
}

In my mind, if something works with foreach, it should also work 
with std.algorithm.each.
However if I try something like 2) the compiler complains with 
error: cannot deduce function from argument types !()(uint, 
int)...


Technically I'd like to transform args into a range/array of 
strings but I'm not smart enough to understand the error messages 
these functions in std.algorithms produce.


How is 1) different from 2) ?

Re: tuple(...).each error; why does foreach work and std.algorithms.each doesn't ?

[wjoe via Digitalmars-d-learn]

On Tuesday, 11 February 2020 at 19:04:17 UTC, Paul Backus wrote:

On Tuesday, 11 February 2020 at 18:55:45 UTC, wjoe wrote:
What's a compiler list... is that something like a tuple? or 
more like a macro expansion?
Or is it only valid to use in a foreach to take advantage of 
each item individually and for expansion in a function call ?

Is it possible to partially expand like:

void fn(int, uint) {}
and ARGS(string, int, uint)
and call fn(args[1..$]);

Is that possible?


This article answers all of your questions:

https://dlang.org/articles/ctarguments.html


That's more information than I had hoped for. Thank you :)

Re: tuple(...).each error; why does foreach work and std.algorithms.each doesn't ?

[wjoe via Digitalmars-d-learn]

On Tuesday, 11 February 2020 at 19:05:19 UTC, Adam D. Ruppe wrote:

On Tuesday, 11 February 2020 at 18:55:45 UTC, wjoe wrote:

What's a compiler list... is that something like a tuple?


Yea, they are frequently called tuples too. It is basically 
just a list of arguments used for a function call that the 
compiler treats somewat magically.



Is it possible to partially expand like:

void fn(int, uint) {}
and ARGS(string, int, uint)
and call fn(args[1..$]);


Yes, slicing is the exact syntax for it. You can slice and 
index as if it were an array.


Cool. thanks for your reply :)

Re: How to dispatch a class function for an object accessed by handle?

[wjoe via Digitalmars-d-learn]

On Friday, 6 March 2020 at 15:19:39 UTC, Adam D. Ruppe wrote:

On Friday, 6 March 2020 at 15:05:56 UTC, wjoe wrote:
But didn't like the string part and that's when I introduced 
the alias fn because I figured maybe it's possible to do 
something like:

  factory.dispatch!(Bitmap.load)(handle, path);
and get the Bitmap part from that alias and hence save the 
duplicate Bitmap type in factory.dispatch!(Bitmap, 
Bitmap.load)(...);


ooh you can do that. on the alias, use __traits(identifier) to 
get thef ucntion name and __traits(parent) to get the class 
name! then it reduces to what we already wrote.


Awesome! I read the docs up and down but I couldn't figure it 
out. Thank you!

Re: Is it possible to dynamically load a @safe function from a shared library ?

[wjoe via Digitalmars-d-learn]

On Friday, 13 March 2020 at 20:31:16 UTC, Steven Schveighoffer 
wrote:

On 3/13/20 4:22 PM, wjoe wrote:
I would expect that something could be written to turn a 
signature string into a mangling and also provide the correct 
type upon return. Something like:


auto f = getFunction!(@safe void 
function(int))("package.module.symbol");


and have it properly mangle the expected function name and pull 
it from the dynamic library.


-Steve


Thanks for your reply.

core.demangle: mangle; comes to mind. And in fact, because the 
exports weren't extern(C), that's how I imported the symbols; 
prior to reading H. S. Teoh's reply. That's when I realized that 
I've got a problem.


Even though I know that the function being exported are all 
compiled @safe, that doesn't mean I can count on the fact.
Since a plugin is a separate file it can be swapped out with a 
version that exports all the same (forged) symbols names but with 
a @system implementation.
Forging these symbol names is as easy as something like 
mangle!(int function(int))("a.b")); (=_D1a1bPFiZi) and 
copy/pasting that into pragma(mangle, "_D1a1bPFiZi") and voila, 
the loader can nothing but trust that this is true.


Forging is maybe too hard a word but my vocabulary lacks a better 
one.

Is it possible to dynamically load a @safe function from a shared library ?

[wjoe via Digitalmars-d-learn]

I've got a plug-in which is a shared library. Like this

module plugin;

@safe int VersionOfAPI()
{
   return 1;
}

this is builds to plugin.so

in main.d I'm loading the plugin and bind the those functions 
like so:


module app;
@safe:

alias apiverfn = int function();
apiverfn apiVersion;

void main()
{
   LoadPlugin("plugin.so");
}

void LoadPlugin(string path)
{
   void* plugin = loadLibrary(path);

   @trusted void* bindSymbol(void** pfn, const(char)* symbolName)
   {
   *pfn = dlsym(plugin, symbolName);
   }

   bindSymbol(, "VersionOfAPI");
}

The compiler now refuses to call bindSymbol:
  Error: function bindSymbol(void**, const(char)*) is not 
callable using argument types (int function() @safe*, string)  
cannot pass  of type int function() @safe* to 
parameter void** pfn


It makes sense that the compiler refuses to assign a @system 
function* to a @safe one but dlsym is a @system function which 
returns a @system fn* and I know that the function is @safe.


Is it possible to convince the compiler to look the other way 
while binding @safe functions from the plugin ?

Re: Is it possible to dynamically load a @safe function from a shared library ?

[wjoe via Digitalmars-d-learn]

On Friday, 13 March 2020 at 16:04:06 UTC, Mike Parker wrote:

On Friday, 13 March 2020 at 15:16:06 UTC, wjoe wrote:


   bindSymbol(, "VersionOfAPI");
}





Is it possible to convince the compiler to look the other way 
while binding @safe functions from the plugin ?


It probably has nothing to do with @safe, but is because of the 
void**.


bindSymbol(cast(void**), "VersionOfAPI");


Than works, thanks :)
But isn't apiVersion a function pointer ?

Re: Is it possible to dynamically load a @safe function from a shared library ?

[wjoe via Digitalmars-d-learn]

On Friday, 13 March 2020 at 18:30:51 UTC, H. S. Teoh wrote:
On Fri, Mar 13, 2020 at 06:11:01PM +, wjoe via 
Digitalmars-d-learn wrote:

On Friday, 13 March 2020 at 17:05:32 UTC, Mike Parker wrote:
> On Friday, 13 March 2020 at 16:11:53 UTC, wjoe wrote:
> > On Friday, 13 March 2020 at 16:04:06 UTC, Mike Parker 
> > wrote:

[...]

> > > bindSymbol(cast(void**), "VersionOfAPI");

[...]
This also means that LoadPlugin() can't be @safe - or at least 
the

call to bindSymbol.

[...]

Of course it cannot be @safe, because it depends on whether the 
symbol defined in the library you loaded is actually @safe.  
You cannot know that for sure (for example, maybe it exports a 
symbol that happens to coincide with the mangling of a @safe 
function, but isn't in fact @safe).  Similarly, at least on 
Posix, shared libraries only export symbol names, the actual 
type is not part of the shared library API other than what is 
encoded in the mangled symbol.  So you don't know for sure that 
you're actually casting to the correct type, for example; if 
you make a mistake, you might get UB and memory corruption.


So essentially, you're trusting that the symbol you just looked 
up is actually pointing to what you think it's pointing to.  
Therefore, it makes sense that such calls have to be @trusted.



T


I wasn't aware that pragma(mangle, ..) can practically name any 
function anything. So from what I understand, because, at least 
on Posix, since there's only a symbol name there's nothing I can 
do in my loader to verify that a function is or does what it 
claim to be/do.


This is kind of disappointing but well worth the lessons learned.

Thanks for your reply.

Re: Is it possible to dynamically load a @safe function from a shared library ?

[wjoe via Digitalmars-d-learn]

On Friday, 13 March 2020 at 17:05:32 UTC, Mike Parker wrote:

On Friday, 13 March 2020 at 16:11:53 UTC, wjoe wrote:

On Friday, 13 March 2020 at 16:04:06 UTC, Mike Parker wrote:

On Friday, 13 March 2020 at 15:16:06 UTC, wjoe wrote:


   bindSymbol(, "VersionOfAPI");
}





Is it possible to convince the compiler to look the other 
way while binding @safe functions from the plugin ?


It probably has nothing to do with @safe, but is because of 
the void**.


bindSymbol(cast(void**), "VersionOfAPI");


Than works, thanks :)
But isn't apiVersion a function pointer ?


Yes, but when you take the address of *any* kind of pointer, 
you can't assign it to void** without a cast.


Didn't know that. I'm curious as to why this is the case.
This also means that LoadPlugin() can't be @safe - or at least 
the call to bindSymbol.


Thanks for the reply.

Re: How to port C++ std::is_reference to D ?

[wjoe via Digitalmars-d-learn]

On Wednesday, 6 May 2020 at 16:01:37 UTC, Paul Backus wrote:

On Wednesday, 6 May 2020 at 09:40:47 UTC, wjoe wrote:
yes, I did read the spec. I read the language spec on traits 
as well as std.traits docs as well as searching the internet 
for a solution since day before yesterday. But I couldn't 
bring it together because


  } else static if (__traits(isRef, T)) {

compiles, but e.g.

   assert (modifier!(ref int) == "[out] ");

doesn't.
Anyways, thanks for your reply.


D doesn't have reference *types*, it only has reference 
*parameters*. Here's an example:


void fun(ref int r, int v) {
static assert(is(typeof(r) == int)); // note: not `ref int`
static assert(is(typeof(r) == typeof(v))); // `ref` makes 
no difference to type


static assert(__traits(isRef, r)); // note: not 
`__traits(isRef, typeof(r))`

static assert(!__traits(isRef, v));
}


Hello Paul, thanks for the explanation. This is quite the dilemma 
then. What this guy does in his library is he builds a static 
array at compile time and populates it with const and ref type 
names.

Re: Best way to refer to the type of a struct inside itself ?

[wjoe via Digitalmars-d-learn]

On Friday, 15 May 2020 at 13:52:38 UTC, Paul Backus wrote:

On Friday, 15 May 2020 at 13:47:43 UTC, wjoe wrote:

struct Foo(A, B, C, size_t a, size_t b)
{
  alias foo_t = Foo!(A, B, C, a, b); // is there a better way 
to get foo_t ?

}


typeof(this)


Thanks :)

Best way to refer to the type of a struct inside itself ?

[wjoe via Digitalmars-d-learn]

struct Foo(A, B, C, size_t a, size_t b)
{
  alias foo_t = Foo!(A, B, C, a, b); // is there a better way to 
get foo_t ?

}

Re: Best way to refer to the type of a struct inside itself ?

[wjoe via Digitalmars-d-learn]

On Friday, 15 May 2020 at 15:24:32 UTC, Ali Çehreli wrote:

On 5/15/20 8:04 AM, Paul Backus wrote:

[...]

Yes, that is a consistent way of explaining it. :)

As an off-topic trivia, the same feature is in C++ as well:
[...]

Ali


Awesome. Thank you Ali and Paul :)

Re: final struct ?

[wjoe via Digitalmars-d-learn]

On Tuesday, 19 May 2020 at 10:08:37 UTC, user1234 wrote:

On Tuesday, 19 May 2020 at 10:01:34 UTC, wjoe wrote:

[...]


It has no purpose. In D many attributes are allowed even if 
they have no meaning.
D-Scanner checks this kind of stuff, to some extent, but not 
the compiler.


Thank you.

final struct ?

[wjoe via Digitalmars-d-learn]

As I was reading a few source files of a library I found dozens 
of final struct declarations like this:


final struct Foo {

  const pure final nothrow bar() { ... }

}

What's this supposed to express ?

A final class is a class that can't be subclassed - structs can't 
be subclassed, so does that express something else or is the 
final redundant ?
Additionally since it's not possible to subclass a struct it's 
also not possible to override bar() - does 'final bar()' mean 
something else ?


The only relevant bits of my web search for 'dlang: final' were 
results for final class, virtual functions and final switch. Am I 
missing something ?

Easy way to format int in pragma msg ?

[wjoe via Digitalmars-d-learn]

Is there an easy way to print an int in hexadecimal, octal or 
binary representation ?


The documentation on pragma(msg, ...) and a quick web search 
didn't provide an answer.

Re: Easy way to format int in pragma msg ?

[wjoe via Digitalmars-d-learn]

On Thursday, 14 May 2020 at 10:58:34 UTC, WebFreak001 wrote:

On Thursday, 14 May 2020 at 09:49:15 UTC, wjoe wrote:
Is there an easy way to print an int in hexadecimal, octal or 
binary representation ?


The documentation on pragma(msg, ...) and a quick web search 
didn't provide an answer.


for simple hex/binary/etc printing use

  import std.conv;
  pragma(msg, i.to!string(16));

where you can replace 16 with your target base.

You can also use format as in the previous reply if you want 
more formatting control


That's great. Thanks for the fast reply. To both of you :)

Re: Error running concurrent process and storing results in array

[wjoe via Digitalmars-d-learn]

On Friday, 8 May 2020 at 13:43:40 UTC, data pulverizer wrote:
[...] I also chose kernel matrix calculations, you can't always 
call a library, sometimes you just need to write performant 
code.


Aren't kernel function calls suffering a context switch though ?

Re: How to port C++ std::is_reference to D ?

[wjoe via Digitalmars-d-learn]

On Monday, 11 May 2020 at 19:08:09 UTC, Q. Schroll wrote:

[...]

1. You can have variables ("data members") of reference type in 
structs. (They work like head-const pointers; if D had 
head-const or at least head-const pointers, those would be 
practically the same, only that references cannot be null.)

[...]



That's also something I don't really know how to correctly port 
to D.
Anyways, that was insightful. Thank you very much for your 
explanations.

Compiler bug ? -preview=intpromote and Integral promotion rules not being followed for unary + - ~ operators

[wjoe via Digitalmars-d-learn]

I have a container which provides access to data via a handle. 
For book keeping I calculate some bitmasks.
Previously, when the handle type as well as the constants were 
uint, everything compiled fine.
Today I added a template parameter to be able to specify the 
handle type and I ran into this problem.


I've read the following information on the matter:

https://forum.dlang.org/thread/yqfhytyhivltamujd...@forum.dlang.org
https://issues.dlang.org/show_bug.cgi?id=18380
https://dlang.org/changelog/2.078.0.html#fix16997

However I still don't see the problem with regards to unsigned 
types.
Why is it necessary to promote a ushort or ubyte to int for the 
purpose of shifting or the one's complement ?
At least the code at the bottom of the post seems to produce 
correct results.


One problem I see with the bug fix is that, AFAIK, the int type 
in C is not a fixed bit type like it is in D where it is defined 
to be 32 bit and therefore casting to int in D can't really 
reproduce the C behavior. What  am I missing ?


Back to my container.
* Using a 32 bit type, i.e. uint, everything compiles fine.

* Using a 16 or 8 bit type, i.e. ushort and ubyte, the compiler 
complains with -preview=intpromote for the pragmas and errors out 
on assignments of the same types.

i.e. e.g.

alias handle_t = ushort;
enum handle_t MASK = 0x8000;
handle_t handle = ~MASK; // the error message is basically: 
[value is promoted to int and] 32769 can't be assigned to ushort


* Using a 64 bit type, i.e. ulong, the whole thing blows up 
because the compiler pro-, or rather, demotes the ulong to int 
and int << 40 is obviously violating a constraint of 0..31 for 
32bit types.


void main()
{
import std.conv: to;
import std.stdio;
alias t = ushort;
enum t m = 0x8000;
pragma (msg, m.to!string(16));
pragma (msg, (~m).to!string(16));
pragma (msg, (cast(int)m).to!string(16));
pragma (msg, (~cast(int)m).to!string(16));
}

2.063  : Success with output:
-
8000
7FFF
8000
7FFF
-

2.064   to 2.077.1: Success with output:
-
8000
7FFF
8000
7FFF
-

2.078.1 to 2.084.1: Success with output:
-
8000
onlineapp.d(8): Deprecation: integral promotion not done for 
`~cast(ushort)32768u`, use '-transition=intpromote' switch or 
`~cast(int)(cast(ushort)32768u)`

7FFF
8000
7FFF
-

Apart from the fact that I end up with an int, which causes all 
kinds of havoc and the annoyance that i need to cast a ushort to 
ushort to be able to assign it to a ushort, it appears to me that 
all the results are correct.

How to port C++ std::is_reference to D ?

[wjoe via Digitalmars-d-learn]

Hello,

I'm choking on a piece of C++ I have no idea about how to 
translate to D.


  template typename std::enable_if< std::is_const::value == true, 
void>::type* = nullptr>

constexpr const char *modifier() const {
return "[in] ";
}

  template typename std::enable_if< std::is_reference::value == 
true, void>::type* = nullptr>

constexpr const char *modifier() const {
return "[out] ";
}

my attempt at it is like this:

  template modifier(T) {

  static if (is (T==const)) {

  const char* modifier = "[in] ";

  } else static if (/* T is a reference ?*/) { // [*]

  const char* modifier = "[out] ";
  }
  }

but even if I could e.g. say something like
  is(T == ref R, R),
  auto a = modifier!(ref T);
wouldn't work.

Re: How to port C++ std::is_reference to D ?

[wjoe via Digitalmars-d-learn]

On Wednesday, 6 May 2020 at 09:19:10 UTC, drug wrote:

06.05.2020 12:07, wjoe пишет:

Hello,

I'm choking on a piece of C++ I have no idea about how to 
translate to D.


   template      typename std::enable_if< std::is_const::value == 
true, void>::type* = nullptr>

     constexpr const char *modifier() const {
     return "[in] ";
     }

   template      typename std::enable_if< std::is_reference::value 
== true, void>::type* = nullptr>

     constexpr const char *modifier() const {
     return "[out] ";
     }

my attempt at it is like this:

   template modifier(T) {

   static if (is (T==const)) {

   const char* modifier = "[in] ";

   } else static if (/* T is a reference ?*/) { // [*]

   const char* modifier = "[out] ";
   }
   }

but even if I could e.g. say something like
   is(T == ref R, R),
   auto a = modifier!(ref T);
wouldn't work.





did you try https://dlang.org/spec/traits.html#isRef?


yes, I did read the spec. I read the language spec on traits as 
well as std.traits docs as well as searching the internet for a 
solution since day before yesterday. But I couldn't bring it 
together because


  } else static if (__traits(isRef, T)) {

compiles, but e.g.

   assert (modifier!(ref int) == "[out] ");

doesn't.
Anyways, thanks for your reply.

Why is there no throws, @gc, impure, mutable ?

[wjoe via Digitalmars-d-learn]

It's easy to declare the entire module @safe and functions which 
can't be can be declared @system.
However there is const, immutable, pure, @nogc and nothrow but no 
mutable, impure, @gc and throws.


Why is that ?

Re: Why is there no throws, @gc, impure, mutable ?

[wjoe via Digitalmars-d-learn]

On Monday, 7 September 2020 at 11:44:40 UTC, Paul Backus wrote:

On Monday, 7 September 2020 at 11:25:15 UTC, wjoe wrote:
It's easy to declare the entire module @safe and functions 
which can't be can be declared @system.
However there is const, immutable, pure, @nogc and nothrow but 
no mutable, impure, @gc and throws.


Why is that ?


Mostly because nobody's bothered to add them (yet). There's an 
accepted proposal to add a "throw" attribute as the opposite of 
nothrow [1], but it looks like it still hasn't been implemented 
in the compiler.


For const and immutable, you can use std.traits.Unconst [2] to 
remove them in most cases.


[1] 
https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1029.md
[2] 
http://dpldocs.info/experimental-docs/std.traits.Unconst.html


Very interesting. Thanks.

Re: How can I test at compile time whether T is an instance of an interface ?

[wjoe via Digitalmars-d-learn]

On Wednesday, 23 September 2020 at 18:50:28 UTC, H. S. Teoh wrote:

Try this:

interface I {}
class C : I {}
class D {}
struct S {}

pragma(msg, is(C : I)); // true
pragma(msg, is(D : I)); // false
pragma(msg, is(S : I)); // false

So probably what you want is something like this:

void register(C, ARGS...)(ARGS args)
if (behavesLikeFoo!C || is(C : IFoo))
...


T


Yes, that's it. Thanks :)

Re: How can I test at compile time whether T is an instance of an interface ?

[wjoe via Digitalmars-d-learn]

On Wednesday, 23 September 2020 at 18:49:28 UTC, data pulverizer 
wrote:

On Wednesday, 23 September 2020 at 18:37:45 UTC, wjoe wrote:

[...]


A class at compile time is it's own static type, OOP 
polymorphism is a runtime feature not compile time. You have to 
write your own traits for specific objects to get them to 
relate to each other using static overloading.


It doesn't occur to me that the compiler doesn't know at compile 
time that


interface IFoo{}
class Foo: IFoo {}

class Foo implements interface IFoo.

How can I test at compile time whether T is an instance of an interface ?

[wjoe via Digitalmars-d-learn]

I have some similar functions:

void register(C: IFoo)()
{
  _insert!C();
}

void register(C)() if (behavesLikeFoo!C)
{
  _insert!C();
}

There are more overloads with parameters so I want to merge them

void register(C, ARGS...)(ARGS args) if (behavesLikeFoo!C || 
isInstanceOf!(C, IFoo))

{
  _insert!C(args);
}

I found a lot of information on how to do this at runtime but not 
at compile time.
std.traits: isInstanceOf doesn't work. Neither did anything I 
tried with typeid etc.


The behavesLikeFoo constraint works as expected but it accepts 
any class no matter whether or not it implements the interface.

Re: How can I test at compile time whether T is an instance of an interface ?

[wjoe via Digitalmars-d-learn]

On Wednesday, 23 September 2020 at 19:08:47 UTC, data pulverizer 
wrote:

On Wednesday, 23 September 2020 at 18:56:33 UTC, wjoe wrote:

[...]


Didn't think that the compiler didn't know but wasn't aware 
that you could use that information to statically dispatch. My 
mistake, I'll shut up now!


Appologies if you took offense. Your replies are very much 
appreciated.

Re: Building LDC runtime for a microcontroller

[wjoe 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


congratulations! All the best for your family :)

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

[wjoe via Digitalmars-d-learn]

On Friday, 18 September 2020 at 22:31:09 UTC, mw wrote:

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.


Thanks for the link, I will have a look.

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

[wjoe via Digitalmars-d-learn]

On Friday, 18 September 2020 at 22:21:52 UTC, Adam D. Ruppe wrote:

On Friday, 18 September 2020 at 22:02:07 UTC, aberba wrote:

[...]


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.




This looks promising. How could I forget about arsd. You have 
something for anything :)


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.


But if I wanted that sort of "convenience" I would still be using 
PHP ;)


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 ?

[wjoe via Digitalmars-d-learn]

On Friday, 18 September 2020 at 22:02:07 UTC, aberba wrote:

[...]


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.




Yes it would be convenient and thanks for the links but since I'm 
not familiar with Node.js at all parsing the input myself will be 
better than getting into Node.



Vibe.d still lacks many things I personally need... there's 
simply not enough ecosystem third-party libraries.


My first impression of vibe.d is that the author(s) made a 
presumptions about the one way things should be done(tm) and if 
that's not your use case too bad for you.
That's where most of my displeasure of using vibe.d comes from 
and that those aren't described in the documentation - not so 
much because of the things that aren't implemented (yet).


Handling file uploads is one example, another is command line 
arguments.
The presumption here is there is vibe and there can only be vibe. 
It takes them from Runtime.args. Duh?
This didn't make sense to me until I saw example where the 
initialization of vibe was done in a module constructor.
Looks cool on a cursory look but is incredibly impractical if you 
don't want to do it that way. And that's the gist - vibe.d is 
incredibly impractical if your use case doesn't exactly match the 
author(s) assumptions of the one way to do things(tm).
And there are issues with that, too. E.g. in the example the 
server will be started before command line args are completely 
processed. That means if there are wrong or missing or extra args 
the application aborts and leaks OS resources.
The way I would have implemented it is to take args from 
Runtime.args by default but allow passing an args[] to a vibe 
args-handler. I could then parse whatever args I'm interested in 
in my favorite way and pass the rest to vibe.


But you can handle those with vibe getOption or some such - why 
don't you want to do comandline args processing with vibe you ask 
?

Because 1. there's std.getopt which is awesome, and
2. If I don't depend on vibe to parse them and I have a build 
configuration with version="NO_SERVER" I don't even need to link 
against vibe and its dependencies.


By using vibe I feel like I need to bend myself like a snake and 
jump through the hoops of vibe's one way to do it. You save a lot 
of time here and there and then you lose half a day because of 
some stupid road block like the above.

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

[wjoe via Digitalmars-d-learn]

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[].


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 them back into memory for further 
processing sounds, above all else, incredibly inefficient.

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

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


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

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 ;)


Still, thanks a lot for all the replies everybody. Very much 
appreciated :)

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

[wjoe via Digitalmars-d-learn]

I found this [1] but unfortunately the post this refers to is a 
dead link and the content, unfortunately, didn't tell me anything 
that I didn't already find in the docs.


What I can get from the form is the form fields with content, the 
field name for the file upload and the file name. But the file 
name is useless to me because I need the file content.


Where is it stored ?

[1] https://aberba.com/2017/multiple-file-upload-in-vibe-d/

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

[wjoe via Digitalmars-d-learn]

On Thursday, 17 September 2020 at 16:32:55 UTC, WebFreak001 wrote:

On Thursday, 17 September 2020 at 16:00:33 UTC, wjoe wrote:
I found this [1] but unfortunately the post this refers to is 
a dead link and the content, unfortunately, didn't tell me 
anything that I didn't already find in the docs.


What I can get from the form is the form fields with content, 
the field name for the file upload and the file name. But the 
file name is useless to me because I need the file content.


Where is it stored ?

[1] https://aberba.com/2017/multiple-file-upload-in-vibe-d/


hi, you can access HTTPServerRequest.files which contains the 
uploaded file.


Example in real code: 
https://github.com/WebFreak001/ImageUploader/blob/master/source/app.d#L141-L159


Documentation: https://vibed.org/api/vibe.inet.webform/FilePart

Note: the file is only downloaded from the client / stored on 
disk once you access the files or the form property, though 
this isn't documented.


Every post or example I found copies the file, like your code 
does, too. Why is that ? The content of the file upload is 
embedded in the form data. There's no need for temporary files or 
copying at all.


On top of that, if I upload a file to a server which is on a 
different PC on a different file system, how am I supposed to 
read the file from disk on a remote file system ?


This makes no sense.

What I want is something like this:


~$ cat /var/log/temperatures.log

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



~$ curl -F "temperature_log=@/var/log/temperatures.log" 
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: 245
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

--c73c71472ff9e7d5--



void upload(HttpRequest.. req, blah)
{
   auto file = "temperature_log" in req.files;
   if (file) {
  string temp_data_raw = file.data;
  assert ("temp_1=22;temp_2=28\ntemp_1=21;temp_2=25" == 
temp_data_raw);

   }
}

Re: What's the best way to find out which exceptions may be thrown ?

[wjoe via Digitalmars-d-learn]

On Wednesday, 27 May 2020 at 11:40:00 UTC, Mike Parker wrote:

On Wednesday, 27 May 2020 at 10:30:36 UTC, wjoe wrote:

On Wednesday, 27 May 2020 at 10:01:33 UTC, Mike Parker wrote:
Could you please elaborate why checked exceptions are more 
annoying?




For me, it's because they require all functions that touch them 
to either try/catch or include an exception specification in 
its declaration. In my Java days, I ended up just doing what so 
many others do and adding `throws Exception` or 
`catch(Exception)` to avoid having to handle multiple exception 
types. Most of the time, I didn't care what specific sort of 
exception was thrown.


Johannes, Dennis, Mike that was very insightful. I didn't 
consider those reasons.

Thank you very much for the elaboration :)

Re: What's the best way to find out which exceptions may be thrown ?

[wjoe via Digitalmars-d-learn]

On Wednesday, 27 May 2020 at 10:01:33 UTC, Mike Parker wrote:

On Wednesday, 27 May 2020 at 09:56:07 UTC, wjoe wrote:


The problem with catch(Exception) is that it's run time 
whereas I'd like to know compile time which exception may 
possibly be thrown.


So I take it the only way to find out what may be thrown is to 
read the source code of the called function(s) and the rat 
tail that follows - and to rely on documentation to be 
accurate and complete if the source code isn't available.


That's sort of annoying.


Checked exceptions are much more annoying.


Could you please elaborate why checked exceptions are more 
annoying?


The only exposure to checked exceptions I had was with Java and I 
always liked and appreciated them.
It's super annoying the fiddle around with catch(Exception) all 
over the place and log unhandled Exceptions and never be sure 
that all exceptions are properly taken care of.

What's the best way to find out which exceptions may be thrown ?

[wjoe via Digitalmars-d-learn]

nothrow void foo()
{
   bar(4);
}

void bar(int a)
{
  if (a ==1)
throw new Exception1();
  else if (a == 2)
throw new Exception2();

   baz();
}

void baz()
{
  if (whatever)
throw new Exception3();
}


The compiler will complain that bar(int) isn't nothrow.

What's the best way to find out which Exceptions aren't handled 
inside of foo() for foo to be able to be nothrow without using a 
'catch (Exception){}' catch-all?

Re: What's the best way to find out which exceptions may be thrown ?

[wjoe via Digitalmars-d-learn]

On Wednesday, 27 May 2020 at 09:44:56 UTC, Mike Parker wrote:

On Wednesday, 27 May 2020 at 09:42:58 UTC, Mike Parker wrote:

On Wednesday, 27 May 2020 at 09:40:08 UTC, wjoe wrote:



The compiler will complain that bar(int) isn't nothrow.

What's the best way to find out which Exceptions aren't 
handled inside of foo() for foo to be able to be nothrow 
without using a 'catch (Exception){}' catch-all?


`catch(Exception)`.


I should add that if you're only catching specific exceptions 
in a `nothrow` function, then it isn't `nothrow`. You have to 
catch Exception because D does not have exception 
specifications. I would expect the compiler to complain if you 
try to do otherwise.


Thanks for the fast reply, Mike.

The problem with catch(Exception) is that it's run time whereas 
I'd like to know compile time which exception may possibly be 
thrown.


So I take it the only way to find out what may be thrown is to 
read the source code of the called function(s) and the rat tail 
that follows - and to rely on documentation to be accurate and 
complete if the source code isn't available.


That's sort of annoying.

Re: What's the best way to find out which exceptions may be thrown ?

[wjoe via Digitalmars-d-learn]

On Wednesday, 27 May 2020 at 09:44:56 UTC, Mike Parker wrote:

On Wednesday, 27 May 2020 at 09:42:58 UTC, Mike Parker wrote:

I should add that if you're only catching specific exceptions 
in a `nothrow` function, then it isn't `nothrow`. You have to 
catch Exception because D does not have exception 
specifications. I would expect the compiler to complain if you 
try to do otherwise.


I should add that the reason for my question wasn't to make a 
function nothrow by means of not letting Exceptions escape, for 
which std.exception.assumeWontThrow could be used, but to be able 
to find out which exceptions can/should be handled at a 
particular call site.

Re: final struct ?

[wjoe via Digitalmars-d-learn]

On Wednesday, 20 May 2020 at 04:40:33 UTC, user1234 wrote:

On Tuesday, 19 May 2020 at 10:29:51 UTC, wjoe wrote:

On Tuesday, 19 May 2020 at 10:08:37 UTC, user1234 wrote:

[...]


Thank you.


A little sample to show you more cases of attributes that have 
no effect:


---
struct Foo
{
nothrow @nogc int field; // why not ?

void func()
{
void nested() const
{
field++;  // mutation is allowed because const 
is a noop

extern int j; // extern decl in a nested func...
}

nothrow i = 8;// just like auto
pure f = 9;   // just like auto
@safe s = 10; // just like auto
@system t = s;// just like auto
}
}

void main() { }
---


much appreciated :)

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

[wjoe via Digitalmars-d-learn]

On Tuesday, 15 September 2020 at 01:49:13 UTC, James Blachly 
wrote:
I wish to write a function including ∂x and ∂y (these are 
trivial to type with appropriate keyboard shortcuts - alt+d on 
Mac), but without a unicode byte order mark at the beginning of 
the file, the lexer rejects the tokens.


It is not apparently easy to insert such marks (AFAICT no 
common tool does this specifically), while other languages work 
fine (i.e., accept unicode in their source) without it.


Is there a downside to at least presuming UTF-8?


As you probably already know BOM means byte order mark so it is 
only relevant for multi byte encodings (UTF-16, UTF-32). A BOM 
for UTF-8 isn't required an in fact it's discouraged.


Your editor should automatically insert a BOM if appropriate when 
you save your file. Probably you need to select the appropriate 
encoding for your file. Typically this is available in the 'Save 
as..' dialog, or the settings.

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

[wjoe via Digitalmars-d-learn]

On Saturday, 19 September 2020 at 19:27:40 UTC, Steven 
Schveighoffer wrote:

[...]
This used to be the expected way to set up vibe (using module 
constructors). And vibe would provide its own main function.


I *think* the idea was to allow registration of different 
handlers in their respective modules.


A reasonable decision if you assume that's the only thing you 
want to do.
Vibe and dub share this philosophy. The author(s) assumed those 
are the only use cases and nothing else flies.
Like for e.g. you can build a D application that uses a C library 
with D glue code and compile the files together in 1 go with GCC, 
maybe with LDC, too, but I haven't tried.

something like: gcc main.d dglue.d clib.c clib.h
But this doesn't work with dub, or at least it didn't work the 
last time I tried a year or so ago.

I'm not a fan of the "The one true way" philosophy.


[...]
I used Kai's book, and yeah, you have to do things the vibe 
way. But most web frameworks are that way I think.


I recommend getting the book if you plan on doing a lot with 
vibe.d


I forgot that I got it some time ago, never really got around to 
take a look however. Thanks for the reminder :)


Where vibe really shines are the diet templates and the web 
interface stuff. To not have to handle anything from forms, or 
query parameters, and just write normal D functions is really 
great. You can even do a lot of authentication and stuff using 
UDAs. It helps you write consistent web applications.


And I LOVE diet templates. So much less verbose than actual 
HTML. I have a hard time writing actual HTML now.


Those are the only reason why I didn't throw it out, yet. Maybe 
it will make up for some of the initial frustration :)


When you want to do stuff manually, I think it's not as well 
supported.


-Steve

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

[wjoe via Digitalmars-d-learn]

On Saturday, 19 September 2020 at 20:17:06 UTC, aberba wrote:
I personally (and many others in the industry... judging by 
popularity of express (node.js) and the plentiful third-party 
libraries,..do prefer the router.get() design. Also having 
everything abstracted in a convenient and consistent way...is 
very desirable. vibe.d's web interface API is something I've 
always praised and thanks to how powerful D is compare to say 
JavaScript. Diet templates is also an example.


I'm not a professional web developer and I don't intend to become 
one.
My intention is to live a long and mentally healthy life and web 
development is a serious threat to that ;)


However that power is not tapped in enough (yet) to favour 
using D conveniently over node (js). And web developers are 
interested in getting things done (at least my kind of web 
devs) rather than getting it our way...or squeezing every bit 
of efficiency out of it. Part of why v8 is fast by default (for 
us).


But joking aside, I'm going to use D over Javascript any day of 
the week no questions asked.
And despite my constant bickering, vibe is a huge accomplishment 
and improvement over what I used in the past. So kudos.

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

[wjoe via Digitalmars-d-learn]

On Sunday, 20 September 2020 at 00:36:30 UTC, Adam D. Ruppe wrote:

[...]
That's it - all the html and javascript are all auto-generated.



Amazing :)
Would even be more awesome if it provided a function which could 
be called from a custom main on top of the FancyMain.
I find e.g. custom parsing of command line arguments incredibly 
useful.

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 ?

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.

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.

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: 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: 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: 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: vibe.d: How to get the conent of a file upload ?

[wjoe via Digitalmars-d-learn]

On Sunday, 20 September 2020 at 00:36:30 UTC, Adam D. Ruppe wrote:

[...]


I browsed in your arsd docs a bit and I'll have a closer look at 
the CGI module a bit later.
Your http2 module piqued my interest as it could come in handy 
some time later :)


Looks like your modules cover everything I need and requiring 
only 2 or 3 modules that cover everything I would use from vibe 
beats fighting with dub and vibe's complexity - and I can use a 
simple makefile :) That alone will save a ton of time.

Re: Good way to send/receive UDP packets?

[wjoe via Digitalmars-d-learn]

On Tuesday, 21 July 2020 at 18:35:34 UTC, notna wrote:
well, I guess all your remarks are true... and irrelevant at 
the same time.


please go back and read his first post starts with "I have 
a project where I need to take and send UDP packets over the 
Internet"...


... and continues with:

On Saturday, 18 July 2020 at 16:00:09 UTC, Dukc wrote:
[...] And only communication with a single address, no need to 
communicate with multiple clients concurrently.


Let me elaborate on why what I wrote is both, on topic and 
relevant at the same time:


It's a fundamental characteristic of UDP that you can't 
communicate with a single client only but you always are 
communicating with everyone who listens concurrently.


The combination of the Internet and theoretically only 65535 
available ports means that (mis)communication with other clients 
is likely to happen.
OP's client may receive datagrams that are broadcast on that port 
by other programs (port forwarding).
Likewise, other programs, which have a socket bound to the same 
port, may receive OP's data.


Examples:
- You behaving correctly yourself doesn't make others behave 
correctly now or retroactively.


- Choosing a port which isn't in use right now isn't good enough 
because a few minutes later there may be another program using 
it, too, and for the same reason.


- Checking a magic byte at offset 0 followed by the size isn't 
good enough.
Let's say I decide my magic is a word because I want to be able 
to determine byte order - I choose 0x015a.
When I broadcast a packet, e.g. [[0x015a], [0x0, 0x5a, 0xff]], 
but because I sent this from a little endian machine, the 
datagram will be delivered like so [0x5a, 0x01, 0x0, 0x5a, 0xff].

When OP's client receives this message it goes like so:
Read 2 bytes: [0x5a, 0x1]
 0x5a, oh that's me, 0x01 aha length of 1 byte - except it's not 
even a valid packet in the context of their program...


Using UDP in a good way is far more complicated than it first 
appears to be.