Re: A vibe.d thing
On Fri, 2018-07-27 at 15:58 -0400, Steven Schveighoffer via Digitalmars-d-learn wrote: > […] > > I'm guessing they don't use it, but use peek instead (or maybe peek > to > get the size, and then read to get the data). I tried using req.bodyReader.peek, but that only works for situations where there is only a small amount of data. In particular it fails spectacularly if there is a large amount of data, but for what reason I cannot infer. Do you have an example of getting the body data size so as to do that, I can't see non-deprecated things to do that. > I'd be surprised if there isn't some better I/O options in vibe.d. I > mainly use the higher-level features. The CVu Code Critique 112 code isn't doing anything actually sensible, it is about echoing POSTed data. I suspect vibe.d is only reqlly working when used in an idiomatic way for stuff that is normal in the single threaded asynchronous server world. If you can point me at a few examples, I have today and Tuesday to try and put together a working example solving the CC112 problem that is not totally crap. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
How to best implement a DSL?
Hi, I'm seeking for ideas/comments/experiences how to best implement a
DSL in D.
What I would like to do is something like this:
... my D code ...
my-dsl {
... my multi-line DSL code ...
trade 100 shares(x) when (time < 20:00) and timingisright()
}
... my D code ...
Some things that circle in my head:
* Can the D parser somehow be missued for a DSL? So I can skip all the
generic features for types etc.?
* I could use a PEG grammer for parsing the DSL, but this leads to
quite some overhead for a tiny DSL.
* For static DSL code I would like to use CTFE to convert it into D code
* Does this requires a CTFE compatible PEG parser tookit?
* Could I somehow call an external program during compilation which
gets the DSL block as input and returns D code?
* For dynamic DSL code I think I need to create something like an interpreter
* How can I reference D variables from DSL code? Is there a lookup
meachnisam or do I have to create a dictonary?
* Is it possible to populate such a dictonary via CTFE?
--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster
Re: How to best implement a DSL?
On 29/07/2018 2:59 AM, Robert M. Münch wrote:
Hi, I'm seeking for ideas/comments/experiences how to best implement a
DSL in D.
What I would like to do is something like this:
... my D code ...
my-dsl {
... my multi-line DSL code ...
trade 100 shares(x) when (time < 20:00) and timingisright()
}
... my D code ...
Some things that circle in my head:
* Can the D parser somehow be missued for a DSL? So I can skip all the
generic features for types etc.?
Let's go with no.
* I could use a PEG grammer for parsing the DSL, but this leads to quite
some overhead for a tiny DSL.
* For static DSL code I would like to use CTFE to convert it into D code
* Does this requires a CTFE compatible PEG parser tookit?
Yes.
* Could I somehow call an external program during compilation which
gets the DSL block as input and returns D code?
No. But you can pre-process.
* For dynamic DSL code I think I need to create something like an
interpreter
* How can I reference D variables from DSL code? Is there a lookup
meachnisam or do I have to create a dictonary?
Registration, but like you said, a giant dictionary.
* Is it possible to populate such a dictonary via CTFE?
Sort of, it can be registered, but the actual execution of the
registration occurs at runtime.
But you're slightly over thinking this. Write an interpreter and a
parser. The fact that the parser can work at CTFE is irrelevant and
almost a footnote on the page of details ;).
If you want to be clever you could generate D code and mix it in based
upon what was parsed. But you'd still want that dictionary.
Re: How to best implement a DSL?
On 2018-07-28 15:43:12 +, rikki cattermole said: * Could I somehow call an external program during compilation which gets the DSL block as input and returns D code? No. But you can pre-process. Yes, sure, but this complicates the build-system. I preferr to use as few parts as possible. * Is it possible to populate such a dictonary via CTFE? Sort of, it can be registered, but the actual execution of the registration occurs at runtime. Yes, no problem. How is this done? But you're slightly over thinking this. Write an interpreter and a parser. The fact that the parser can work at CTFE is irrelevant and almost a footnote on the page of details ;). Not really if you think about deployment. I want to create a single executable, no external files. So I somehow have to get the scripts included or use the compiler as generator. The main use-case is, that I want to use a very declarative approach for some UI parts. If you want to be clever you could generate D code and mix it in based upon what was parsed. But you'd still want that dictionary. Yes, mixing in generate D code was the idea. However, I think a good included infrastructure that support creating DSLs might help a lot to simplify this. -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Re: A vibe.d thing
On Fri, 2018-07-27 at 15:58 -0400, Steven Schveighoffer via Digitalmars-d-learn wrote: > […] > Haha, I don't blame you. The docs should say in bold letters (NOT > IMPLEMENTED). In the end I used the deprecated leastSize property to create a right size buffer so the read function never tries to read more data than it has. This gets round the exception being thrown and makes for quite a nice solution. The problem is of course the leastSize property is being deprecated. This seems like a bad idea to me, especially given the read function is actually broken with respect reads shorter than the buffer. […] > > I'd be surprised if there isn't some better I/O options in vibe.d. I > mainly use the higher-level features. Any chance of you doing an article on D and vibe.d proper use prompted by this Code Critique so as to show CVu readers what vibe.d is really like – as opposed to the rather negative image readers will get from this Code Critique. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: How to best implement a DSL?
On 29/07/2018 4:53 AM, Robert M. Münch wrote: On 2018-07-28 15:43:12 +, rikki cattermole said: * Could I somehow call an external program during compilation which gets the DSL block as input and returns D code? No. But you can pre-process. Yes, sure, but this complicates the build-system. I preferr to use as few parts as possible. * Is it possible to populate such a dictonary via CTFE? Sort of, it can be registered, but the actual execution of the registration occurs at runtime. Yes, no problem. How is this done? Usually either a mixin template or a string mixin that plops a module constructor down with it calling a register function with whatever data you happened to compute/create using CTFE. But you're slightly over thinking this. Write an interpreter and a parser. The fact that the parser can work at CTFE is irrelevant and almost a footnote on the page of details ;). Not really if you think about deployment. I want to create a single executable, no external files. So I somehow have to get the scripts included or use the compiler as generator. The main use-case is, that I want to use a very declarative approach for some UI parts. You missed my point here. There is nothing special about parsing at CTFE, you're just restricted as to the language features you can use (e.g. no extern's), that's it.
Re: How to get an inout constructor working with a template wrapper
On Friday, 27 July 2018 at 14:38:27 UTC, Steven Schveighoffer
wrote:
On 7/27/18 9:29 AM, aliak wrote:
Ok, thanks to Simen from another post [0], I just figured out
what the correct constructor and factory method for a template
wrapper should be:
https://run.dlang.io/is/S4vHzL
struct W(T) {
T val;
this(U : T, this This)(auto ref U val) {
this.val = val;
}
}
auto wrap(T)(auto ref T t) {
return W!T(t);
}
Seems to catch all cases!
And instantiate a new template for all mutabilities. Whereas
inout would only instantiate one (and disallows modification of
val if not const or immutable).
-Steve
If you change the ctor to be inout then you get (from the link
above):
onlineapp.d(4): Error: cannot implicitly convert expression val
of type onlineapp.C to inout(C)
onlineapp.d(28): Error: template instance
`onlineapp.W!(C).W.__ctor!(C)` error instantiating
onlineapp.d(4): Error: cannot implicitly convert expression val
of type S1 to inout(S1)
onlineapp.d(44): Error: template instance
`onlineapp.W!(S1).W.__ctor!(S1)` error instantiating
onlineapp.d(4): Error: cannot implicitly convert expression val
of type onlineapp.C to inout(C)
onlineapp.d(9): Error: template instance
`onlineapp.W!(C).W.__ctor!(C)` error instantiating
onlineapp.d(52):instantiated from here: wrap!(C)
onlineapp.d(4): Error: cannot implicitly convert expression val
of type const(C) to inout(const(C))
onlineapp.d(9): Error: template instance
`onlineapp.W!(const(C)).W.__ctor!(const(C))` error instantiating
onlineapp.d(53):instantiated from here: wrap!(const(C))
Am I applying inout incorrectly?
Re: How to avoid inout type constructor with Optional type wrapper undoing string type
On Friday, 27 July 2018 at 14:52:20 UTC, Steven Schveighoffer
wrote:
On 7/23/18 2:39 PM, aliak wrote:
Hi,
I'm playing around with an Optional wrapper type. It stores a
type T and a bool that defines whether a value is defined or
not:
struct Optional(T) {
T value;
bool defined = false;
this(U : T)(auto ref inout(U) value) inout {
this.value = value;
this.defined = true;
}
}
Don't use inout here. The point of inout on the constructor is
to *transfer* the mutability of the parameter to the struct
instance. But you want to simply copy the type into the struct
(an immutable(Optional!T) is quite useless, no?)
Just use U, not inout(U), and don't put inout on the
constructor.
-Steve
But then it only works for mutable Optional right? Why would an
immutable(Optional!T) be useless? Data can be "forever" empty or
a certain value.
Re: How to get an inout constructor working with a template wrapper
On Friday, 27 July 2018 at 14:34:54 UTC, Steven Schveighoffer wrote: The problem here is that inout(immutable(int)) is equivalent to immutable(int). That is, all flavors of mutability are equivalent to immutable(int): /*mutable*/(immutable(int)) => immutable(int) const(immutable(int)) => immutable(int) immutable(immutable(int)) => immutable(int) So the compiler really looks at your wrap instantiation like this; inout(W!(immutable(int))) wrap(immutable(int) t) Ah ok, so the compiler remove inout behind me back here? (And then tells me it needs to be there? :p) which triggers the (really bad) message. I'd ask, why are you even worrying about explicit instantiation? Why not just wrap(3)? Just because I don't see why it should not work really. Why not allow wrap!(immutable int)(3)? or (if you really want to test it) wrap(immutable(int)(3))? To make it compile successfully you can either: 1) Chance immutable to const, then it works for some reason. Because immutable(const(int)) => immutable(int), so the compiler can't remove the inout behind your back. 2) Change the line to: "auto si = wrap(cast(immutable int)3);" - i.e. do not explicitly provide type information. Yep, do this :) Note that the point of inout is 2-fold: 1. reduce template instantiations. In fact, wrap!int works for const, mutable and immutable int. 2. ENSURE that the data isn't modified, even in the case of mutable parameters. Thanks for the explanations! For some reason it's hard to get it all to *just work* right now without the template this. But it's probably some minor detail I'm just overlooking... -Steve
dynamically loading a dynamic library from the program
I read this article: https://dlang.org/articles/dll-linux.html However, I did not find the answer to my questions. = = = = Facts: a. I have closed-source dynamic library (DLL) on Windows (e.g.: AutoItScript). b. I do not know the language and compiler in which it was created. c. I can get a list of symbols from it. d. I have function definitions from this library. Questions: 1. In this case, can I use this library in the D language program? 2. How to create initialization? = = = = Facts: e. Subthread "Dynamically Loading a C++ DLL From a D Program", from the article above. f. I have a dynamic library created in C not C++ on Windows. Questions: 3. Is it possible to use it regardless of the compiler that created it (e.g.: MinGW, MSVC)?
Re: dynamically loading a dynamic library from the program
On Saturday, 28 July 2018 at 22:30:38 UTC, Michal Kozakiewicz wrote: 1. In this case, can I use this library in the D language program? 2. How to create initialization? You can load it exactly the same way you would from C. The article you linked is about writing a DLL in D itself, but using a DLL from D is nothing special. Same functions as in C. The compiler of the dll doesn't matter.
Re: dynamically loading a dynamic library from the program
On Saturday, 28 July 2018 at 22:47:33 UTC, Adam D. Ruppe wrote: On Saturday, 28 July 2018 at 22:30:38 UTC, Michal Kozakiewicz wrote: 1. In this case, can I use this library in the D language program? 2. How to create initialization? You can load it exactly the same way you would from C. The article you linked is about writing a DLL in D itself, but using a DLL from D is nothing special. Same functions as in C. The compiler of the dll doesn't matter. Thank you for your answer!
What does std.traits.hasAliasing do
struct SomeStruct {
string p;
string q;
string[] pq;
}
ErrorMessage[] pq;
session.set("registerBody", pq);
/home/venkat/.dub/packages/vibe-d-0.8.4/vibe-d/http/vibe/http/session.d(83,3): Error:
static assert: "Type SomeStruct contains references, which is not supported for
session storage."
vibe.d session won't let me put in a simple struct with an array
or an associative array. session.put calls std.traits.hasAliasing
which is returning true when I have either an array or an
associative array. I looked through the std.traits.hasAliasing
code. I can't make a whole lot of sense there.
The hasAliasing function documentation says as long as the array
or associative array are not immutable it should return true.
Since session.put does !hasAliasing I changed string[] to
immutable, that throws a whole lot of other compilation error
messages.
What is hasAliasing doing ?
Re: What does std.traits.hasAliasing do
On Sunday, 29 July 2018 at 01:05:19 UTC, Venkat wrote:
struct SomeStruct {
string p;
string q;
string[] pq;
}
Session session = req.session;
session.get!SomeStruct("registerBody");
/home/venkat/.dub/packages/vibe-d-0.8.4/vibe-d/http/vibe/http/session.d(83,3): Error:
static assert: "Type SomeStruct contains references, which is not supported for
session storage."
vibe.d session won't let me put in a simple struct with an
array or an associative array. session.put calls
std.traits.hasAliasing which is returning true when I have
either an array or an associative array. I looked through the
std.traits.hasAliasing code. I can't make a whole lot of sense
there.
The hasAliasing function documentation says as long as the
array or associative array are not immutable it should return
true. Since session.put does !hasAliasing I changed string[] to
immutable, that throws a whole lot of other compilation error
messages.
What is hasAliasing doing ?
Posted the wrong code. Fixed it above. Reposting below for
clarity. For the record both session.get and session.put call
hasAliasing.
struct SomeStruct {
string p;
string q;
string[] pq;
}
Session session = req.session;
session.get!SomeStruct("registerBody");
