Type inference for constructors
I’d like to know if constructors of classes and structs can have
type inference. So far, I am using a separate function for this
purpose, for example:
```
import std.stdio: writeln;
struct Pair(T, U)
{
T first;
U second;
this(T first, U second)
{
this.first = first;
this.second = second;
}
}
Pair!(T, U) pair(T, U)(T first, U second)
{
return Pair!(T, U)(first, second);
}
void main()
{
auto mp = pair("Michael", 32);//standard function inference
works
//auto m0 = Pair("Michael", 32); //I’d like to be able to do
this
writeln("pair: ", mp);
}
```
On a slightly different note, I was doing some reading in
std.typecons
(https://github.com/dlang/phobos/blob/3754e92341a393331bd6b0bc9e70335d34e42016/std/typecons.d#L6838) on Github and wondered what `this` in the code below does:
```
auto ref opIndex(this X, D...)(auto ref D i) {
return a[i]; }
```
Re: Proper way to exit with specific exit code?
On Thu, Sep 17, 2020 at 09:53:07PM -0400, James Blachly via Digitalmars-d-learn wrote: [...] > I never considered this -- so when I call core.stdc.stdlib : exit, > none of my destructors get called? Yes. > Presumably also not scope(exit) blocks? Yes. > If this is the case, could we simply add a publically-accessible > shutdown hook in the runtime? That's the obvious solution, except that actually implementing it is not so simple. When you have multiple threads listening for each other and/or doing work, there is no 100% guaranteed way of cleanly shutting all of them down at the same time. You can't just clean up the calling thread and leave the others running, because the other threads might hold references to your data, etc.. But there's no universal protocol for shutting down the other threads too -- they could be in a busy loop with some long-running computation, or they may not be checking for thread messages, or they could be in a server loop that is designed to keep running, etc.. It's one of those annoying things that reduce to the halting problem in the general case. Unless we adopt some kind of exit protocol that will apply to *all* threads in *all* D programs, I don't see any way to implement something that will work in the general case. T -- If blunt statements had a point, they wouldn't be blunt...
Re: enum and const or immutable ‘variable’ whose value is known at compile time
On Thursday, 17 September 2020 at 22:25:47 UTC, claptrap wrote: If enum means manifiest constant, or compile time constant, then it makes more sense, as you allude to in a later post. But 'enum' is a terrible name for that and I dont think my brain will ever stop finding it incongruous. And in my mind, what is a single-member enum if not a compile-time constant? This is why naming is hard.
Re: Proper way to exit with specific exit code?
On 9/17/20 12:46 PM, IGotD- wrote: The only way is to return from main. The thing is that druntime runs initialization before main and then returning from main it runs all the tear down code including cleaning up the GC. This means there is no equivalent of the exit function in the C library. Calling exit from D means that there will be no cleanup in D environment. ... I never considered this -- so when I call core.stdc.stdlib : exit, none of my destructors get called? Presumably also not scope(exit) blocks? If this is the case, could we simply add a publically-accessible shutdown hook in the runtime?
Re: enum and const or immutable ‘variable’ whose value is known at compile time
On Thursday, 17 September 2020 at 10:53:48 UTC, Mike Parker wrote: [snip] I can attest that in the 17 years I've been hanging around here, the fact that enum is used to indicate a manifest constant has not been a serious source of WTF posts. So I think "pretty much everyone coming to D" have decided it's either perfectly fine or perfectly tolerable. It's the sort of thing that may not be obvious, but once you figure you absorb it and get down to coding. I know some people would prefer it were something else and some don't care. I'm squarely in the camp that thinks it makes perfect sense and it would be silly to create a new keyword for it. A talk at dconf 2019 provided an alternative approach to using enum for manifest constants: http://dconf.org/2019/talks/marques.html
Re: vibe.d: How to get the conent of a file upload ?
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 :)
Re: another question on hidden mixin names
On Thursday, 17 September 2020 at 22:07:54 UTC, Simen Kjærås
wrote:
Usually, that would be:
struct V {
int x;
mixin assign!"+" a;
mixin assign!"-" b;
alias opOpAssign = a.opOpAssign;
alias opOpAssign = b.opOpAssign;
}
However, I can't seem to get that working. It seems to be an
instance of this issue:
https://issues.dlang.org/show_bug.cgi?id=18118
Yes, I tried that. It didn't work so I assumed that it must have
been wrong. Is this a bug in the compiler or an issue in the
language specification?
btw, I'm somewhat surprised by your use of a template this
parameter
(https://dlang.org/spec/template.html#template_this_parameter).
Generally this will work, but you're probably better off with
ref auto opOpAssign(string op)(typeof(this) rhs) if (op ==
op_)
I learned it from here: http://ddili.org/ders/d.en/mixin.html,
could you elaborate on why this is not advisable?
Re: vibe.d: How to get the conent of a file upload ?
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
Re: enum and const or immutable ‘variable’ whose value is known at compile time
On Thursday, 17 September 2020 at 10:56:28 UTC, Mike Parker wrote:
On Thursday, 17 September 2020 at 09:44:20 UTC, claptrap wrote:
Seriously how it's implemented is irrelevant.
And to be clear, my point wasn't about how it's implemented. My
point was that:
enum { foo = 10; }
and
enum foo = 10;
Are effectively the same thing, whether it's implemented that
way or not. So why on earth would a new keyword be necessary?
Because they are not the same thing, one is a set of things, one
is a single thing. That you say they are "effectively the same"
is what Im getting at, just because they can be implemented the
same, or one feature can be repurposed to serve the other need,
doesnt mean they should. It's like...
int x;
int[1] x;
They are effectively the same thing, a single int on the stack if
declared locally, but they are conceptually different. And to me
programming is not just about getting the job done but about
being able to express the concept / design precisely.
For example, this to me is utter nonsense...
enum auto isTwoWayCompatible(alias fn, T1, T2);
It makes about as much sense as using "enum" in place of "struct".
If enum means manifiest constant, or compile time constant, then
it makes more sense, as you allude to in a later post. But 'enum'
is a terrible name for that and I dont think my brain will ever
stop finding it incongruous.
Re: enum and const or immutable ‘variable’ whose value is known at compile time
On Thu, Sep 17, 2020 at 06:06:56PM -0400, Steven Schveighoffer via Digitalmars-d-learn wrote: > On 9/17/20 9:13 AM, Simen Kjærås wrote: > > > To be clear: I don't mind 'enum' being used this way, but if I were > > to do things over again, I would have used 'alias'. > > fun fact: for a (very) brief time, D had a `manifest` keyword that did > exactly what enum does in this instance (not even sure it made it into > a release). > > enum is a head scratcher of a name, for sure. But it works out just > fine once you get used to it. I think of it as "compile time". To be > honest, for what it does, enum is a very poor name. But because it's > consistent, it works. [...] In my mind, I just substitute 'enum' with 'manifest constant' and everything makes sense. ;-) T -- What are you when you run out of Monet? Baroque.
Re: vibe.d: How to get the conent of a file upload ?
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. 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 I think you can agree that it's not feasible to store arbitrary sized file contents in memory. But it certainly can provide a mechanism to handle it as it's read. -Steve 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. I've done this with my REST interface, though that's not form data. Can you share your code for this?
Re: enum and const or immutable ‘variable’ whose value is known at compile time
On 9/17/20 9:13 AM, Simen Kjærås wrote: To be clear: I don't mind 'enum' being used this way, but if I were to do things over again, I would have used 'alias'. fun fact: for a (very) brief time, D had a `manifest` keyword that did exactly what enum does in this instance (not even sure it made it into a release). enum is a head scratcher of a name, for sure. But it works out just fine once you get used to it. I think of it as "compile time". To be honest, for what it does, enum is a very poor name. But because it's consistent, it works. -Steve
Re: another question on hidden mixin names
On Thursday, 17 September 2020 at 21:05:59 UTC, 60rntogo wrote:
struct V
{
int x;
mixin assign!"+";
// mixin assign!"-";
}
However, if I uncomment the second mixin, there is an error "v
is not a scalar, it is a V". I guess I somehow need to merge
these overloads, but I don't know how.
Usually, that would be:
struct V {
int x;
mixin assign!"+" a;
mixin assign!"-" b;
alias opOpAssign = a.opOpAssign;
alias opOpAssign = b.opOpAssign;
}
However, I can't seem to get that working. It seems to be an
instance of this issue:
https://issues.dlang.org/show_bug.cgi?id=18118
Note that explicitly calling the methods does work:
v.opOpAssign!"-"(v);
v.opOpAssign!"+"(v);
I don't know any good workarounds for this, you'll probably have
to write a separate opOpAssign method for V that performs the
forwarding to the mixed-in methods. This is, to put it very
nicely, not an optimal solution.
btw, I'm somewhat surprised by your use of a template this
parameter
(https://dlang.org/spec/template.html#template_this_parameter).
Generally this will work, but you're probably better off with
ref auto opOpAssign(string op)(typeof(this) rhs) if (op ==
op_)
--
Simen
Re: vibe.d: How to get the conent of a file upload ?
On 9/17/20 1:08 PM, wjoe wrote:
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);
}
}
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'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.
I think you can agree that it's not feasible to store arbitrary sized
file contents in memory. But it certainly can provide a mechanism to
handle it as it's read.
-Steve
another question on hidden mixin names
I suspect that this is similar to the issue I asked about here:
https://forum.dlang.org/post/vukxaqprjbyrdpiou...@forum.dlang.org, but I can't figure it out.
This compiles:
---
private mixin template assign(string op_)
{
ref auto opOpAssign(string op, this RHS)(RHS rhs) if (op == op_)
{
mixin("x " ~ op ~ "= rhs.x;");
return this;
}
}
struct V
{
int x;
mixin assign!"+";
// mixin assign!"-";
}
unittest
{
auto v = V(2);
v += v;
assert(v.x == 4);
}
---
However, if I uncomment the second mixin, there is an error "v is
not a scalar, it is a V". I guess I somehow need to merge these
overloads, but I don't know how.
Re: Building LDC runtime for a microcontroller
On Thu, Sep 17, 2020 at 08:40:06PM +, wjoe via Digitalmars-d-learn wrote: > 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 [...] "A day or two"??! More likely a month for starters. :-D :-D :-D If even that! (Speaking from experience here. ;-)) Congratulations! T -- Живёшь только однажды.
Re: Building LDC runtime for a microcontroller
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 ?
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. I don't believe the temp file behavior is customizable as it is hardcoded here to write to a temporary file (which is called on form parsing): https://github.com/vibe-d/vibe.d/blob/ebebfa827f568cc9bced4bec2b66edc043a8adf7/inet/vibe/inet/webform.d#L311 However if you really wanted to (but I'd advise against it) you could parse the form data from the HTTPServerRequest.bodyReader yourself Yeah I think what he wants is a way to write the file into an in-memory buffer. This is especially necessary it some environments where you can write to disk at all. How that's done, even in node.js is to use a middleware for parsing library to parse the headers in such way. I often use multer (which is also based on busybody) to do that in nodejs. Unfortunately I haven't used D to that extent to need such a thing... I in never hit that problem. I wonder if using a psuedo file handler will work for the in-memory buffer thing.
Re: Building LDC runtime for a microcontroller
fyi my baby was just born i'll come back to this but it might be a day or two
Re: Building LDC runtime for a microcontroller
On Thursday, 17 September 2020 at 09:53:57 UTC, Remi wrote:
[snip]
My problem here is mostly understanding the __initZ symbol and
where it comes from. I mostly want classes and the bare minimum
of std like you did for Tetris in WebAssembly for example. My
project is OpenGL/SDL2 so there's a lot of glue code but just
ruinning a simple example gives me problems I want to
understand first.
Well... I just found out that it wasn't an issue with the code
but rather the order of files as given to the compiler:
(ldc-1.23.0)speps:~/dlang/wasm/webassembly$ ldc2 -i=. -i=std
-Iarsd-webassembly/ -L-allow-undefined -oftetris.wasm
-mtriple=wasm32-unknown-unknown-wasm arsd-webassembly/object.d
tetris.d
arsd-webassembly/object.d(112): Error: Global variable type does
not match previous declaration with same mangled name:
_D11TypeInfo_Ai6__initZ
arsd-webassembly/object.d(112):Previous IR type:
%object.TypeInfo_Array = type { [1 x i8*]*, i8*,
%object.TypeInfo* }, mutable, non-thread-local
arsd-webassembly/object.d(112):New IR type:
%object.TypeInfo_Ai = type { [1 x i8*]*, i8*, %object.TypeInfo*
}, const, non-thread-local
(ldc-1.23.0)speps:~/dlang/wasm/webassembly$ ldc2 -i=. -i=std
-Iarsd-webassembly/ -L-allow-undefined -oftetris.wasm
-mtriple=wasm32-unknown-unknown-wasm tetris.d
arsd-webassembly/object.d
(ldc-1.23.0)speps:~/dlang/wasm/webassembly$
If object.d is passed after tetris.d, everything works as
expected. Otherwise you get issues with __initZ. It also means
that I might have no control over what dub does with the order of
files and I can't use dub to build my WASM project.
Re: vibe.d and video files?
On Thursday, 17 September 2020 at 18:29:12 UTC, bauss wrote: Does vibe.d not work properly with ex. mp4 files? I have a consistent issues that it will only play part of video files in the browser. As if it won't "stream" the rest of the video. Is that a problem with vibe.d or is it some configuration that needs to be enabled? videos and streaming have long been implemented in 2016 (see https://github.com/vibe-d/vibe.d/pull/1634) since 0.8.0, what exactly is the issue (console, network logs) and do you have a reproduction case?
vibe.d and video files?
Does vibe.d not work properly with ex. mp4 files? I have a consistent issues that it will only play part of video files in the browser. As if it won't "stream" the rest of the video. Is that a problem with vibe.d or is it some configuration that needs to be enabled?
Re: vibe.d: How to get the conent of a file upload ?
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: Proper way to exit with specific exit code?
On Thursday, 17 September 2020 at 14:58:48 UTC, drathier wrote: What's the proper way to exit with a specific exit code? I found a bunch of old threads discussing this, making sure destructors run and the runtime terminates properly, all of which seemingly concluding that it's sad that there isn't a way to do this easily, but hopefully things have changed in the last 5-10 years and I'm just missing the obvious solution. The only way is to return from main. The thing is that druntime runs initialization before main and then returning from main it runs all the tear down code including cleaning up the GC. This means there is no equivalent of the exit function in the C library. Calling exit from D means that there will be no cleanup in D environment. This is a bit limiting for my needs for example. I would like that exiting from main will not tear down the D runtime because my system is a message driven system and main just sets up the program and then returns but the programs continues to react on messages. Many libraries like Qt circumvents this just by parking the main thread as a event handler but this doesn't fit my system and will waste one thread resource. Finally to exit the program I have equivalent to the C library exit function. Creating a similar exit function in D would be trivial really.
Re: vibe.d: How to get the conent of a file upload ?
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. I don't believe the temp file behavior is customizable as it is hardcoded here to write to a temporary file (which is called on form parsing): https://github.com/vibe-d/vibe.d/blob/ebebfa827f568cc9bced4bec2b66edc043a8adf7/inet/vibe/inet/webform.d#L311 However if you really wanted to (but I'd advise against it) you could parse the form data from the HTTPServerRequest.bodyReader yourself
vibe.d: How to get the conent of a file upload ?
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: Proper way to exit with specific exit code?
On Thu, Sep 17, 2020 at 02:58:48PM +, drathier via Digitalmars-d-learn
wrote:
> What's the proper way to exit with a specific exit code?
>
> I found a bunch of old threads discussing this, making sure
> destructors run and the runtime terminates properly, all of which
> seemingly concluding that it's sad that there isn't a way to do this
> easily, but hopefully things have changed in the last 5-10 years and
> I'm just missing the obvious solution.
AFAIK, there still isn't an "official" way to do this besides return
the exit code from main(). My go-to solution is to declare an
ExitException that's explicitly caught by main():
class ExitException : Exception {
int returnCode;
this() { super("exit"); }
}
void exit(int rc=0) { throw new ExitException(rc); }
int main(string[] args) {
try {
... // your code here
exit(123);
...
} catch (ExitException e) {
return e.returnCode;
}
return 0;
}
Caveat: this may or may not do the Right Thing(tm) in a multithreaded
application.
T
--
Talk is cheap. Whining is actually free. -- Lars Wirzenius
Proper way to exit with specific exit code?
What's the proper way to exit with a specific exit code? I found a bunch of old threads discussing this, making sure destructors run and the runtime terminates properly, all of which seemingly concluding that it's sad that there isn't a way to do this easily, but hopefully things have changed in the last 5-10 years and I'm just missing the obvious solution.
Re: enum and const or immutable ‘variable’ whose value is known at compile time
On Thursday, 17 September 2020 at 13:25:08 UTC, Mike Parker wrote: Well, I was already using anonymous enums for compile-time And, I should add, I have *never* seen C enums as an enumerated list of values. I've always seen them as an alternative for #defined constants because they're anonymous. It's *named* enums that I view as enumerated lists of values. So, in terms of vocabulary definitions, that was already a non-issue for me before I even discovered D.
Re: enum and const or immutable ‘variable’ whose value is known at compile time
On Thursday, 17 September 2020 at 13:13:46 UTC, Simen Kjærås
wrote:
To quote Bill Baxter from way back when
(https://forum.dlang.org/post/fjdc4c$2gft$1...@digitalmars.com):
> Why does:
> final int x = 3;
> make any more intuitive sense than:
> enum int x = 3;
> ?
There are these things called "words". And they have
"meanings"...
enum: (short for "enumeration", the noun form of "enumerate")
"to specify one after another : list"
final:
"not to be altered or undone "
To be clear: I don't mind 'enum' being used this way, but if I
were to do things over again, I would have used 'alias'.
Well, I was already using anonymous enums for compile-time
constants anyway. For example, when translating C headers with
lots of #defined constants (OpenGL is the poster child), I was
doing this in Derelict:
enum {
GL_THIS = ...,
GL_THAT = ...,
}
So enum for this has always made sense to me. I would have been
fine with final, but it would have been a leap for me because of
my Java background; I would have kept seeing it as a synonym for
const. And I would never have liked the Alias approach.
But no matter what solution would have been implemented (final,
Alias, new keyword), I would have looked it up then, put my head
down and gotten right back to writing code. It just happens the
one that's most intuitive to me was picked :-)
Re: enum and const or immutable ‘variable’ whose value is known at compile time
On Thursday, 17 September 2020 at 10:56:28 UTC, Mike Parker wrote:
On Thursday, 17 September 2020 at 09:44:20 UTC, claptrap wrote:
Seriously how it's implemented is irrelevant.
And to be clear, my point wasn't about how it's implemented. My
point was that:
enum { foo = 10; }
and
enum foo = 10;
Are effectively the same thing, whether it's implemented that
way or not. So why on earth would a new keyword be necessary?
I could imagine some new users may think in
enum foo = someTemplate!();
someTemplate could evaluate to a list of values like a 'normal'
enum. That's just conjecture, though. The one thing I dislike
about enum like this is that we have another keyword that's able
to handle manifest constants when tickled correctly, and which
doesn't evoke the image of an enumerated list of values:
import std.meta : Alias;
alias foo = Alias!([1,2,3]);
alias bar = Alias!9;
alias baz = Alias!someFunc;
Some of the above may be doable without Alias!(), but not all. I
don't know if you remember the discussions when bracketless enums
were introduced back in 2007ish, but alias was the prime
contender back then, and is slowly gaining the power that was
requested at the time (the ability to alias values as above was
added fairly recently).
To quote Bill Baxter from way back when
(https://forum.dlang.org/post/fjdc4c$2gft$1...@digitalmars.com):
> Why does:
> final int x = 3;
> make any more intuitive sense than:
> enum int x = 3;
> ?
There are these things called "words". And they have
"meanings"...
enum: (short for "enumeration", the noun form of "enumerate")
"to specify one after another : list"
final:
"not to be altered or undone "
To be clear: I don't mind 'enum' being used this way, but if I
were to do things over again, I would have used 'alias'.
--
Simen
Re: What kind of mangling has the LDC2 -X JsonFile "deco" field?
On Thursday, 17 September 2020 at 04:01:11 UTC, Adam D. Ruppe wrote: On Thursday, 17 September 2020 at 03:06:45 UTC, realhet wrote: Anyone can help me telling how to decode these please? Just prepend _D4name Thank you very much!
Re: enum and const or immutable ‘variable’ whose value is known at compile time
On Thursday, 17 September 2020 at 10:56:28 UTC, Mike Parker wrote: Are effectively the same thing, whether it's implemented that way or not. So why on earth would a new keyword be necessary? C++ made enums stricter by "enum class".
Re: enum and const or immutable ‘variable’ whose value is known at compile time
On Thursday, 17 September 2020 at 09:44:20 UTC, claptrap wrote:
Seriously how it's implemented is irrelevant.
And to be clear, my point wasn't about how it's implemented. My
point was that:
enum { foo = 10; }
and
enum foo = 10;
Are effectively the same thing, whether it's implemented that way
or not. So why on earth would a new keyword be necessary?
Re: enum and const or immutable ‘variable’ whose value is known at compile time
On Thursday, 17 September 2020 at 09:44:20 UTC, claptrap wrote: Names are important, principle of least astonishment and all that, pretty much everyone coming to D is going be WTF in learning about that. And if you keep overloading existing keywords with more and more meanings the code gets harder and harder to grep at first glance. I can attest that in the 17 years I've been hanging around here, the fact that enum is used to indicate a manifest constant has not been a serious source of WTF posts. So I think "pretty much everyone coming to D" have decided it's either perfectly fine or perfectly tolerable. It's the sort of thing that may not be obvious, but once you figure you absorb it and get down to coding. I know some people would prefer it were something else and some don't care. I'm squarely in the camp that thinks it makes perfect sense and it would be silly to create a new keyword for it.
Specify dmd or ldc compiler and version in a json dub file?
https://forum.dlang.org/post/nnxbwdypwepymgerz...@forum.dlang.org On Tuesday, 8 August 2017 at 09:17:02 UTC, data pulverizer wrote: Hi, I would like to know how to specify dmd or ldc compiler and version in a json dub file. Thanks in advance. https://dub.pm/settings.html
Re: Building LDC runtime for a microcontroller
On Wednesday, 16 September 2020 at 18:34:05 UTC, Adam D. Ruppe wrote: On Wednesday, 16 September 2020 at 17:59:41 UTC, Remi wrote: I tried to modify the hello.d example from your blog post. It works without changes but when I tried to do a string concatenation Yeah, concatenation is one of the features that uses druntime, and specifically, it is done through TypeInfo. I would actually personally skip it if you are doing a minimal custom thing. If you skip it, you can implement your own type instead of using the built-in array concat. You can make a struct with an operator overload to look basically the same, and it can give a slice to pass to other functions. This is much easier here - no druntime code needed and the user code will be clearer that they might have to manage the memory. Typical code with normal append tends to just assume there's no stomping, that the GC takes care of it, etc. I'm hitting linker errors related to TypeInfo: But if you do implement it, as of right now, you have to define TypeInfo. Which suckss because it is super tedious. There's a WIP pull request up there with dmd to templatize this which would help a lot. But right now it means implementing at least some of it. You'd need the base class TypeInfo, then TypeInfo_a (a == "char"), TypeInfo_Array, TypeInfo_Aa (which means "array of char"), then finally, TypeInfo_Aya, which is "array of immutable char", aka, string. Once you get enough of that up - and the compiler is picky about those right now - then the append operation is `_d_arrayappendcTX`, which takes TypeInfo as a param. Search these names in the druntime source to see their official implementations... it is a bit of a beast, which is why I recommend actually skipping them if you can. It quickly explodes in size and by the time you follow it to its final conclusion, you've reimplemented 3/4 of full druntime anyway and might as well have just done a port. I don't mind implementing enough to get my project running, I first tried Sebastiaan's WASM druntime port but I realised the project I'm working on wouldn't need that much to get running so I thought maybe I can slowly port each part until I get the project to run. My problem here is mostly understanding the __initZ symbol and where it comes from. I mostly want classes and the bare minimum of std like you did for Tetris in WebAssembly for example. My project is OpenGL/SDL2 so there's a lot of glue code but just ruinning a simple example gives me problems I want to understand first. I'll probably try what you describe in your "Zero-runtime classes" actually, and hopefully I can get away without the string manipulation or replace it with my own version of it.
Re: enum and const or immutable ‘variable’ whose value is known at compile time
On Thursday, 17 September 2020 at 01:57:39 UTC, Mike Parker wrote:
On Thursday, 17 September 2020 at 00:32:40 UTC, Cecil Ward
enum foo is essentially a shortcut for enum { foo }. It’s
neither bent out of shape nor twisted. Consider that C++ added
the new keyword constexpr for the same thing. Why pollute the
namespace with a new keyword when you already have one that
fits?
Seriously how it's implemented is irrelevant. When people use it
(for that use case) they arn't thinking ohh right here I want an
enum with one member. They are thinking I want a constant
expression evaluated at compile time. IE, C++ got something right
for once, D let the mechanic name the controls on the dashboard.
It's an "implementers name" and it's retarded beyond belief.
Seriously look up enumeration in a dictionary and explain how
that can be twisted to mean "constant expression" or "evaluated
at compile time".
Names are important, principle of least astonishment and all
that, pretty much everyone coming to D is going be WTF in
learning about that. And if you keep overloading existing
keywords with more and more meanings the code gets harder and
harder to grep at first glance.
Re: Install multiple executables with DUB
On Tuesday, 8 September 2020 at 08:41:24 UTC, glis-glis wrote: Following the advice of drug, I moved the "tools" folder from src to the parent directory, added a dependency to "biophysics" with path ".." and build the binaries with "dub build --single tools/..." This works fine, however, now I have a problem when editing with Emacs: Flycheck gives errors as it cannot find my package anymore and company autocomplete does not work anymore neither. By the way, I have the same problem when I clone tsv-utils and open the source file with Emacs. I have to admit I am using emacs' d-mode as a black-box since there seems to be no documentation, and I am not very fluent in elisp... To follow up, I came up with the following folder structure: . ├── bin │ └── ... ├── dub.sdl ├── install ├── lib │ └── ... ├── src │ └── biophysics │ └── ... ├── test │ └── ... └── tools ├── biophysics -> ../src/biophysics └── ... the symbolic link did the trick for emacs Flycheck and Company. The install script simply reads #!/usr/bin/env bash for f in tools/*.d; do dub build --build=release --single $f done
