Re: [OT] Is this a feature is any Linux terminal?
On 10/14/18 10:28 PM, Basile B. wrote: VTE can certainly do this. It's the library many people use to embed a terminal in their app (or to make terminals, like Tilix). You can look at the API to get a better idea of what's possible https://developer.gnome.org/vte/0.48/VteTerminal.html. Click on message is certainly possible. I use VTE in Coedit but so far the only advanced feature is that it follows the projects path and/or the editor file path dynamically. Useful but far from what you describe, which is done elsewhere. I think that Konsole must be based on something similar to VTE (i.e a library) because the way it's integrated in Dolphin for example shows that it's not just a window that's hosted (it follows the path selected in the explorer... oh i remember where i stole the idea now...) Cool, I didn't know about VTE. On the desktop, I'm more KDE/Qt, but apparently, it seems Qt has an equivalent: qtermwidget. Don't know whether it supports the same thing though. Will have to look into it.
Re: You don't like GC? Do you?
On Sunday, 14 October 2018 at 07:51:09 UTC, Stanislav Blinov wrote: That's a lamest excuse if I ever seen one. If you can't be bothered to acquire one of the most relevant skills for writing code for modern systems, then: a) Ideally, you shouldn't be writing code b) At the very least, you're not qualified to give any advice pertaining to writing code PS. "Correctness" also includes correct use of the machine and it's resources. Ideally you wouldn’t have chosen to even try D. You (and others who spend so much time arguing against garbage collection on a forum for a language designed with garbage collection) would be better off using a non-garbage collected language.
How can I induce implicit type convesion with alias this on calling template function?
void func(T : int)(T value) if (is(T == int)) {
}
struct S {
int x;
alias x this;
}
void main() {
func(S()); // error
}
In above code, 'func' can accept only int as its argument type,
so when 'S', which can be implicitly convertible into int, is
passed on 'func', I expect S.x is passed, but this function call
is failed.
Is there any way to solve it with keeping 'func' template
function?
Re: Noob question about structs allocation
On Monday, 15 October 2018 at 03:33:04 UTC, Basile B. wrote:
On Monday, 15 October 2018 at 03:19:07 UTC, IM wrote:
I probably used to know the answer to this question, but it's
been a long time since I last used D, and I don't remember.
Suppose we have:
struct S {
int num;
}
Would allocating an instance on the heap using:
S* s = new S;
use the GC, or do we have to call destroy() or delete on s
ourselves?
new is an operator that always allocates using the GC,
calling destroy yourself won't hurt either but is not necessary.
What is the effect of calling destroy?
- calling the destructor?
- deallocating the memory?
- both?
Re: Noob question about structs allocation
On Monday, 15 October 2018 at 03:19:07 UTC, IM wrote:
I probably used to know the answer to this question, but it's
been a long time since I last used D, and I don't remember.
Suppose we have:
struct S {
int num;
}
Would allocating an instance on the heap using:
S* s = new S;
use the GC, or do we have to call destroy() or delete on s
ourselves?
new is an operator that always allocates using the GC,
calling destroy yourself won't hurt either but is not necessary.
Noob question about structs allocation
I probably used to know the answer to this question, but it's
been a long time since I last used D, and I don't remember.
Suppose we have:
struct S {
int num;
}
Would allocating an instance on the heap using:
S* s = new S;
use the GC, or do we have to call destroy() or delete on s
ourselves?
Re: [OT] Is this a feature is any Linux terminal?
On Sunday, 14 October 2018 at 23:28:04 UTC, Nick Sabalausky (Abscissa) wrote: But it just occurred to me: There's no reason any ordinary terminal emulator couldn't be written to do the same thing. A setting for a custom regex to look for, another setting for a command to run when the line is clicked on. That should be about it. The user's editor would have to support some kind of "editor --jump-to..." feature, but aside from that...well, why the heck not? The terminal emulator I've been using (Konsole) doesn't appear to have anything like that, AFAICT. But I'm not really married to Konsole. Anyone know of another terminal with a feature like this? Tilix supports this. You can define a custom regex and then use the values extracted by the regex to launch an editor to load the file at the right line number. https://gnunn1.github.io/tilix-web/manual/customlinks/ The screenshot shows a configuration that does this for gedit.
Re: [OT] Is this a feature is any Linux terminal?
On Sunday, 14 October 2018 at 23:28:04 UTC, Nick Sabalausky (Abscissa) wrote: Was just thinking about this: I've often liked the idea of having a terminal emulator built-into my code editor, so it could auto-highlight errors/etc and do jump-to-line on ANY variation of build command, without having to set up a custom build tool in the editor for "the is the exact command to build my project". (Yes, Iknow that full IDEs...and even many editors support jump-to-line, but they generally don't support running arbitrary modifications of commands without manually setting up ahead of time a very specific instance of a command). But it just occurred to me: There's no reason any ordinary terminal emulator couldn't be written to do the same thing. A setting for a custom regex to look for, another setting for a command to run when the line is clicked on. That should be about it. The user's editor would have to support some kind of "editor --jump-to..." feature, but aside from that...well, why the heck not? The terminal emulator I've been using (Konsole) doesn't appear to have anything like that, AFAICT. But I'm not really married to Konsole. Anyone know of another terminal with a feature like this? VTE can certainly do this. It's the library many people use to embed a terminal in their app (or to make terminals, like Tilix). You can look at the API to get a better idea of what's possible https://developer.gnome.org/vte/0.48/VteTerminal.html. Click on message is certainly possible. I use VTE in Coedit but so far the only advanced feature is that it follows the projects path and/or the editor file path dynamically. Useful but far from what you describe, which is done elsewhere. I think that Konsole must be based on something similar to VTE (i.e a library) because the way it's integrated in Dolphin for example shows that it's not just a window that's hosted (it follows the path selected in the explorer... oh i remember where i stole the idea now...)
[Issue 10692] Deprecation isn't checked using alias this
https://issues.dlang.org/show_bug.cgi?id=10692 Walter Bright changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #2 from Walter Bright --- Note that a plain 'alias' declaration specifically does not add modifiers, storage classes, attributes, etc. It's not a wrapper. It just forwards the lookup to the symbol. It should ignore any attributes, like plain alias does. Added a clarification to the spec: https://github.com/dlang/dlang.org/pull/2487 --
Re: Help about Template and class inheritance
On Sunday, 14 October 2018 at 15:06:49 UTC, Basile B. wrote:
The basic problem you're faced to here is that D class /
interface member functions that are templatized are never
virtual. I'm not sure if i understand well the JAVA pattern you
try to reproduce but since D interfaces can be templatized you
can do something like this, using variadics:
That's a good try. I want to have a try with template mixin.
About Java's pattern, see also:
https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/ExecutorService.html
The interface ExecutorService has many implements like
AbstractExecutorService, ForkJoinPool,
ScheduledThreadPoolExecutor, ThreadPoolExecutor etc.
The sample above is updated:
import std.stdio;
class Future(T)
{
T result;
this(T r) {
this.result = r;
}
}
interface IExecutorService {
// Future!(T) submit(T)(T result); // can't be implemented
}
abstract class ExecutorService : IExecutorService {
Future!(T) submit(T)(T result) {
return new Future!(T)(result);
}
}
class ThreadPoolExecutor : ExecutorService {
// alias submit = ExecutorService.submit;
// override Future!(T) submit(T)(T result) { // can't override it
// return new Future!(T)(result + 10);
// }
}
class ForkJoinPool : ExecutorService {
// alias submit = ExecutorService.submit;
// override Future!(T) submit(T)(T result) { // can't override it
// return new Future!(T)(result * 10);
// }
}
void testBase(ExecutorService service) {
writeln("testBase: ", typeid(service));
Future!(int) f = service.submit!int(12);
writeln(f.result);
}
void testInterface(IExecutorService service) {
writeln("testInterface: ", typeid(service));
writeln("testInterface: ", typeid(cast(Object)service));
// Future!(int) f = service.submit!int(12);
// writeln(f.result);
}
void main()
{
ThreadPoolExecutor threadPool = new ThreadPoolExecutor();
ForkJoinPool forkJoinPool = new ForkJoinPool();
testBase(threadPool);
writeln();
testBase(forkJoinPool);
writeln("\n");
testInterface(threadPool);
writeln();
testInterface(forkJoinPool);
}
Re: You don't like GC? Do you?
On Sunday, 14 October 2018 at 20:26:10 UTC, 12345swordy wrote: It not an excuse, it's reality. The d language have multiple issues, the idea to have the language to have built in support for GC is NOT one of them. Read this thread again then, carefully. You *have to* understand D's GC in order to use it correctly, efficiently, and safely. And to do that, you *have to* understand your data and what you're doing with it. And to do that you *have to* work with the machine, not in spite of it. At which point you may well reconsider using the GC in the first place. Or you may not. But at least that will be an informed decision based on actual value, not this "save time" fallacy. We develop our software using C# and the GC is a huge time saver for us as we are developing web apps. So you're in this for a quick buck, and to hell with everything else. Got it. And C#, so likely also everything is an "object", and screw the heap wholesale, right?.. Save time writing code, waste time processing data. Cool choice. I find your side remarks to be very arrogant and condescending. I'm arrogant, huh? It's people like you who think that "the" way to program is produce crappy code fast. It's so funny how all of you guys seem to think that I'm against the GC. I'm not. I'm against stupid "advice" like the one given in the OP. Almost all of you seem like you're in the same boat: you don't give a flying duck about your impact on the industry.
[OT] Is this a feature is any Linux terminal?
Was just thinking about this: I've often liked the idea of having a terminal emulator built-into my code editor, so it could auto-highlight errors/etc and do jump-to-line on ANY variation of build command, without having to set up a custom build tool in the editor for "the is the exact command to build my project". (Yes, Iknow that full IDEs...and even many editors support jump-to-line, but they generally don't support running arbitrary modifications of commands without manually setting up ahead of time a very specific instance of a command). But it just occurred to me: There's no reason any ordinary terminal emulator couldn't be written to do the same thing. A setting for a custom regex to look for, another setting for a command to run when the line is clicked on. That should be about it. The user's editor would have to support some kind of "editor --jump-to..." feature, but aside from that...well, why the heck not? The terminal emulator I've been using (Konsole) doesn't appear to have anything like that, AFAICT. But I'm not really married to Konsole. Anyone know of another terminal with a feature like this?
Re: A Friendly Challenge for D
On Sunday, 14 October 2018 at 10:51:11 UTC, Vijay Nayar wrote: But as previous posters have said, the code is not really very different between Nim and D. Most of it is array manipulation and arithmetic operations, and not many of the features of either D or Nim are very different. Both turn into fast code, both have garbage collection, and both have generally similar operators and libraries for this kind of problem. The biggest differences I observed revolved not around the languages themselves, but around code style. Are you aware of DCompute? [1] I haven’t used it myself but since Jabari explicitly mentioned taking advantage of the GPU, it may be worth giving it a try. It should have an impact on performance and possibly on style as well, even though it will still be D. It would be nice if Nicholas could chime in on this thread. Bastiaan. [1] https://dlang.org/blog/2017/10/30/d-compute-running-d-on-the-gpu/
Re: LDC 1.12.0
On Saturday, 13 October 2018 at 16:05:31 UTC, kinke wrote: * New, Easy::jit-like interface for dynamic/JIT compilation. I'm not familiar with Easy::jit. Would it make sense to do some kind of simple tutorial? Or maybe blog post?
[Issue 19306] New: Explicit struct constructors aren't smart when the structs contain anonymous unions
https://issues.dlang.org/show_bug.cgi?id=19306
Issue ID: 19306
Summary: Explicit struct constructors aren't smart when the
structs contain anonymous unions
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: b2.t...@gmx.com
struct Foo
{
union
{
void delegate() a;
void function() b;
}
ulong c;
}
void b(){}
struct A {void a(){}}
void main()
{
A a;
Foo f0 = Foo(); // ok
Foo f1 = Foo(, 0UL); // not allowed but should
Foo f2 = Foo(, 0UL); // not allowed but should
Foo f3 = Foo();// not allowed but should
}
--
Re: You don't like GC? Do you?
On Sunday, 14 October 2018 at 07:51:09 UTC, Stanislav Blinov wrote: On Saturday, 13 October 2018 at 21:44:45 UTC, 12345swordy wrote: Not everyone have the time nor skills of doing manual memory management. Even more so when correctness is way more important than speed. Not everything needs to be fast. That's a lamest excuse if I ever seen one. It not an excuse, it's reality. The d language have multiple issues, the idea to have the language to have built in support for GC is NOT one of them. We develop our software using C# and the GC is a huge time saver for us as we are developing web apps. I find your side remarks to be very arrogant and condescending.
Re: Spasm - webassembly libary for single page applications
On Sunday, 14 October 2018 at 06:03:10 UTC, Bogdan wrote: Awesome work! I remember that, at some point the https://glimmerjs.com/ authors wanted to write their vm in rust for better performance. It looks like D is a new option for such projects. Bogdan Thanks, a lot of credits go to LDC for supporting the webassembly backend of LLVM. I thought about doing a VM as well, specifically because I was afraid of the performance penalty of switching a lot between js and wasm. The idea was to emit all dom operations into one bytebuffer (possibly at compile-time) and then instruct js to execute that. It turns out jumping between wasm and js isn't really a big deal (at least not anymore), so I ditched that idea to keep things simple. Plus, there is a good chance that in the near future wasm will be able to call the browsers' api directly.
Re: LDC2 compiling executable requiring elevated privileges?
On Sunday, 14 October 2018 at 15:46:57 UTC, Laurent Tréguier wrote: Why should an OS decide whether an executable should be run with admin privileges ? If it has to, then it's up to the developer to explicitly ask for it... Windows supports programs written as much as 30 years ago. The developer might not even be around anymore, yet they try to keep the program working. Sometimes that means some weird hacks in the OS. It is really good for the end user.
Re: fork vs. posix_spawn (vfork)
On Sunday, 14 October 2018 at 11:36:28 UTC, notna wrote: Hi D gurus. Did read an interesting post form GitLab [1] how they improved performance by 30x by just going to go_v1.9... because they again went from "fork" to "posix_spawn"... [1] https://about.gitlab.com/2018/01/23/how-a-fix-in-go-19-sped-up-our-gitaly-service-by-30x/ Hi notna, Thanks for the interesting article. I've searched the GitHub DLANG org for "posix_spawn" and didn't find a hit... Indeed currently (as of DMD 2.082.1) druntime does not include bindings of posix_spawn [1]. The nice thing about D is that if you need to use a C function that's not yet declared in druntime it's very easy to add the declaration to your app and use it. I looked at glibc's implementation and translated the declarations. You can find them along with the example from the man page here: https://run.dlang.io/gist/ZombineDev/536eb8b456cc365b7ee05133ec452627?compiler=dmd (if you want to use posix_spawn in your app/library copy the code from line 133 till the end of the file). so asking myself and you is DLANG still on "fork" and could there be some performance improvement potential? One cannot say whether D is "on fork" or not because unlike Go, everyone is free to use whatever system function they need, without explicit cooperation from upstream. Though probably many apps or libraries use the high-level functions declared in https://dlang.org/phobos/std_process instead of using the low-level system functions directly. In particular, spawnProcess [2] is currently implemented via fork/exec. I found an open issue about optimizing std.process: https://issues.dlang.org/show_bug.cgi?id=14770. I'll look into making a pull request to druntime about posix_spawn, though no promises for phobos, as there the code is a bit more involved and would need more careful analysis. [1]: http://man7.org/linux/man-pages/man3/posix_spawn.3.html [2]: https://dlang.org/phobos/std_process#.spawnProcess
Re: Is there an efficient byte buffer queue?
On Monday, 8 October 2018 at 09:39:55 UTC, John Burton wrote: I would do much better to maintain a fixed size buffer and maintain read and write positions etc. Perhaps https://github.com/AuburnSounds/Dplug/blob/master/core/dplug/core/ringbuf.d#L16
Re: LDC2 compiling executable requiring elevated privileges?
On Sunday, 14 October 2018 at 13:20:09 UTC, Adam D. Ruppe wrote: On Sunday, 14 October 2018 at 12:16:28 UTC, spikespaz wrote: I'm compiling an executable that does not need administrator privileges. For some reason though, LDC thinks it does and marks it as elevated. This has nothing to do with ldc. It is just any 32 bit program called setup.exe or install.exe is assumed to be an installer by Windows, and thus triggers UAC unless you specifically tell it not to. More info (including how to override this default behavior): https://stackoverflow.com/questions/20096706/how-does-windows-decide-whether-to-display-the-uac-prompt Easiest way, of course, is to just not call it setup.exe This automation drove me crazy. I changed the name from "install" to "bootstrap" to solve it when I faced this problem. Why should an OS decide whether an executable should be run with admin privileges ? If it has to, then it's up to the developer to explicitly ask for it...
Re: Passing $ as a function argument
On Sunday, 14 October 2018 at 14:35:36 UTC, lngns wrote:
On Sunday, 14 October 2018 at 13:18:37 UTC, lngns wrote:
That would require introducing a new type
Or just use int with a negative number... That's how it's done
in some dynamic languages.
But my point is that it should be compatible with pre-existing
code using unsigned indices somehow. I don't think that is
possible.
Another way to do this with UFCS:
// write-once library wrapper
struct Indexer(R) {
R r;
auto opDollar() { return r.length; }
auto opIndex(size_t i) { return r[i]; }
}
auto indexer(R)(R r) { return Indexer(r); }
// rewrite index parameter => return wrapped range
auto foo()
{
auto arr = (...);
return indexer(arr);
}
// easy-to-use result
auto end = foo[$-1];
Re: Help about Template and class inheritance
On Sunday, 14 October 2018 at 13:21:00 UTC, Heromyth wrote:
Here is a sample code
```d
import std.stdio;
class Future(T)
{
T result;
this(T r) {
this.result = r;
}
}
interface IExecutorService {
// Future!(T) submit(T)(T result); // can't be implemented
}
abstract class ExecutorService : IExecutorService {
Future!(T) submit(T)(T result) {
return new Future!(T)(result);
}
}
class ThreadPoolExecutor : ExecutorService {
// alias submit = ExecutorService.submit;
// override Future!(T) submit(T)(T result) { // can't override
it
// return new Future!(T)(result + 10);
// }
}
void main()
{
ThreadPoolExecutor service = new ThreadPoolExecutor();
ExecutorService serviceBase = service;
IExecutorService serviceInterface = service;
Future!(int) f = service.submit!int(12);
writeln(f.result);
f = serviceBase.submit!int(12);
writeln(f.result);
// f = serviceInterface.submit!int(12);
// writeln(f.result);
}
```
The **submit** can't be defined in D as done in Java. See also
(search for exchangeMessageVectorsAsync):
https://www.programcreek.com/java-api-examples/?code=aarmea/noise/noise-master/app/src/main/java/com/alternativeinfrastructures/noise/sync/StreamSync.java
So, is there a better way to do this in D?
Any suggestions are welcome.
Thanks.
The basic problem you're faced to here is that D class /
interface member functions that are templatized are never
virtual. I'm not sure if i understand well the JAVA pattern you
try to reproduce but since D interfaces can be templatized you
can do something like this, using variadics:
import std.stdio;
class Future(T)
{
T result;
this(T r) {
this.result = r;
}
}
interface IExecutorService(Ts...) {
static foreach(T; Ts)
Future!T submit(T result);
}
abstract class ExecutorService(Ts...) : IExecutorService!Ts {
static foreach(T; Ts)
Future!T submit(T result) {
return new Future!(T)(result);
}
}
class ThreadPoolExecutor : ExecutorService!int {
override Future!int submit(int result) {
return new Future!int(result + 10);
}
}
void main()
{
ThreadPoolExecutor service = new ThreadPoolExecutor();
ExecutorService!int serviceBase = service;
IExecutorService!int serviceInterface = service;
Future!(int) f = service.submit(12);
writeln(f.result);
f = serviceBase.submit(12);
writeln(f.result);
f = serviceInterface.submit(12);
writeln(f.result);
}
so that you can submit and have Future for several types.
[Issue 11320] std.math.fmod, round, trunc are not yet pure
https://issues.dlang.org/show_bug.cgi?id=11320 Simon Naarmann changed: What|Removed |Added Assignee|nob...@puremagic.com|eiderd...@gmail.com --
[Issue 11320] std.math.fmod, round, trunc are not yet pure
https://issues.dlang.org/show_bug.cgi?id=11320 Simon Naarmann changed: What|Removed |Added CC||eiderd...@gmail.com --- Comment #2 from Simon Naarmann --- This issue is still in 2.082.0. Are there technical problems (floating representation etc.) that require impurity? Otherwise, I'll make a PR that adds the pure keyword. --
Re: Passing $ as a function argument
On Sunday, 14 October 2018 at 13:18:37 UTC, lngns wrote: That would require introducing a new type Or just use int with a negative number... That's how it's done in some dynamic languages. But my point is that it should be compatible with pre-existing code using unsigned indices somehow. I don't think that is possible.
Help about Template and class inheritance
Here is a sample code
```d
import std.stdio;
class Future(T)
{
T result;
this(T r) {
this.result = r;
}
}
interface IExecutorService {
// Future!(T) submit(T)(T result); // can't be implemented
}
abstract class ExecutorService : IExecutorService {
Future!(T) submit(T)(T result) {
return new Future!(T)(result);
}
}
class ThreadPoolExecutor : ExecutorService {
// alias submit = ExecutorService.submit;
// override Future!(T) submit(T)(T result) { // can't override it
// return new Future!(T)(result + 10);
// }
}
void main()
{
ThreadPoolExecutor service = new ThreadPoolExecutor();
ExecutorService serviceBase = service;
IExecutorService serviceInterface = service;
Future!(int) f = service.submit!int(12);
writeln(f.result);
f = serviceBase.submit!int(12);
writeln(f.result);
// f = serviceInterface.submit!int(12);
// writeln(f.result);
}
```
The **submit** can't be defined in D as done in Java. See also
(search for exchangeMessageVectorsAsync):
https://www.programcreek.com/java-api-examples/?code=aarmea/noise/noise-master/app/src/main/java/com/alternativeinfrastructures/noise/sync/StreamSync.java
So, is there a better way to do this in D?
Any suggestions are welcome.
Thanks.
Re: LDC2 compiling executable requiring elevated privileges?
On Sunday, 14 October 2018 at 12:16:28 UTC, spikespaz wrote: I'm compiling an executable that does not need administrator privileges. For some reason though, LDC thinks it does and marks it as elevated. This has nothing to do with ldc. It is just any 32 bit program called setup.exe or install.exe is assumed to be an installer by Windows, and thus triggers UAC unless you specifically tell it not to. More info (including how to override this default behavior): https://stackoverflow.com/questions/20096706/how-does-windows-decide-whether-to-display-the-uac-prompt Easiest way, of course, is to just not call it setup.exe
Re: Passing $ as a function argument
On Wednesday, 10 October 2018 at 13:32:15 UTC, Simen Kjærås wrote:
struct Sentinel {}
Sentinel $;
void foo(T)(T loc) {
auto bar = double[RandomPInt+1];
static if (is(T == Sentinel)) {
return bar[$];
} else {
return bar[loc];
}
}
unittest {
foo($);
}
It looks to me OP is proposing exactly this, but wants the
subscript expression to support it.
That would require introducing a new type or changing size_t, so
that both integer indices and the sentinel can be passed around.
Present-day size_t is unsigned, so we can't use negative values
to represent it.
I guess it could be useful when you are manipulating multiple
arrays at the same time in a functional fashion and need the
upper bound of all of them at one point, which could be different.
Re: Is there an efficient byte buffer queue?
On Monday, 8 October 2018 at 09:39:55 UTC, John Burton wrote: My use case is sending data to a socket. We have ported some containers from JAVA. ByteBuffer is a basic container interface and widely used in JAVA. See also: https://github.com/huntlabs/hunt/blob/master/source/hunt/container/ByteBuffer.d https://github.com/huntlabs/hunt/tree/master/examples/ContainerDemo/source
LDC2 compiling executable requiring elevated privileges?
I'm compiling an executable that does not need administrator privileges. For some reason though, LDC thinks it does and marks it as elevated. = ldc2 source\setup.d -i -I source -J build\vars -of build\bin\setup.exe -m32 -g = No clue why, but what can I do about that? I'm thinking maybe it's because I'm importing "std.windows.registry". But even then, I'm only writing to "HKEY_CURRENT_USER", so no elevation should be required. This is the source. https://github.com/spikespaz/search-deflector/blob/master/source/setup.d
Question about D hirearchy and include directory
Dear,
Some projects seem to have an extra directory for their include
directory, such as:
- stdx-allocator
- containers
- msgpack
- dparse
...
To draw the picture, I take as example the containers project and
build using meson:
$ ls /usr/include/d/containers/containers/
cyclicbuffer.d dynamicarray.d hashmap.d hashset.d
immutablehashset.d internal openhashset.d package.d simdset.d
slist.d treemap.d ttree.d unrolledlist.d
Why it is not : /usr/include/d/containers
Or why for (phobos/std) it is not /usr/include/d/std/std
Is it the expected behaviour or these meson.build should be fixed:
Example at line 94
https://github.com/dlang-community/containers/blob/master/meson.build#L94
replace:
install_subdir('src/containers/', install_dir:
'include/d/containers/')
to:
install_subdir('src/containers/', install_dir: 'include/d/')
Thanks
Have a good day
Re: custom sorting of lists ?
On Sunday, 14 October 2018 at 01:31:26 UTC, Jonathan M Davis wrote: Unless there's something about the implementation that's tied to the list itself, I would think that it would make more sense to make it a generic algorithm, then it will work with any non-random-access range, and it avoids needing to reimplement it for similar circumstances. IMHO, it really only makes sense to tie it to the container if the implementation itself needs to be for some reason. - Jonathan M Davis All operations on collections are tied to implementation. Phobos just intorduced range abstraction that hides iteration code (and is still implemented by collection itself). Iteration is only a small part of functionality that one expects from the data structure. I'm against operation generalization, collections have little in common besides basic semantics of insertion, they should provide their own methods. It is the lack of such methods that is more disheartening. And the lack of cursor\iterator concept, wich maps well to mutation semantics of lists\trees.
fork vs. posix_spawn (vfork)
Hi D gurus. Did read an interesting post form GitLab [1] how they improved performance by 30x by just going to go_v1.9... because they again went from "fork" to "posix_spawn"... I've searched the GitHub DLANG org for "posix_spawn" and didn't find a hit... so asking myself and you is DLANG still on "fork" and could there be some performance improvement potential? [1] https://about.gitlab.com/2018/01/23/how-a-fix-in-go-19-sped-up-our-gitaly-service-by-30x/
Re: A Friendly Challenge for D
On Saturday, 13 October 2018 at 19:04:48 UTC, Jabari Zakiya wrote: On Saturday, 13 October 2018 at 18:31:57 UTC, Vijay Nayar wrote: On Saturday, 13 October 2018 at 18:14:20 UTC, Vijay Nayar wrote: On Saturday, 13 October 2018 at 18:05:45 UTC, Jabari Zakiya wrote: It may be also running into a hard time limit imposed on compilation that Nim had/has that prevented my code from initially compiling. I'm generating a lot of PG parameter constants at compile time, and it's doing a lot of number crunching and building larger and larger arrays of constants as the PG's get larger. Try compiling with successive PG's (just P5, then P5 and P7, etc) to see where it fails. That will let you know the code is working correctly, and that the compiler is choking either/and because of a hard time limit and/or memory limit. That's why I put in a compiler output statement in 'genPGparameters' to see the progression of the PG parameters being built by the compiler to initially find when the compiler started choking. You may also need to patch whatever facility in the D compiler chain that controls this too. It's P17, the biggest one that takes the longest to build in the Nim version. I actually don't know what memory limits exist for the D compiler at compile-time, so I may need to do some homework. It's not just DMD either. $ ldc2 twinprimes_ssoz.d ... generating parameters for P17 Killed $ gdc twinprimes_ssoz.d ... generating parameters for P17 gdc: internal compiler error: Killed (program cc1d) Please submit a full bug report, with preprocessed source if appropriate. See for instructions. $ dmd twinprimes_ssoz.d ... generating parameters for P17 Killed In the Nim code, starting line 91 is when the PG constants are being generate at compile time. - # Generate at compile time the parameters for PGs P5-P17. const parametersp5 = genPGparameters(5) const parametersp7 = genPGparameters(7) const parametersp11 = genPGparameters(11) const parametersp13 = genPGparameters(13) const parametersp17 = genPGparameters(17) - Can it compile just using P5 (the first line, others commented out), and then P7, etc? I'm not understanding your comments now. If you can get a working version up and running (with correct output) we can solve the P17 compiler issues later (or in a parallel forum thread), especially if you have to delve into the weeds of the compiler chain. In my mind (same with Nim process) getting working code using any PG is first order priority (because you'll need getting multi-threading working too). Once you can do that, by default, you can then use any generator you want if you create the correct parameters for it. That's one of the advantages of the algorithm, it's PG agnostic (as long as your hardware will accommodate it). So don't prioritize getting P17 to compile right now (in this thread). Create the working generic structure that can work with any PG first. Updated: https://gist.github.com/vnayar/79e2d0a9850833b8859dd9f08997b4d7 I still get a few runtime errors likely from mistakes in my conversion for certain primes. I'll resolve those after I get back from the gym. But as previous posters have said, the code is not really very different between Nim and D. Most of it is array manipulation and arithmetic operations, and not many of the features of either D or Nim are very different. Both turn into fast code, both have garbage collection, and both have generally similar operators and libraries for this kind of problem. The biggest differences I observed revolved not around the languages themselves, but around code style. For example, can you put a loop and 3 additional statements on a single line in D? Yes. But it is considered to be not very readable code from a style perspective. Once I get the bugs out, I'm curious to see if any performance differences crop up. There's the theory that says they should be the same, and then there's the practice.
Re: std.regex is fat
On Sunday, 14 October 2018 at 03:26:33 UTC, Adam D. Ruppe wrote: On Sunday, 14 October 2018 at 03:07:59 UTC, Chris Katko wrote: For comparison, I just tested and grep uses about 4 MB of RAM to run. Running and compiling are two entirely different things. Running the D regex code should be comparable, but compiling it is slow, in great part because of internal templates... There was an effort to speed up the template code, but it is still not complete. I know that. I figured people would miss my point on it though so I should have clarified. That's why I said it's likely the templates/DMD that's exploding--not the actual regex action. From a simple program, it takes ~100-150MB of RAM to compile. Adding a single regex (not compiled regex) balloons to 550MB at 5 seconds of compile time. --- Anyhow, I wrote my own simple "dgrep" and compared the results with grep, it's very competitive: (NOT to be confused with the above RAM stats for COMPILING) Command being timed: "sh -c cat dgrep.d | ./dgrep 'write' " User time (seconds): 0.00 System time (seconds): 0.00 Percent of CPU this job got: 0% Elapsed (wall clock) time (h:mm:ss or m:ss): 0:00.00 Average shared text size (kbytes): 0 Average unshared data size (kbytes): 0 Average stack size (kbytes): 0 Average total size (kbytes): 0 Maximum resident set size (kbytes): 3192 Average resident set size (kbytes): 0 Major (requiring I/O) page faults: 0 Minor (reclaiming a frame) page faults: 301 Voluntary context switches: 5 Involuntary context switches: 124 Swaps: 0 File system inputs: 8 File system outputs: 8 Socket messages sent: 0 Socket messages received: 0 Signals delivered: 0 Page size (bytes): 4096 Exit status: 0 Command being timed: "sh -c cat dgrep.d | grep 'write'" User time (seconds): 0.00 System time (seconds): 0.00 Percent of CPU this job got: 0% Elapsed (wall clock) time (h:mm:ss or m:ss): 0:00.00 Average shared text size (kbytes): 0 Average unshared data size (kbytes): 0 Average stack size (kbytes): 0 Average total size (kbytes): 0 Maximum resident set size (kbytes): 2224 Average resident set size (kbytes): 0 Major (requiring I/O) page faults: 2 Minor (reclaiming a frame) page faults: 282 Voluntary context switches: 10 Involuntary context switches: 0 Swaps: 0 File system inputs: 760 File system outputs: 0 Socket messages sent: 0 Socket messages received: 0 Signals delivered: 0 Page size (bytes): 4096 Exit status: 0 So I have to say I'm impressed with the actual performance of the regular expressions engine--especially considering "grep" is, IIRC, considered a fine-tuned beast.
Re: custom sorting of lists ?
On Sunday, 14 October 2018 at 01:31:26 UTC, Jonathan M Davis wrote: Unless there's something about the implementation that's tied to the list itself, I would think that it would make more sense to make it a generic algorithm, then it will work with any non-random-access range, and it avoids needing to reimplement it for similar circumstances. IMHO, it really only makes sense to tie it to the container if the implementation itself needs to be for some reason. - Jonathan M Davis I'm currently using this... https://dpaste.dzfl.pl/09ea7fa8c58c you can delete/insert from anywhere in the list, sort it, and even produce an array from it...
[Issue 13825] relativePath not handling "." and ".." correctly
https://issues.dlang.org/show_bug.cgi?id=13825 --- Comment #3 from Dechcaudron --- Okay, so I've been mulling on it for the last day. Before I move in to make any changes, here are some questions I'd like to get some discussion going around: 1) Does it make sense that the first argument to the `relativePath` and `asRelativePath` functions can be already relative? Personally I find that to be a bad idea, but you may have a valid counterpoint (please, provide use case). 2) Currently, the "second argument must be an absolute path" claim is exposed in the functions' documentation, and only in `relativePath` is it enforced via throwing an exception (`asRelativePath` merely assumes so). Regardless of the outcome of question 1), would if make sense to remove the exception from `relativePath` and add a check for `isAbsolute(path)` as an input contract? I understand this is a breaking change, so please see 4). 3) The root cause of this issue does not seem to be other than the arguments not being normalized. As the reporter stated, calling `buildNormalizedPath` on both arguments fixes the issue (bar for the first argument starting with "../", see 1)). A quick and dirty fix would be to naively call such function on the arguments within both `relativePath` and `asRelativePath`, but that would be wasteful if the paths are already normalized. It makes sense to me that we add a contract on both input arguments to require they are normalized. As of today, we do not have any `isNormalized` function, but it could be added. Would that make sense? Again, breaking changes, please see 4). 4) Since 2) and 3) both imply breaking changes in the behavior of the function (or rather, as I am suggesting, the ability to terminate the program via `assert` when the arguments violate the stated requirements) I understand the way to go would be to begin a deprecation process. Since the signature of the function does not need to change, the process is not as straightforward as I'd like. I would propose the following: 1. Create the `relativePath(bool useContracts, CaseSensitive cs = CaseSensitive.osDefault)` template, which `static if`s `useContracts` to determine whether to define the `relativePath` function with the new behavior if true, or to define the deprecated function with the legacy behavior if false. The legacy function would call the template function with `false`, to trigger the deprecation warning. Proceed the same way with `asRelativePath`. 2. Once the deprecation period expires, move the definition of the new behavior with contracts to the legacy function declaration, deprecate the `useContracts = true` declaration (which by then would forward to the legacy signature function) and remove the `useContracts = false` declaration. 3. Once the deprecation period for the template expires, remove it and keep the legacy signature function with contracts. 4. My grand-grandkids will close the issue. Thoughts? --
ACCU 2019 Call for Propoals is Open
ACCU has traditionally had a big chunk of C++ content but is is fact a conference on programming. Go, Kotlin, and Rust have maintained a position in the programme. Yet D, which is supposed to be the replacement for C++, has been noticeable by it's absence from the programme. Will 2019 and 2020 be the years when D comes to ACCU to show the C++ folk what they are missing? And perhaps show the Go and Rust folk that there are things they are missing? Call is open for two more weeks. https://cfp.conference.accu.org -- 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: You don't like GC? Do you?
On Saturday, 13 October 2018 at 21:44:45 UTC, 12345swordy wrote: Not everyone have the time nor skills of doing manual memory management. Even more so when correctness is way more important than speed. Not everything needs to be fast. That's a lamest excuse if I ever seen one. If you can't be bothered to acquire one of the most relevant skills for writing code for modern systems, then: a) Ideally, you shouldn't be writing code b) At the very least, you're not qualified to give any advice pertaining to writing code PS. "Correctness" also includes correct use of the machine and it's resources.
Re: Spasm - webassembly libary for single page applications
On Friday, 12 October 2018 at 19:43:25 UTC, Sebastiaan Koppe wrote: I like to announce Spasm https://github.com/skoppe/spasm It is a webassembly library to develop single page applications and builds on my previous work (https://forum.dlang.org/post/eqneqstmwfzugymfe...@forum.dlang.org). It generates fast and small webassembly binaries. The example todo-mvc is only 5995 bytes (wasm) + 2199 bytes (html+js) when gzipped, and loads pretty fast (https://skoppe.github.io/spasm/examples/todo-mvc/) Spasm can be used with dub and only requires a recent version of ldc. See the readme on github how to get started. The library includes a webpack bootstrap project to build a production ready web page. Spasm is written in betterC. Next steps are: - more js host bindings (xhr, localstorage, etc.) - memory deallocation - gather an angry mob to make phobos more betterC compatible ;) Awesome work! I remember that, at some point the https://glimmerjs.com/ authors wanted to write their vm in rust for better performance. It looks like D is a new option for such projects. Bogdan
