difference between x = Nullable.init and x.nullify
Hello,
What's the difference between x = Nullable!Test.init and
x.nullify?
class Test{}
void test()pure nothrow{
Nullable!Test x;
x = Nullable!Test.init; //OK
x.nullify; //Error: function
'std.typecons.Nullable!(Test).Nullable.nullify!().nullify' is not
nothrow
}
Re: Guide - Migrating from std.experimental.ndslice to mir-algorithm
On Friday, 2 June 2017 at 16:08:20 UTC, Zz wrote: Hi, Just tried migrating from std.experimental.ndslice to mir-algorithm. Is there a guide on how migrate old code? I used the following imports before and using then with ndslice. import std.experimental.ndslice; import std.algorithm : each, max, sort; import std.range : iota, repeat; simplified example of how it was used. auto a = cr.iota.sliced(r, c); auto b = a.reshape(c, r).transposed!1; auto c = a.reversed!1; auto d = a.reshape(c, r).transposed!1.reversed!1; auto f = new int[cr].sliced(r, c); auto h = f.transposed(1); how can I do the following in mir-algorithm. Note: I will be going through the documentation. Zz Hello Zz, std.experimental.ndslice -> mir.ndslice std.range : iota, repeat -> mir.ndslice.topology: iota, repeat; std.algorithm : each; -> mir.ndslice.algorithm: each; std.algorithm : max; -> mir.utility: max; std.algorithm : sort; -> mir.ndslice.sorting: sort; Note, that Mir functions has different semantics compared with Phobos! For example, each iterates deep elements, so should be combined with `pack` to iterates rows instead of elements. Ndslices work with Phobos functions but it is suggested to use Mir analogs if any. // Mir's iota! It is already 2D ndslice :-) auto a = [r, c].iota; auto b = a // returns flattened iota, a has Contiguous kind, // so the result type would be equal to `iota(r*c)` .flattened // convert 1D iota ndslice to 2D iota ndslice .sliced(c, r) // It is required to use transposed // Convert ndslice kind from Contiguous to Universal. .universal // Transpose the Universal ndslice .transposed; auto c = a.universal.reversed!1; auto d = a.flattened.sliced(c, r).universal.transposed!1.reversed!1; // see also `rotated` auto f = slice!int(c, r); // new int[cr].sliced(r, c); works too. auto h = f.universal.transposed(1); --- Mir ndslices have three kinds: http://docs.algorithm.dlang.io/latest/mir_ndslice_slice.html#.SliceKind If you have any questions feel free to ask at the Gitter: https://gitter.im/libmir/public Best, Ilya Best, Ilya
Re: D scripting in D
On Fri, 2017-06-02 at 20:47 +, Mike B Johnson via Digitalmars-d- learn wrote: > […] > > Would you mind, when you get some time, to write up a more > detailed analysis of the problems you had to overcome to get it > to work? Possibly we could get some type of library solution that > just "works" with very little change and restriction? > > After all, dll's effectively already solve the problem, in some > sense... except they are generally not meant to be reloaded on > demand. Solving the issues that reloading causes, I think, would > be the bulk of the problem? And there are always magazines/journals such as Overload and CVu [1] which are places to publish articles that are more than just Web ephemera. [1] https://accu.org/index.php/journal -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: D scripting in D
On Fri, 2017-06-02 at 12:27 +, Adam D. Ruppe via Digitalmars-d- learn wrote: > On Friday, 2 June 2017 at 09:39:51 UTC, Russel Winder wrote: > > With D and Go, both of which claim compilation so fast you do > > not notice: > > 1. Edit > 2. run rdmd > There is no rdmd on Fedora Rawhide. There is only ldc2. (Indeed Debian Sid has no rdmd either by default, you have to use d-apt.) > Especially if you only expose to the "script" in D the same > functions you'd expose to, say, a javascript script, that compile > can be under a tenth of a second. > > But 3/10 of a second isn't bad either and that's about what you'd > get with an out of the box setup... Not enough is made of rdmd. rdmd needs to be separated from dmd so it works with gdc and ldc2. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: D scripting in D
On Friday, 2 June 2017 at 20:47:31 UTC, Mike B Johnson wrote: Would you mind, when you get some time, to write up a more detailed analysis of the problems you had to overcome to get it to work? Possibly we could get some type of library solution that just "works" with very little change and restriction? For sure. I actually want to post the source code at some point, but the changes I made are very much set up specifically for this project. I'll sift through at some point and see if I can gather together something worth posting. The main problem with hot-reloading DLLs stems from the fact that every new D DLL comes with its own copy of druntime. This means a second GC, a second registry of active threads, a second registry of typeinfos, and so on. If there were a way to load a D DLL that automatically used the executable's copy of druntime, most of the hacks I had to make could be removed. For reference, my general approach is that I have an EXE and a DLL. We run the EXE, which makes a copy of the DLL and loads the copy. Once per frame, the EXE calls GameUpdateAndRender() on the DLL, which does everything needed to step the game forward one frame. After each call to GameUpdateAndRender(), the EXE checks to see if the original DLL has changed. If so, we unload the DLL, make a copy of the new one, and load the copy. We then continue calling GameUpdateAndRender() as usual. All game state that needs to survive a hot reload is stored directly (or referenced indirectly) from a giant struct call the GameState. The EXE keeps a void* to the GameState, that way the GC doesn't collect anything inside it. The main issues I remember off the top of my head: - I have to use the GC proxy to redirect DLL GC calls over to the EXE's GC. This is because when I hot reload, the DLL's GC dies, so it can't be holding on to anything that needs to survive the hot reload (and I want pretty much everything to survive a hot reload). - D has some built-in support for redirecting GC calls. However when you load a DLL, by the time you get a chance to call gc_setProxy(), it's too late, and druntime has already done a few allocations into the DLL GC. I had to change the order of a couple parts of initialization (in runtime.d I think?), and in my own code defer calling dll_attach_process() until after DllMain(). That way I get a chance to set up the GC proxy, then initialize druntime, which will trigger a few allocations that now go to the right place. - I haven't experimented thoroughly with threading, but I think I have to do something similar. Since we're using the EXE's GC, if the EXE's druntime doesn't know about the existence of a thread spawned through the DLL's druntime, then we run into problems. So I redirect all thread spawning over to the EXE. - With threading, we have to be careful that we don't tear down the DLL from underneath a thread that might still be running code on it. We have two options. 1. Join all threads before unloading the DLL. 2. The thread needs to be running a procedure that originates in the EXE, and then calls into the DLL, returning periodically back to the EXE. While execution is back in the EXE, we take that moment to reload the DLL. Currently I'm doing the former, but might move to the latter if I end up needing long-lived threads for performance reasons. Note that callbacks originating from C code running on a separate thread also have this same restriction, and need to be handled careful. - The different druntimes have different typeinfos for each class. This can be problematic for a few reasons, and I don't have as total a grasp on what situations related to classes are guaranteed to cause a crash. In particular, finalizers seem to cause problems, so I have disabled them entirely in druntime. In my own code, I almost exclusively use structs, and any instances of classes I do use are never stored long-term, and are never allowed to survive a hot reload. I think those are all the D-specific gotchas, but I'll double-check my notes when I get home. In addition, there are common gotchas to this approach that would exist in other languages (C/C++ for example). Examples: - Static variables will die in a hot reload, so be cautious using them. - Storing a char* or string that references string in the data segment of the DLL will cause problems when we hot reload. To avoid this, I have a templated function that, on hot reload, iterates over my entire gamestate and copies each string. Since hot reloading is a debug-only utility for me, this is acceptable. - Code changes to the gamestate struct will require a restart. Adding a new field to the gamestate does not, since I have some padding room at the end of the struct where I can add new fields during a hot reload. - Don't hold on to function pointers through a hot reload, as functions addresses are liable to be reshuffled in the new DLL. - Probably some others I'm
Re: Trouble with SList for generic Stack class
On Friday, 2 June 2017 at 23:34:14 UTC, Ali Çehreli wrote: You've probably seen H. S. Teoh's answer but still... :) ... Ali Awesome, thanks everyone!
Re: Trouble with SList for generic Stack class
You've probably seen H. S. Teoh's answer but still... :)
On 06/02/2017 04:05 PM, Mark wrote:
> Am I supposed to write template Struct(T) { class Stack { ... } }?
Not necessary because in this case it's the same thing as
class Stack(T) {
// Don't templatize functions in here (in general)
}
However, you can templatize member functions as well if you want them to
work with different types as well. For example, push() may work with any
type that can be converted to T.
class Stack(T) {
private SList!T list;
private int _size;
this() {
// Aside: No need to initialize members (in this case)
// list = SList!T;
// _size = 0;
}
public void push(T item) {
list.insertFront(item);
_size++;
}
public void pop() {
if(_size > 0){
list.removeFront();
_size--;
}
}
// Aside, length() is more idiomatic:
public int length() { return _size; }
}
Ali
Re: Trouble with SList for generic Stack class
On Fri, Jun 02, 2017 at 11:05:43PM +, Mark via Digitalmars-d-learn wrote:
[...]
> Stefan, what do you mean that it must be a template?
>
> Am I supposed to write template Struct(T) { class Stack { ... } }?
No, he means to turn class Stack into a template by adding a template
parameter to it, like I suggested.
In D, writing `class Stack(T) { ... }` is equivalent to writing:
template Stack(T) {
class Stack { ... }
}
It's the so-called eponymous template.
The reason you need a template here is because, unlike Java, D does not
do type erasure to achieve generic types. Full type information is
preserved, so Stack!int and Stack!string represent distinct,
incompatible types.
T
--
Never wrestle a pig. You both get covered in mud, and the pig likes it.
Re: Trouble with SList for generic Stack class
Awesome. That worked.
On Friday, 2 June 2017 at 22:30:28 UTC, Stefan Koch wrote:
On Friday, 2 June 2017 at 22:21:07 UTC, Mark wrote:
Hello,
I am trying to make a class that can accept any type as an
argument.
[...]
the stack class needs to be a template as well.
This is not java ;)
Stefan, what do you mean that it must be a template?
Am I supposed to write template Struct(T) { class Stack { ... } }?
I got that from programming in D, in the more templates section.
This worked as well.
What is the benefit of using the full syntax for templates?
I'm new to templates, this is the first time I've ever used them.
Thanks.
Re: Trouble with SList for generic Stack class
On Fri, Jun 02, 2017 at 10:21:07PM +, Mark via Digitalmars-d-learn wrote:
> Hello,
>
> I am trying to make a class that can accept any type as an argument.
>
> Here is the class:
>
>
> import std.container: SList;
>
>
> class Stack {
>
> private SList!T list;
> private int _size;
>
> this(T)() {
> list = SList!T;
> _size = 0;
> }
>
> public void push(T)(T item) {
> list.insertFront(item);
> _size++;
> }
>
> public void pop(T)() {
> if(_size > 0){
> list.removeFront();
> _size--;
> }
> }
>
> public int getSize() { return _size; }
>
> }
>
>
> When I compile with dmd, I get this error:
>
> Stack.d(6): Error: undefined identifier 'T'
>
> That's on the line private SList!T list;
Yes, because T is not specified when .list is declared. What you need
to do is to put the template parameter on your class instead of your
methods, something like this:
class Stack(T) {
private SList!T list;
private int _size;
this() {// N.B. no template parameter here
list = SList!T;
_size = 0;
}
public void push(T item) { // N.B. no template parameter here
...
}
...
}
T
--
What do you get if you drop a piano down a mineshaft? A flat minor.
Re: Trouble with SList for generic Stack class
On Friday, 2 June 2017 at 22:21:07 UTC, Mark wrote: Hello, I am trying to make a class that can accept any type as an argument. [...] the stack class needs to be a template as well. This is not java ;)
Trouble with SList for generic Stack class
Hello,
I am trying to make a class that can accept any type as an
argument.
Here is the class:
import std.container: SList;
class Stack {
private SList!T list;
private int _size;
this(T)() {
list = SList!T;
_size = 0;
}
public void push(T)(T item) {
list.insertFront(item);
_size++;
}
public void pop(T)() {
if(_size > 0){
list.removeFront();
_size--;
}
}
public int getSize() { return _size; }
}
When I compile with dmd, I get this error:
Stack.d(6): Error: undefined identifier 'T'
That's on the line private SList!T list;
So the SList needs a type, but I can't give that type to it at
that moment when I instantiate the class.
How do I over come this problem?
I might just write this again, using structs as a SLL. I might
have similar issues with that as well.
Thanks,
Mark.
Re: Creating and loading D plugins in D app
On Friday, 2 June 2017 at 12:19:48 UTC, Adam D. Ruppe wrote: On Friday, 2 June 2017 at 11:09:05 UTC, aberba wrote: 1. Get shared libs to work in D (the best approach for all D code) I have done very little with this myself but other people have so it is doable. 1. some kind of embeddable interpreter for a scripting language like (a mini js engine) which exposes callable native D APIs at runtime My script.d does this kind of thing http://dpldocs.info/experimental-docs/arsd.script.html#examples it is slow though. You should put a link on the help somewhere so one can get to the github page easily to view the source(or have the ability to go from the module to the github source easily(small icon next to module name in modules list). This would help peruse the source to see how you came up with some of your stuff ;)
Re: Creating and loading D plugins in D app
On Thursday, 1 June 2017 at 23:24:13 UTC, aberba wrote: Want to create and load plugins written in D into a D app at run-time, the kind that can make api calls or extended main app with other functionality. I'm currently interested in it for a vibe.d app. How does these stuff work? Plugin system c++ http://blog.nuclex-games.com/tutorials/cxx/plugin-architecture/
Re: D scripting in D
On Friday, 2 June 2017 at 15:55:53 UTC, Lewis wrote: On Friday, 2 June 2017 at 02:06:27 UTC, Mike B Johnson wrote: I wonder if it is possible to somehow turn D in to a scripting language that can be run inside D? On a game project I'm working on at home, I've done: - Hot reloading via a DLL - A build script that runs in the background, detects file changes, and automatically rebuilds - A code structure that keeps build times to a minimum (currently 1.8s) All these combined, and D feels pretty script-like. The setup is far from ideal, since it imposes some limitations on the language (only limited use of classes/finalizers, be careful with static data, some changes to the program state struct require a restart, etc). It also took a significant amount of work to get it up and running, requiring several changes to druntime. But writing an entire feature with the game still running, followed by testing and iterating, all without closing the game, is pretty great. Way nicer than at work, where I have 1-15 minute rebuilds, with a restart for every change. Would you mind, when you get some time, to write up a more detailed analysis of the problems you had to overcome to get it to work? Possibly we could get some type of library solution that just "works" with very little change and restriction? After all, dll's effectively already solve the problem, in some sense... except they are generally not meant to be reloaded on demand. Solving the issues that reloading causes, I think, would be the bulk of the problem?
Re: D scripting in D
On Friday, 2 June 2017 at 17:50:30 UTC, H. S. Teoh wrote: On Fri, Jun 02, 2017 at 05:22:20PM +, Stefan Koch via Digitalmars-d-learn wrote: On Friday, 2 June 2017 at 16:13:03 UTC, Laeeth Isharc wrote: > [...] No there is not. First it's woefully incomplete and secondly it's tightly bound to dmd, and it's semantic phases Hmm. I wonder if there's a way for, say, ldc to export llvm bytecode of a given D program, such that another program can load this bytecode and interpret it at runtime? Is it possible to use llvm in such a way? T Yes it is possible but you will be astonished how slow this will be. It is probably more viable run dmd and have it compile into a shared library.
Re: D scripting in D
On Friday, 2 June 2017 at 17:22:20 UTC, Stefan Koch wrote: On Friday, 2 June 2017 at 16:13:03 UTC, Laeeth Isharc wrote: On Friday, 2 June 2017 at 02:06:27 UTC, Mike B Johnson wrote: [...] Stefan Koch has written a good part of an interpreter for D AST, no? And I guess the lexing and parsing stage doesn't take so long, whereas not having to link saves much time. So is there any way to repurpose his work on ctfe to have an interpreter that you can call at run time, set context for and get return values back? No there is not. First it's woefully incomplete and secondly it's tightly bound to dmd, and it's semantic phases Maybe it's incomplete today, but some day it will be or could be finished. And whilst I understand the difficulty of working with the dmd codebase as it's structured today, why is it intrinsically a problem that your work is bound to dmd? T - interesting idea about ldc though that's a bit slower than dmd.
Re: D scripting in D
On Fri, Jun 02, 2017 at 05:22:20PM +, Stefan Koch via Digitalmars-d-learn wrote: > On Friday, 2 June 2017 at 16:13:03 UTC, Laeeth Isharc wrote: > > On Friday, 2 June 2017 at 02:06:27 UTC, Mike B Johnson wrote: > > > [...] > > > > Stefan Koch has written a good part of an interpreter for D AST, no? > > And I guess the lexing and parsing stage doesn't take so long, > > whereas not having to link saves much time. > > > > So is there any way to repurpose his work on ctfe to have an > > interpreter that you can call at run time, set context for and get > > return values back? > > No there is not. First it's woefully incomplete and secondly it's > tightly bound to dmd, and it's semantic phases Hmm. I wonder if there's a way for, say, ldc to export llvm bytecode of a given D program, such that another program can load this bytecode and interpret it at runtime? Is it possible to use llvm in such a way? T -- People tell me that I'm skeptical, but I don't believe them.
Re: Mixin in Inline Assembly
On Thursday, 1 June 2017 at 12:00:45 UTC, Era Scarecrow wrote: So why is the offset off by 14h (20 bytes)? It's not like we need a to set a ptr first. Go figure i probably found a bug... Well as a side note a simple yet not happy workaround is making a new array slice of the memory and then using that pointer directly. Looking at the intel opcode and memory call conventions, I could have used a very compact intel set and scaling. Instead I'm forced to ignore scaling, and I'm also forced to push/pop the flags to save the carry when advancing the two pointers in parallel. Plus there's 3 instructions that don't need to be there. Yeah this is probably nitpicking... I can't help wanting to be as optimized and small as possible.
Re: howto count lines - fast
On Thu, Jun 01, 2017 at 08:39:07AM +0100, Russel Winder via Digitalmars-d-learn wrote: > On Wed, 2017-05-31 at 16:37 -0700, H. S. Teoh via Digitalmars-d-learn > wrote: > > > […] > > With D, we can have the cake and eat it too. The understandable / > > naïve implementation can be available as a fallback (and reference > > implementation), with OS-specific optimized implementations guarded > > under version() or static-if blocks so that one could, in theory, > > provide implementations specific to each supported platform that > > would give the best performance. > > But isn't that the compiler's job? Unfortunately, the compiler can only go so far, because it doesn't understand the larger context of what you're trying to accomplish. Modern optimizing compilers certainly go a lot further than before, but still, at some point some amount of human judgment is needed. Also, compiler implementors do still have to do the "heroics", or rather, teach the compiler to do the "heroics" when compiling straightforward code. So while the general programmer probably will have less need for it, compiler writers still need to know how to do them in order to write the optimizing compilers in the first place. > The lesson of functional programming, logic programming, etc. (when > the acolytes remember the actual lesson) is that declarative > expression of goal is more comprehensible to people than detailed > explanation of how the computer calculates a result. Object-oriented > computing lost the plot somewhere in the early 2000s. There is no argument that straightforward code is more comprehensible to people. The question here is whether it delivers maximum performance. We know from Kolgomorov complexity theory that global optimization, in the general case, is undecidable, so no optimizing compiler is going to be able to generate optimal code in all cases. There will always be cases where you have to manually tweak it yourself. Of course, that doesn't mean you go around micro-optimizing everything -- the usual approach is to write it the straightforward way first, then profile it, identify the hotspots, and find ways to improve performance in the hotspots. Well, at a higher level, the first order of business is really to look at it from an algorithmic POV and decide whether or not a different algorithm ought to be used (and no optimizing compiler can help you there). Then if that's still not enough, then you dig into the details and see if you can squeeze more juice out of your current algorithms -- if the profiler has indicated that they are the bottleneck. > The advance of Scala, Kotlin, Groovy, and now Rust and Go (but only to > some extent), which D has, is to express algorithms as declarative > requirements in a dataflow manner. > > One day hardware people will catch up with the hardware innovations of > the 1970s and 1980s regarding support of dataflow rather than state. Dataflow can only capture a limited subset of algorithms. Of course, in my observation, 90% of code being written today generally belongs in the category of what I call "linear shuffling of data", i.e., iterate over some linear set of objects and perform some transformation X on each object, copying linear memory region X to linear memory region Y, rearranging some linear set of objects, permuting the order of some linear set of things, etc.. This category basically subsumes all of GUI programming and web programming, which in my estimation covers 90% or maybe even 95% of code out there. The bulk of game code also falls under this category -- they are basically a matter of copying X items from A to B, be they pixels to be copied to the video buffer, traversing the list of in-game objects to update their current position, direction, speed, or traversing scanlines of a polygon to map a 3D object to 2D, etc.. Almost all business logic also falls under this category. All of these are easily captured by dataflow models. However, there are algorithms outside of this category, that are not easily captured by the dataflow model. Solving certain graph theory problems, for example, require actual insight into the structure of the problem than mere "move X items from A to B". Route planning, which is an NP-complete problem that, for practical applications, can only be approximated, and therefore actual thought is required for how you actually go about solving the problem beyond "data X moves from A to B". Computing the convex hull of a set of input points, used for solving optimization problems, if expressed and solved in a naïve way, has O(n^3) time complexity, and therefore impractical for non-trivial problem instances. True, your average general programmer may not even know what a convex hull problem is, and probably doesn't even need to care -- at worst, there are already libraries out there that implement the algorithms for you. But the point is, *somebody* out there needs to write these algorithms, and they need to implement these
Re: D scripting in D
On Friday, 2 June 2017 at 16:13:03 UTC, Laeeth Isharc wrote: On Friday, 2 June 2017 at 02:06:27 UTC, Mike B Johnson wrote: [...] Stefan Koch has written a good part of an interpreter for D AST, no? And I guess the lexing and parsing stage doesn't take so long, whereas not having to link saves much time. So is there any way to repurpose his work on ctfe to have an interpreter that you can call at run time, set context for and get return values back? No there is not. First it's woefully incomplete and secondly it's tightly bound to dmd, and it's semantic phases
Re: Creating and loading D plugins in D app
On Fri, Jun 02, 2017 at 12:19:48PM +, Adam D. Ruppe via Digitalmars-d-learn wrote: > On Friday, 2 June 2017 at 11:09:05 UTC, aberba wrote: > > 1. Get shared libs to work in D (the best approach for all D code) > > I have done very little with this myself but other people have so it is > doable. [...] This is not directly related to the OP's question, but recently I wrote a program that, given a user-specified string, transforms it into D code using a code template, invokes dmd to compile it into a shared object, loads the shared object using dlopen(), and looks up the generated function with dlsym() to obtain a function pointer that can be used for calling the function. The shared object is unloaded after it's done. So it's definitely doable, in the sense that I've successfully generated D code, compiled it into a shared library, loaded it into the running executable, and can call the code. Of course, in my case, the code template is relatively simple so I don't have to worry about things like module ctors, shared data, non-TLS globals, or GC use. If you're planning to support those features, you might need to do a bit more work after calling dlopen(). At the very least you'd have to use dlsym() to look up module ctor symbols and run them before calling any other functions in the shared object, and you may have to initialize druntime in the shared object too, if it's statically linked. I'm not sure what happens if it's dynamically linked, or if it uses its own copy of the GC. In any case, this is all possible, it just takes someone to dig into the details and write the code to make it all work. Then publish it on github or dub, and the rest of us can reap the benefits too. ;-) T -- PNP = Plug 'N' Pray
Re: D scripting in D
On Friday, 2 June 2017 at 02:06:27 UTC, Mike B Johnson wrote: I wonder if it is possible to somehow turn D in to a scripting language that can be run inside D? The point? To have the same uniform syntax for quickly developing scripts that can then be easily transferred, if desired, in to a complete binary. e.g., suppose I am working in some type of analysis software. Use a Dscript like feature to develop and test different analysis algorithms quickly(rather than using the compile and execute model)... then once everything is working, move the code to a D file and compile it directly. Since the syntax would be identical(or nearly so) it would be quite easy to copy and paste... unlike, say, using lua or some other non-D like scripting language. Stefan Koch has written a good part of an interpreter for D AST, no? And I guess the lexing and parsing stage doesn't take so long, whereas not having to link saves much time. So is there any way to repurpose his work on ctfe to have an interpreter that you can call at run time, set context for and get return values back?
Guide - Migrating from std.experimental.ndslice to mir-algorithm
Hi, Just tried migrating from std.experimental.ndslice to mir-algorithm. Is there a guide on how migrate old code? I used the following imports before and using then with ndslice. import std.experimental.ndslice; import std.algorithm : each, max, sort; import std.range : iota, repeat; simplified example of how it was used. auto a = cr.iota.sliced(r, c); auto b = a.reshape(c, r).transposed!1; auto c = a.reversed!1; auto d = a.reshape(c, r).transposed!1.reversed!1; auto f = new int[cr].sliced(r, c); auto h = f.transposed(1); how can I do the following in mir-algorithm. Note: I will be going through the documentation. Zz
Re: D scripting in D
On Friday, 2 June 2017 at 02:06:27 UTC, Mike B Johnson wrote: I wonder if it is possible to somehow turn D in to a scripting language that can be run inside D? On a game project I'm working on at home, I've done: - Hot reloading via a DLL - A build script that runs in the background, detects file changes, and automatically rebuilds - A code structure that keeps build times to a minimum (currently 1.8s) All these combined, and D feels pretty script-like. The setup is far from ideal, since it imposes some limitations on the language (only limited use of classes/finalizers, be careful with static data, some changes to the program state struct require a restart, etc). It also took a significant amount of work to get it up and running, requiring several changes to druntime. But writing an entire feature with the game still running, followed by testing and iterating, all without closing the game, is pretty great. Way nicer than at work, where I have 1-15 minute rebuilds, with a restart for every change.
Re: D scripting in D
On Friday, 2 June 2017 at 02:06:27 UTC, Mike B Johnson wrote: I wonder if it is possible to somehow turn D in to a scripting language that can be run inside D? The point? To have the same uniform syntax for quickly developing scripts that can then be easily transferred, if desired, in to a complete binary. e.g., suppose I am working in some type of analysis software. Use a Dscript like feature to develop and test different analysis algorithms quickly(rather than using the compile and execute model)... then once everything is working, move the code to a D file and compile it directly. Since the syntax would be identical(or nearly so) it would be quite easy to copy and paste... unlike, say, using lua or some other non-D like scripting language. You might find the conversation on this thread interesting: http://forum.dlang.org/thread/tssitxrniaxacpktj...@forum.dlang.org
Re: How to cleanup array of structs?
On Friday, 2 June 2017 at 13:32:02 UTC, Suliman wrote:
I remember that there was topic about remobing data from
struct/arrays of structs. But I do not remember what is
idiomatic way to do it, and can't google it.
something like:
struct MyTrack
{
ulong id;
string recordDate;
int velocity;
int maxAllowedSpeedForRoad;
}
MyTrack mytrack;
MyTrack [] mytracks;
// filling
mytracks.clean() or what?
There are multiple options
// Will set the array to an empty one, and leave the
// old one for the GC to clean up when it feels like it.
// The safest way.
mytracks = null;
// Mostly equivalent:
mytracks = [];
// Will reuse the array, overwriting existing data.
// If other parts of the program are using existing data
// in the array, this will lead to hard-to-track-down bugs.
mytracks.length = 0;
mytracks.assumeSafeAppend();
// If you just want to get rid of the last element you added to
the array:
mytracks = mytracks[0..$-1];
--
Biotronic
How to cleanup array of structs?
I remember that there was topic about remobing data from
struct/arrays of structs. But I do not remember what is idiomatic
way to do it, and can't google it.
something like:
struct MyTrack
{
ulong id;
string recordDate;
int velocity;
int maxAllowedSpeedForRoad;
}
MyTrack mytrack;
MyTrack [] mytracks;
// filling
mytracks.clean() or what?
Re: Creating and loading D plugins in D app
On Friday, 2 June 2017 at 13:05:41 UTC, aberba wrote: Can source of script be reloaded at runtime? It is just an ordinary string. Do I have to wrap external APIs in the "global" object passed as argument to "interpreter()" Yes, anything the script calls must be exposed through that. It does a decent job automatically wrapping functions though, so just assigning them in a list might work. I'm trying to implement a plugin system for a vibe.d server where plugins can be installed to provide additional http routes: extending server functionality. might work.
Re: Creating and loading D plugins in D app
On Friday, 2 June 2017 at 12:19:48 UTC, Adam D. Ruppe wrote: On Friday, 2 June 2017 at 11:09:05 UTC, aberba wrote: 1. Get shared libs to work in D (the best approach for all D code) I have done very little with this myself but other people have so it is doable. 1. some kind of embeddable interpreter for a scripting language like (a mini js engine) which exposes callable native D APIs at runtime My script.d does this kind of thing http://dpldocs.info/experimental-docs/arsd.script.html#examples it is slow though. Performance doesn't matter now. Can source of script be reloaded at runtime? Do I have to wrap external APIs in the "global" object passed as argument to "interpreter()" I'm trying to implement a plugin system for a vibe.d server where plugins can be installed to provide additional http routes: extending server functionality.
Re: D scripting in D
On Friday, 2 June 2017 at 09:39:51 UTC, Russel Winder wrote: With D and Go, both of which claim compilation so fast you do not notice: 1. Edit 2. run rdmd Especially if you only expose to the "script" in D the same functions you'd expose to, say, a javascript script, that compile can be under a tenth of a second. But 3/10 of a second isn't bad either and that's about what you'd get with an out of the box setup...
Re: D scripting in D
On Friday, 2 June 2017 at 04:50:00 UTC, Mike B Johnson wrote: 4. Passing of the hosting D app's context. this could be pretty hard to get right? You'd ideally access the data through functions and shared value types instead of loading it directly. Then you can easily do it with shared libs or scripts or, best of all, an external process so if the "plugin" crashes, it doesn't crash the rest of the program. This is a decent design for any program really, it decouples components and keeps private members private.
Re: Creating and loading D plugins in D app
On Friday, 2 June 2017 at 11:09:05 UTC, aberba wrote: 1. Get shared libs to work in D (the best approach for all D code) I have done very little with this myself but other people have so it is doable. 1. some kind of embeddable interpreter for a scripting language like (a mini js engine) which exposes callable native D APIs at runtime My script.d does this kind of thing http://dpldocs.info/experimental-docs/arsd.script.html#examples it is slow though.
Re: Creating and loading D plugins in D app
On Friday, 2 June 2017 at 02:05:23 UTC, Stefan Koch wrote: On Thursday, 1 June 2017 at 23:24:13 UTC, aberba wrote: Want to create and load plugins written in D into a D app at run-time, the kind that can make api calls or extended main app with other functionality. I'm currently interested in it for a vibe.d app. How does these stuff work? It works using shared libraries. I just read it on Wikipedia. An alternative is to use a scripting/interpreted language. Working with such approach feels unnatural in D (considering pyd, lua-d). A more sustanable approach would be: 1. Get shared libs to work in D (the best approach for all D code) 1. some kind of embeddable interpreter for a scripting language like (a mini js engine) which exposes callable native D APIs at runtime None of which is within my current ability.
Re: Creating and loading D plugins in D app
On Friday, 2 June 2017 at 02:05:23 UTC, Stefan Koch wrote: On Thursday, 1 June 2017 at 23:24:13 UTC, aberba wrote: Want to create and load plugins written in D into a D app at run-time, the kind that can make api calls or extended main app with other functionality. I'm currently interested in it for a vibe.d app. How does these stuff work? It works using shared libraries. Oops
Re: D scripting in D
On Fri, 2017-06-02 at 02:39 +, Stefan Koch via Digitalmars-d-learn wrote: > […] > The D compiler is fast enough that it will not break your flow. > This argument may work for you but it definitely doesn't work for me. Using a language like Python, Groovy, Clojure, Lisp: 1. Edit 2. Run With D and Go, both of which claim compilation so fast you do not notice: 1. Edit 2. Compile 3. Run This is a 50% overhead (*). Even with LiteIDE and Gogland, you have the 3 stage sequence for Go programming, and it is a wee bit annoying. If and only if you have continuous compilation without manual intervention, does Stage 2 go away. As far as I am aware there is currently no continuous compilation framework for D. Now using inotify , it should be possible. However Meson/Ninja, CMake/Ninja, SCons, etc. do not support this out of the box. IntelliJ IDEA and CLion should be able to support this, but D support isn't yet there out of the box (**). (*) Clearly a fatuous number, but there is an election in UK, so fatuous statistics are order of the day. (**) IntelliJ-Dlanguage project could always do with more eople working on it. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Question on @nothrow
On Friday, 2 June 2017 at 07:33:05 UTC, Vasileios Anagnostopoulos
wrote:
On Thursday, 1 June 2017 at 17:03:52 UTC, Ali Çehreli wrote:
[...]
But still I believe that @nothrow should be mandatory if there
is no possibility for a function to throw something. I
understand that in the DLL/LIB level this is not possible.
However, at least in the .di level it should be there.
And if you want my two cents, after reading a lot I came to the
"personal" conclusion that Exception objects are wrong. For me
it is enough to have something like
void A() {
raise;
}
void B() {
raise;
}
void C() {
raise;
}
void D () nothrow { //the compiler inferred from body that D
cannever throw
scope(failure) {
writeln("The end of the world");
exit(1);
}
try {
A();
} else try {
B();
} else {
C();
}
}
Or simply
void A() {
raise;
}
void B() nothrow {
}
void D () nothrow { //the compiler inferred from body that D
cannever throw
try {
A();
} else {
B();
}
}
Re: Question on @nothrow
On Thursday, 1 June 2017 at 17:03:52 UTC, Ali Çehreli wrote:
On 06/01/2017 08:41 AM, Vasileios Anagnostopoulos wrote:
//If I do not know
void haveToCommunicateWithAli() {
sendEmailToAli();
}
//can blow-up after code has shipped
//and have no chance to recover
What shall I do in this case? Thank you in advance.
Vasileios
(Sorry if I go to too basic levels here.) I used to think that
an unhandled exception was a program crash. It's not. It's a
good thing that a program aborts due to an uhandled exception.
What happened is that it could not achieve it's task. There was
nothing else it could do, so it terminated. (For example, it
did not continue with unhealthy radiation levels on the
patient.)
Although an abort may be the safest thing to do in many cases,
it's not user-friendly. So, you catch the exception at the
highest level that it matters or that you can do something
about it. For example, you can catch the exception in main(),
report a friendly error, and return 1.
Or, you may be in a loop, preparing letters, you catch around
that code and either report an error or perhaps grab more
stamps and repeat the last operation.
So the answer is, don't catch exceptions any lower than it
really matters, which could be as high as the main() function.
Ali
But still I believe that @nothrow should be mandatory if there is
no possibility for a function to throw something. I understand
that in the DLL/LIB level this is not possible. However, at least
in the .di level it should be there.
And if you want my two cents, after reading a lot I came to the
"personal" conclusion that Exception objects are wrong. For me it
is enough to have something like
void A() {
raise;
}
void B() {
raise;
}
void C() {
raise;
}
void D () nothrow { //the compiler inferred from body that D
cannever throw
scope(failure) {
writeln("The end of the world");
exit(1);
}
try {
A();
} else try {
B();
} else {
C();
}
}
