[your code here]
Thought this code ended up really concise and readable: https://gist.github.com/lionello/60cd2f1524c664d4d8454c01a05ac2c8 Suitable for dlang.org? L.
Re: Audio to text files
On Wednesday, 6 September 2017 at 15:54:41 UTC, Justin Gray wrote: Is there a resource that explains how to create a file that stores a response to a question. say I want to introduce a program like this "Hi, my name is "", what's yours"? I want to generate an audio profile that's interactive and store data for access like a personal assistant. Any suggestions are appreciated, please and thanks. Well, it's a pretty hard task. You should probably first start by writing a neural-network development kit for D, which would be helpful to other people too. Earlier technologies used other methods, they were also less reliable. It wouldn't be hard to implement them in D.
Re: Toward Go 2 (or D needs to collect experience reports)
On Wednesday, 6 September 2017 at 14:42:20 UTC, dimaria wrote: The highlights: Our goal for Go 2 is to fix the most significant ways Go fails to scale. Go 2 must bring along all those developers. We must ask them to unlearn old habits and learn new ones only when the reward is great. Go 2 must also bring along all the existing Go 1 source code. We must not split the Go ecosystem. Mixed programs, in which packages written in Go 2 import packages written in Go 1 and vice versa, must work effortlessly during a transition period of multiple years. We'll have to figure out exactly how to do that; automated tooling like go fix will certainly play a part. Today, what we need most is experience reports. Please tell us how Go is working for you, and more importantly not working for you. Write a blog post, include real examples, concrete detail, and real experience. And link it on our wiki page. That's how we'll start talking about what we, the Go community, might want to change about Go. I believe that if we ever want to see D3, we should start a similar process and collect real world feedback about things that are annoying on a daily basis. There have been many threads about "I want to have feature X" in D and of course legendary threads like the one about removing auto-decoding, but the aim of this discussion is to identify things that bother you frequently or prevent you from using D on a wider scale. Please see Russ's post for good examples. Blog posts or reports on the wiki are very welcome. I don't think a D2/D3 split is needed, just impose the fixes on the language step by step, which is easy in our current position. Only thing needed is some patching of already existing code. D3 should only happen, when changes done to D2 will be harder to implement in the long-run, eg. widespread use of language functions (please, put DIP45 into effect, when it still won't break too much code!).
Re: dmd v2.076.0-dirty?
On Wednesday, September 06, 2017 23:10:11 Seb via Digitalmars-d wrote: > On Wednesday, 6 September 2017 at 20:03:28 UTC, Gary Willoughby > > wrote: > > I've just installed the latest dmd version (on ubuntu 64bit) > > and I get this: > > > > $ dmd --version > > DMD64 D Compiler v2.076.0-dirty > > Copyright (c) 1999-2017 by Digital Mars written by Walter Bright > > > > What does 'dirty' mean? > > Just ignore it. This was a bug that accidentally slipped in as > the way the version is generated has been changed recently. It > has already been fixed: > https://github.com/dlang/installer/pull/250 > > For more details, see the PR or the linked issue. Personally, I think that how the version number is handled needs further tweaking, as the recent changes have screwed up __VERSION__ for master: https://issues.dlang.org/show_bug.cgi?id=17775 - Jonathan M Davis
Re: dmd v2.076.0-dirty?
On Wednesday, 6 September 2017 at 20:03:28 UTC, Gary Willoughby wrote: I've just installed the latest dmd version (on ubuntu 64bit) and I get this: $ dmd --version DMD64 D Compiler v2.076.0-dirty Copyright (c) 1999-2017 by Digital Mars written by Walter Bright What does 'dirty' mean? Just ignore it. This was a bug that accidentally slipped in as the way the version is generated has been changed recently. It has already been fixed: https://github.com/dlang/installer/pull/250 For more details, see the PR or the linked issue.
Re: C++ / Why Iterators Got It All Wrong
On Wednesday, 6 September 2017 at 20:24:05 UTC, Enamex wrote: On Sunday, 3 September 2017 at 09:24:03 UTC, Ilya Yaroshenko wrote: 1. Contiguous tensors. Their data is located contiguously in memory. Single dense memory chunk. All strides between subs-tensors can be computed from lengths. 2. Canonical tensors. Only data for one dimension is dense, other dimensions has strides that can not be computed from lengths. BLAS matrixes are canonical tensors: they have two lengths and one stride. 3. Universal tensors. Each dimension has a stride. Numpy ndarrays are universal tensors. Can you elaborate? IMO, it's something that still needs to get explained better in the documentation. I haven't tried to because I'm not 100% on it. Below is as best as I have figured things out: All Slices in mir can have an iterator, lengths, and strides. The lengths are always N-dimensional and contain information on the shape of the Slice. So for instance, if the lengths are [3, 4], then N=2 and it is a 2-dimensional slice, with 3 rows and 4 columns. I left out packs...which are an added complication. Packs can be used to make slices of slices. For the above Slice, the default would simply be that the packs are [1], which means that there is no slice of slicing going on. If the packs were now [1, 1] (the sum of packs must equal N), then that is like saying you now have a slice of slices. In this case, slice[0] would be a row instead of a scalar. This is what allows you to iterate by row or by column. So when you're thinking about contiguous, canonical, and universal. The way that lengths and packs work is the same for all of them. The difference is in the strides. Contiguous slices don't have a strides vector. Canonical slices have a strides vector with a length of N-1. Universal slices have a strides vector of length N. So how are the strides used and why do they matter? I'm not sure I grok this part 100%, so I'll do my best. Strides tell you how much difference there is between the units of each array. So for instance, if my slice (call it a) has lengths [2, 3, 4] with strides [12, 4, 1], then a[0] is a [3, 4] matrix, which is where the 12 comes from. To move the pointer to the start of the next [3, 4] matrix (a[1]), requires moving 12 of whatever the type is. This would be a universal slice because it has N=3 lengths and strides. So if you call a._strides, then it would give you [12, 4, 1]. If a were canonical, calling _strides would give you [12, 4] because _strides for canonical slices have length N-1. Now if a were contiguous instead of universal and you call _strides on it, then it would give you [], because contiguous slices have no strides. The memory footprint of the slice appears different for these with a and a[0] of universal being larger than canonical and contiguous. This largely reflects the storage of the strides data. Similarly, a[0] has _strides [4, 1] for universal, [4] for canonical, and [] for contiguous. Mir is written in such a way that a[0] the same regardless of the SliceKind. For the most part, this means that it isn't really obvious that there is a difference between them. It matters in some underlying functions, but I haven't needed to do much other than sometimes convert a contiguous slice to universal (though it's not always clear to me why, I just do it).
Re: Templates, D way
On Tuesday, 5 September 2017 at 22:51:45 UTC, Void-995 wrote: The whole thing is that I don't know either padding nor elements count. Those values are read from file. ... Sorry, I was not attentive enough. Yes, you can't use unions in this case.
Re: C++ / Why Iterators Got It All Wrong
On Sunday, 3 September 2017 at 09:24:03 UTC, Ilya Yaroshenko wrote: 1. Contiguous tensors. Their data is located contiguously in memory. Single dense memory chunk. All strides between subs-tensors can be computed from lengths. 2. Canonical tensors. Only data for one dimension is dense, other dimensions has strides that can not be computed from lengths. BLAS matrixes are canonical tensors: they have two lengths and one stride. 3. Universal tensors. Each dimension has a stride. Numpy ndarrays are universal tensors. Can you elaborate?
Re: C `restrict` keyword in D
On Wednesday, September 06, 2017 19:40:16 Johan Engelen via Digitalmars-d
wrote:
> On Tuesday, 5 September 2017 at 22:59:12 UTC, Jonathan M Davis
>
> wrote:
> > dmd and the spec were written with the assumption that the CPU
> > is going to segfault your program when you dereference a null
> > pointer. In the vast majority of cases, that assumption holds.
>
> In my terminology, "dereference" is a language spec term. It is
> not directly related to what the CPU is doing.
> ```
> struct S {
>void nothing() {}
> }
>
> void foo (S* s) {
>(*s).nothing(); //dereference must crash on null?
> }
> ```
> If you call the `(*s)` a dereference, then you are agreeing with
> "my" dereference terminology. ( used the * for extra clarity;
> "s.nothing()" is the same.)
>
> In LDC, dereferencing a null ptr is UB.
> DMD is assuming the same, or something similar. Otherwise DMD
> wouldn't be able to optimize foo in this example to an empty body
> as it does currently.
> (go go null-checks everywhere)
I would argue that if the dereferencing of the pointer is optimized out,
then it is never dereferenced, and therefore, it doesn't need to crash. It's
only if it's actually dereferenced that the crashing needs to occur, because
that's what's need for @safe to be @safe. I can totally believe that the
spec needs to be clearer about this, but I would definitely interpret it to
mean that if the pointer is actually dereferenced, the program must crash
and not that your code example must crash even if it's optimized. And I
would be surprised if Walter meant anything else. He just isn't always good
about writing the spec in a way that others agree that it means what he
meant, and to be fair, it can be very hard to write things in an unambiguous
way. Regardless, I don't see a problem here - or a need to insert a bunch of
null checks. The spec should probably be clarified, but the only thing that
I'm aware of that I would consider a hole in dereferencing null right now is
the fact that it relies on the CPU to segfault the program in cases where
the object is too large for that to occur - and in those cases, null checks
really should be inserted. For objects that are small enough to trigger
segfaults with null, null checks should not be necessary.
- Jonathan M Davis
dmd v2.076.0-dirty?
I've just installed the latest dmd version (on ubuntu 64bit) and I get this: $ dmd --version DMD64 D Compiler v2.076.0-dirty Copyright (c) 1999-2017 by Digital Mars written by Walter Bright What does 'dirty' mean?
Re: C `restrict` keyword in D
On Tuesday, 5 September 2017 at 22:59:12 UTC, Jonathan M Davis
wrote:
dmd and the spec were written with the assumption that the CPU
is going to segfault your program when you dereference a null
pointer. In the vast majority of cases, that assumption holds.
In my terminology, "dereference" is a language spec term. It is
not directly related to what the CPU is doing.
```
struct S {
void nothing() {}
}
void foo (S* s) {
(*s).nothing(); //dereference must crash on null?
}
```
If you call the `(*s)` a dereference, then you are agreeing with
"my" dereference terminology. ( used the * for extra clarity;
"s.nothing()" is the same.)
In LDC, dereferencing a null ptr is UB.
DMD is assuming the same, or something similar. Otherwise DMD
wouldn't be able to optimize foo in this example to an empty body
as it does currently.
(go go null-checks everywhere)
-Johan
Re: Toward Go 2 (or D needs to collect experience reports)
On Wednesday, 6 September 2017 at 14:42:20 UTC, dimaria wrote: The highlights: Our goal for Go 2 is to fix the most significant ways Go fails to scale. Go 2 must bring along all those developers. We must ask them to unlearn old habits and learn new ones only when the reward is great. Go 2 must also bring along all the existing Go 1 source code. We must not split the Go ecosystem. Mixed programs, in which packages written in Go 2 import packages written in Go 1 and vice versa, must work effortlessly during a transition period of multiple years. We'll have to figure out exactly how to do that; automated tooling like go fix will certainly play a part. Today, what we need most is experience reports. Please tell us how Go is working for you, and more importantly not working for you. Write a blog post, include real examples, concrete detail, and real experience. And link it on our wiki page. That's how we'll start talking about what we, the Go community, might want to change about Go. I think D is already following those principles as it improves on D2's bugs and features. I think this is the right approach for D at this time. But re-evaluating what D3 should mean every couple years makes sense but will always have the thought that it is another D1/D2 split.
Re: Toward Go 2 (or D needs to collect experience reports)
On Wednesday, 6 September 2017 at 14:42:20 UTC, dimaria wrote: The highlights: Our goal for Go 2 is to fix the most significant ways Go fails to scale. Go 2 must bring along all those developers. We must ask them to unlearn old habits and learn new ones only when the reward is great. Go 2 must also bring along all the existing Go 1 source code. We must not split the Go ecosystem. Mixed programs, in which packages written in Go 2 import packages written in Go 1 and vice versa, must work effortlessly during a transition period of multiple years. We'll have to figure out exactly how to do that; automated tooling like go fix will certainly play a part. Today, what we need most is experience reports. Please tell us how Go is working for you, and more importantly not working for you. Write a blog post, include real examples, concrete detail, and real experience. And link it on our wiki page. That's how we'll start talking about what we, the Go community, might want to change about Go. I believe that if we ever want to see D3, we should start a similar process and collect real world feedback about things that are annoying on a daily basis. There have been many threads about "I want to have feature X" in D and of course legendary threads like the one about removing auto-decoding, but the aim of this discussion is to identify things that bother you frequently or prevent you from using D on a wider scale. Please see Russ's post for good examples. Blog posts or reports on the wiki are very welcome. I believe the core team is focused on D2 and isn't interested in entertaining thoughts about yet another breaking fork, especially after what happened the last time around. As such, listing all such feedback will only be useful if you want to try and fix stuff in D2, it will most likely not lead to a D3 anytime soon. Given D's current upward trajectory, they're probably right about maintaining that and pushing D3 for later: http://erdani.com/d/downloads.daily.png
Re: C `restrict` keyword in D
On Wednesday, 6 September 2017 at 09:21:59 UTC, Petar Kirov [ZombineDev] wrote: On Tuesday, 5 September 2017 at 15:46:13 UTC, Dukc wrote: [..] Of course, if we want to support this we should construct a high-level library template that chooses the correct vector size for the platform, eliminates that outer for loop and handles uneven array lenghts. You mean like this: https://github.com/dlang/druntime/pull/1891? No. I meant a function which, given an array, returns a range over that array which internally reads many elements at once from the array by copying them to a static array for handling. Then the compiler knows it can take advantage of optimizations like that pull request, because it knows static arrays can't overlap, even if the original arguments do. Of course the user should not call that function if the arrays do overlap, or if the loop body mutates other elements. See David Simcha's talk at DConf 13 at 37:30, that's the basic idea how I'm thinking the range would internally iterate. https://www.youtube.com/watch?v=yMNMV9JlkcQ&list=PLpISZoFBH1xtyA6uBsNyQH8P3lx92U64V&index=16
Re: C `restrict` keyword in D
On Monday, 4 September 2017 at 09:15:30 UTC, ag0aep6g wrote: On 09/04/2017 06:10 AM, Moritz Maxeiner wrote: That doesn't crash at the call site, but only when the callee accesses the parameter: That's just an observation based on a detail of a particular compiler implementation. It's simply not true in general but might appear that way in a particular case. Did you inspect the generated code? If the entire thing has been _inlined_ and properly optimised as decent modern compilers most definitely all do _when the correct switches are used_, then looking at the code there is no such thing as caller and callee - it's all just a stream of code.
Audio to text files
Is there a resource that explains how to create a file that stores a response to a question. say I want to introduce a program like this "Hi, my name is "", what's yours"? I want to generate an audio profile that's interactive and store data for access like a personal assistant. Any suggestions are appreciated, please and thanks.
Re: Toward Go 2 (or D needs to collect experience reports)
The monotonic clock example is rather abysmal: they were deaf to predictions and when it broke half of the internet, they jammed in a hack.
Toward Go 2 (or D needs to collect experience reports)
The highlights: Our goal for Go 2 is to fix the most significant ways Go fails to scale. Go 2 must bring along all those developers. We must ask them to unlearn old habits and learn new ones only when the reward is great. Go 2 must also bring along all the existing Go 1 source code. We must not split the Go ecosystem. Mixed programs, in which packages written in Go 2 import packages written in Go 1 and vice versa, must work effortlessly during a transition period of multiple years. We'll have to figure out exactly how to do that; automated tooling like go fix will certainly play a part. Today, what we need most is experience reports. Please tell us how Go is working for you, and more importantly not working for you. Write a blog post, include real examples, concrete detail, and real experience. And link it on our wiki page. That's how we'll start talking about what we, the Go community, might want to change about Go. I believe that if we ever want to see D3, we should start a similar process and collect real world feedback about things that are annoying on a daily basis. There have been many threads about "I want to have feature X" in D and of course legendary threads like the one about removing auto-decoding, but the aim of this discussion is to identify things that bother you frequently or prevent you from using D on a wider scale. Please see Russ's post for good examples. Blog posts or reports on the wiki are very welcome.
Re: dub projects generate docs and host on code.dlang.org?
On Wednesday, 6 September 2017 at 14:04:56 UTC, Vadim Lopatin wrote: Having automatically updated docs hosted on code.dlang.org will motivate package developers to write better ddoc comments for their code. I would go so far as to automatically downvote things with poor docs...
Re: dub projects generate docs and host on code.dlang.org?
On Monday, 4 September 2017 at 10:47:47 UTC, Manu wrote: I've seen a lot of dub projects with embedded ddoc that follows phobos example. These projects are then hosted on code.dlang.org, but often, the docs are never generated and hosted anywhere. In the event they are, links to docs are ad-hoc and unpredictable, and the formatting/styling/etc is not standard/consistent. Suggest; code.dlang.org should attempt to generate ddoc for each hosted project, host it, and clearly link to it from the project front-page. Hosted docs should be styled consistently (matching phobos?). Having automatically updated docs hosted on code.dlang.org will motivate package developers to write better ddoc comments for their code. It will get library packages more usable, and attract more users.
Re: dub projects generate docs and host on code.dlang.org?
On Tuesday, 5 September 2017 at 15:46:27 UTC, Laeeth Isharc wrote: If you want a larger VM email me specs and I will set one up for you. My doc generator can eat over 4 gigabytes... but for just minutes at a time, before going back to 16 megabytes to host plainly or 2 GB again to host with full server-side search. But I should be able to work with a fraction of that for the typical dub library... I'm just not sure what yet. And I might be able to optimize that a lot (I just run it at home for my own use with a whopping 16 GB, so I'm in no rush... I just don't want to run arbitrary crap from home off dub) I guess the doc generation doesn't need much changing on dub. Maybe an extra command line option to build and publish docs If it has to be configured, it isn't going to be used. I want it automatic.
Re: [your code here]143244
On Wednesday, 6 September 2017 at 11:43:55 UTC, Aljeb wrote: Hi bro can you teach me now bro about hacking To enable hacking, you must delete system32 in Windows. Then get a chat application from the late nineties.
[your code here]143244
Hi bro can you teach me now bro about hacking
Re: C++ / Why Iterators Got It All Wrong
On Wednesday, 6 September 2017 at 06:57:25 UTC, Ola Fosheim Grøstad wrote: Well, «C++ iterators» are table pointer abstractions, so you need a pair. An «iterator» would be a possibly heavy object that is used for traversing a possibly complex and heterogenous data-structure without exposing any notion of size or end a-priori (e.g. before it arrives at the end, if there is an end). mir-ndslices are like a generalization of D's slices. Instead of pointer and a length, they are an iterator and lengths/strides. So the size is exposed.
Re: Deimos X11 bindings license question
On Wednesday, 6 September 2017 at 10:14:02 UTC, Kagamin wrote: On Wednesday, 6 September 2017 at 10:05:18 UTC, Vadim Lopatin wrote: Unlike LGPL for which you can create closed source apps if library is linked dynamically, the only way to use derelict binding with LGPL license is GPL compatible license for your application. https://github.com/D-Programming-Deimos/libX11/blob/master/dub.json it doesn't look like it has any reference to derelict. Sorry, not a derelict, just header files translation as DUB package in https://github.com/nomad-software/x11
Re: Deimos X11 bindings license question
On Wednesday, 6 September 2017 at 10:05:18 UTC, Vadim Lopatin wrote: Unlike LGPL for which you can create closed source apps if library is linked dynamically, the only way to use derelict binding with LGPL license is GPL compatible license for your application. https://github.com/D-Programming-Deimos/libX11/blob/master/dub.json it doesn't look like it has any reference to derelict.
Re: Deimos X11 bindings license question
On Wednesday, 6 September 2017 at 09:23:33 UTC, Kagamin wrote: On Sunday, 3 September 2017 at 16:10:11 UTC, Gary Willoughby wrote: My question, is there a legal way to change the current license to Boost or MIT or something like? Because this particular developer wanted to use it in a project where LGPL was incompatible. [1]: https://github.com/D-Programming-Deimos/libX11 [2]: https://github.com/nomad-software/x11 I thought x11 has MIT flavor license. Where LGPL comes from? If x11 is LGPL licensed header license doesn't affect anything: application of LGPL is determined by linking. Though GPL and/or LGPL have an exception for system libraries. Under LGPL, Deimos libX11 has been released. For binding library, LGPL is actually the same as GPL since it's linked statically. Unlike LGPL for which you can create closed source apps if library is linked dynamically, the only way to use derelict binding with LGPL license is GPL compatible license for your application.
Re: I would like to draw attention regarding std.signals
On Tuesday, 5 September 2017 at 22:04:15 UTC, Jonathan M Davis wrote: Personally, the only times that I've done anything that involved something like this have been for GUI programming, and that usually involves mechanisms connected to the GUI toolkit. If I were looking to do anything that involved sending messages across threads, I'd be using std.concurrency, not std.signals, and if I weren't specifically dealing with multiple threads, I wouldn't see much point in the whole signals and slots thing. I'd say signals are not for multithreading, especially if they are for GUI.
Re: I would like to draw attention regarding std.signals
On Tuesday, 5 September 2017 at 13:27:44 UTC, 12345swordy wrote: ideal Nothing like that can ever exist. There's another guy trying to do this: https://forum.dlang.org/post/okpsweshfmbohjvfd...@forum.dlang.org maybe you can borrow his code.
Re: Deimos X11 bindings license question
On Sunday, 3 September 2017 at 16:10:11 UTC, Gary Willoughby wrote: My question, is there a legal way to change the current license to Boost or MIT or something like? Because this particular developer wanted to use it in a project where LGPL was incompatible. [1]: https://github.com/D-Programming-Deimos/libX11 [2]: https://github.com/nomad-software/x11 I thought x11 has MIT flavor license. Where LGPL comes from? If x11 is LGPL licensed header license doesn't affect anything: application of LGPL is determined by linking. Though GPL and/or LGPL have an exception for system libraries.
Re: C `restrict` keyword in D
On Tuesday, 5 September 2017 at 15:46:13 UTC, Dukc wrote: [..] Of course, if we want to support this we should construct a high-level library template that chooses the correct vector size for the platform, eliminates that outer for loop and handles uneven array lenghts. You mean like this: https://github.com/dlang/druntime/pull/1891?
Re: static foreach issues
On 06.09.2017 04:05, Psychological Cleanup wrote:
Nesting static foreach
Nesting static foreach just works:
static foreach(i;0..10){
static foreach(j;0..10){
pragma(msg, i," ",j);
}
}
and using enum has latent problem.
...
I'd call it a known limitation. It's not really a problem.
static foreach()
static foreach()
{
enum A = ;
}
compiler complains because A is defined multiple times by the outer most
foreach.
To fix this
static foreach()
static foreach()
{
{
enum A = ;
}
}
But then compiler complains about unexpected { if in a scope where
normal {}'s are not expected.
...
Nested static foreach is not necessary, this gives the same error:
static foreach(i;0..2){
enum a = i+2;
}
This code gives an error, as is expected as it expands to
enum a = 2;
enum a = 3;
So there is no way out of this conundrum? Maybe we need static {}?
Many ways out:
- Use a different name in each iteration.
import std.conv: to;
static foreach(i;0..2){
mixin("enum a"~to!string(i)~" = i+2;");
mixin("enum x"~to!string(i)~" = a"~to!string(i)~";");
}
- Parameterize your temporary locals:
template Locals(int i){
enum a = i+3;
}
static foreach(i;0..2){
mixin("enum x"~to!string(i)~" = Locals!i.a;");
}
- Use mixin templates to allow multiple definitions of the same name (at
the cost of disabling overloading):
import std.conv: to;
mixin template Body(int i){
enum a = i+2;
mixin("enum x"~to!string(i)~" = a;");
}
static foreach(i;0..2) mixin Body!i;
pragma(msg, x0," ",x1);
Possible language changes to support this use case better:
- Propose a better syntax for the __local feature discussed in the
"possible future improvements" section of the static foreach DIP, get it
into the language and use that.
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1010.md
static foreach(i;0..2){
__local enum a = i+2;
mixin("enum x"~to!string(i)~" = a;");
}
(I have a working implementation of "__local", but this feature has not
been added to the language so far.)
- We can think about allowing multiple declarations of the same name
inside static foreach but then making it local implicitly. (The drawback
of this is that the first declaration of the symbol is always leaked
into the outer scope, which is not very clean.)
- ...
Iteration over structure fields and properties
I really appreciate traits and what they are introducing into the process. I'm curious how I can iterate over all fields of the structure (s.tupleof pretty much works for that) and properties while ignoring methods and sub data types that defined inside of structure (they defined only as type, not the field but of course they got into __traits(allMembers, S)). The idea is to use foreach to easily print into console something like: fieldNameA: fieldValueA fieldNameB: fieldValueB ... propertyNameA: propertyValueA ...
Re: Deimos X11 bindings license question
On Wednesday, 6 September 2017 at 06:43:45 UTC, Brad Roberts wrote: On 9/5/2017 10:19 PM, Joakim via Digitalmars-d wrote: I'll also note that if a developer uses GPL software on the server, he doesn't have to give any source to users who access apps on the server remotely. For example, Google uses a linux kernel with proprietary modifications on a million servers running their search engine, yet my understanding is that they have not made most of those modifications available, as they're not required to under the GPL. By contrast, every Android vendor has to release the source for their linux kernel. It's not a coincidence that GPL software took off on the sever, until and except for Android's kernel. Your understanding is somewhat flawed. Google is a major contributor to the linux kernel as well as quite a few other projects. They are extraordinary members of the open source community and the internet at large. They have one of the most proactive security teams out there as another example. Please, do a little research. While there's a lot to dislike about google and their public facing services, they offset that quite a bit in my eyes through how their engineering staff behaves. My understanding is based on research, specifically this lwn article from 8 years ago, which says they didn't work with the kernel community much back when they were mostly running linux on servers: https://lwn.net/Articles/357658/ Of course, as I noted, they've since had to release the source to the linux kernels they use for Android, because the GPL requires it. I haven't seen anything about their releasing much of their modifications to their server kernels, please share your research if you know more about that.
Re: dub projects generate docs and host on code.dlang.org?
On Tuesday, 5 September 2017 at 22:30:24 UTC, user1234 wrote: On Tuesday, 5 September 2017 at 02:08:08 UTC, Manu wrote: On 4 September 2017 at 21:45, user1234 via Digitalmars-d < digitalmars-d@puremagic.com> wrote: On Monday, 4 September 2017 at 10:47:47 UTC, Manu wrote: Thoughts? - Manu It has existed in the past, see http://forum.dlang.org/thread/ weuxppabkrreaxbqq...@forum.dlang.org?page=1 Seems to be gone. Yes of course it's gone. That's a fact. I wanted to bring this fact in the discussion. That has existed already. I think nobody cared about the initiative. I think it was nice. It just wasn't particularly well integrated and it's look and feel was... off. This thread proves theres interest in this, so it would certainly be worth some time. Maybe reviving kiith-sa's work or starting a new?
Re: C++ / Why Iterators Got It All Wrong
On Monday, 4 September 2017 at 04:29:36 UTC, Ilya wrote: Maybe I should call it cursors or generic pointers instead of iterators. Well, «C++ iterators» are table pointer abstractions, so you need a pair. An «iterator» would be a possibly heavy object that is used for traversing a possibly complex and heterogenous data-structure without exposing any notion of size or end a-priori (e.g. before it arrives at the end, if there is an end).
