On 09/09/2018 5:43 PM, Paul Backus wrote:
On Sunday, 9 September 2018 at 04:37:48 UTC, Josphe Brigmo wrote:
If git would automatically do the dates then one could download the
source code. Git would be the central repository and if one wanted an
offline version that had enough info in it such
On Sunday, 9 September 2018 at 04:37:48 UTC, Josphe Brigmo wrote:
If git would automatically do the dates then one could download
the source code. Git would be the central repository and if one
wanted an offline version that had enough info in it such as
the data a change was made, who changed
On Sunday, 9 September 2018 at 03:02:41 UTC, tide wrote:
Oh another one from 2008, 10 years ago.
https://issues.dlang.org/show_bug.cgi?id=1870
Oh hey, a wild me appears.
So, yeah, the tricky bit with this is where to emit the source
code.
If you just want a best-effort aid, you could
On Sunday, 9 September 2018 at 04:53:05 UTC, Nicholas Wilson
wrote:
On Sunday, 9 September 2018 at 04:01:30 UTC, Nicholas Wilson
wrote:
On windows with dub it seems to be creating libfoo.a instead
of foo.lib, I don't think I changed any settings. Old build
based on 2.078 DMDFE seem to have
On Sunday, 9 September 2018 at 02:48:40 UTC, Neia Neutuladh wrote:
On Sunday, 9 September 2018 at 01:27:06 UTC, Josphe Brigmo
wrote:
How hard would it be to automate dating for dmd source so that
everything is consistent in a way that makes sense?
Perhaps you could find out by trying to
On Sunday, 9 September 2018 at 04:01:30 UTC, Nicholas Wilson
wrote:
On windows with dub it seems to be creating libfoo.a instead of
foo.lib, I don't think I changed any settings. Old build based
on 2.078 DMDFE seem to have built .lib but LDC based on 2.082
seems to be building .a
This
On Sunday, 9 September 2018 at 02:49:45 UTC, Walter Bright wrote:
On 9/8/2018 4:29 AM, Josphe Brigmo wrote:
Um, I didn't say don't use Git!
I've done this manually before git. I can guarantee you that
the dates put in the file are invariably wrong, incomplete, or
non-existent.
But if you
On Sunday, 9 September 2018 at 03:33:49 UTC, Vladimir Panteleev
wrote:
On Saturday, 8 September 2018 at 04:24:20 UTC, Jonathan Marler
wrote:
I've rewritten rdmd into a new tool called "rund" and have
been using it for about 4 months. It runs about twice as fast
making my workflow much
On windows with dub it seems to be creating libfoo.a instead of
foo.lib, I don't think I changed any settings. Old build based on
2.078 DMDFE seem to have built .lib but LDC based on 2.082 seems
to be building .a
On Saturday, 8 September 2018 at 04:24:20 UTC, Jonathan Marler
wrote:
I've rewritten rdmd into a new tool called "rund" and have been
using it for about 4 months. It runs about twice as fast making
my workflow much "snappier". It also introduces a new feature
called "source directives" where
On Sunday, 9 September 2018 at 00:58:15 UTC, Nicholas Wilson
wrote:
Obligatory "Bugzilla issue?".
Obligatory "it already exists and has exited for X amount of
years" (4 in this case).
https://issues.dlang.org/show_bug.cgi?id=12790
As with most issues in bugzilla, no one has so much as made
On Sunday, 9 September 2018 at 01:27:06 UTC, Josphe Brigmo wrote:
How hard would it be to automate dating for dmd source so that
everything is consistent in a way that makes sense?
Perhaps you could find out by trying to implement such a system?
That's what I usually do.
You haven't
On 9/8/2018 4:29 AM, Josphe Brigmo wrote:
Um, I didn't say don't use Git!
I've done this manually before git. I can guarantee you that the dates put in
the file are invariably wrong, incomplete, or non-existent.
But if you bring up a source file in github, and click on the "Blame" button,
On Sunday, 9 September 2018 at 01:30:14 UTC, Neia Neutuladh wrote:
On Sunday, 9 September 2018 at 00:20:04 UTC, void wrote:
How do I get a list of all packages (Github URL) available at
code.dlang.org?
I could download individual pages with wget --recursive
code.dlang.org but I wonder if
On Sunday, 9 September 2018 at 01:09:24 UTC, Andrei Alexandrescu
wrote:
it does stand to reason to print the last exception in a chain,
instead of the head, as the most relevant cause. Guess we'd do
good to have such functionality in the stdlib.
So given code like:
scope (exit) throw new
On Sunday, 9 September 2018 at 00:20:04 UTC, void wrote:
How do I get a list of all packages (Github URL) available at
code.dlang.org?
I could download individual pages with wget --recursive
code.dlang.org but I wonder if there is a better solution.
On Saturday, 8 September 2018 at 18:47:39 UTC, Neia Neutuladh
wrote:
On Saturday, 8 September 2018 at 06:59:28 UTC, Josphe Brigmo
wrote:
Having source code that doesn't show changes with dates is
pretty useless for diagnostics. I realize that git has the
changes but the source code should.
On 09/08/2018 12:24 AM, Jonathan Marler wrote:
I've rewritten rdmd into a new tool called "rund" and have been using it
for about 4 months. It runs about twice as fast making my workflow much
"snappier". It also introduces a new feature called "source directives"
where you can add special
On 9/7/18 7:15 PM, Tobias Mueller wrote:
On Thursday, 6 September 2018 at 14:39:12 UTC, Andrei Alexandrescu wrote:
Second, it does pay to keep abreast other languages. I had no idea
(and am quite ashamed of it) that Java also has chained exceptions:
On Saturday, 8 September 2018 at 22:01:23 UTC, Manu wrote:
TL;DR, debugging is critical and neglected. Mixin is worst
offender.
So, string mixin breaks the debugger. All of a sudden there is
code that's executing that doesn't exist anywhere. We need a
solution to this problem...
As I and
How do I get a list of all packages (Github URL) available at
code.dlang.org?
I could download individual pages with wget --recursive
code.dlang.org but I wonder if there is a better solution.
On 09/05/2018 03:35 PM, Meta wrote:
I think the only sane way to use asserts as an
optimization guide is when the program will abort if the condition does
not hold. That, to me, makes perfect sense, since you're basically
telling the compiler "This condition must be true past this assertion
On 09/08/2018 08:43 AM, Guillaume Piolat wrote:
We have something similar with dpldocs which builds docs lazily, and is
now linked from code.dlang.org
It's a matter of extending it with downloading toolchain and building.
I can't speak for anyone else but it looks to me as a realistic way
On Saturday, 8 September 2018 at 22:01:23 UTC, Manu wrote:
As I and others have suggested before; mixin expansion should
emit a `[sourcefile].d.mixin` file to the object directory,
this file should accumulate mixin instantiations, and perhaps
it would be ideal to also emit surrounding code for
On 09/08/2018 02:19 AM, Suliman wrote:
> Is it's correct to say that ALL types that can grow are place on heap
> and types that not growing (int, char, pointer) are place on stack?
The question is not that simple. :)
First, there is also the area used for objects that are static and
object
TL;DR, debugging is critical and neglected. Mixin is worst offender.
So, string mixin breaks the debugger. All of a sudden there is code
that's executing that doesn't exist anywhere. We need a solution to
this problem...
As I and others have suggested before; mixin expansion should emit a
On Saturday, 8 September 2018 at 14:20:10 UTC, Laeeth Isharc
wrote:
Religions have believers but not supporters - in fact saying
you are a supporter says you are not a member of that faith or
community.
If you are a supporter of Jesus Christ's efforts, then you most
certainly are a
https://issues.dlang.org/show_bug.cgi?id=19180
--- Comment #2 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/dmd
https://github.com/dlang/dmd/commit/6983b0b071f8cb495639f62382e8658ddde03d77
Fix Issue 19180 - Expose dmd.mtype.Type.isZeroInit as
On Saturday, 8 September 2018 at 18:21:07 UTC, drug wrote:
On 08.09.2018 20:59, Marcin wrote:
void main()
{
snipped
}
This? https://run.dlang.io/is/SHyCXA
Thanks :)
On Saturday, September 8, 2018 8:05:04 AM MDT Laeeth Isharc via Digitalmars-
d wrote:
> On Thursday, 6 September 2018 at 20:15:22 UTC, Jonathan M Davis
>
> wrote:
> > On Thursday, September 6, 2018 1:04:45 PM MDT aliak via
> >
> > Digitalmars-d wrote:
> >> D makes the code-point case default and
//Ten przyklad po prostu tworzy wątek w którym są trzy obiekty
import core.thread;
import std.stdio: write, writeln, writef, writefln;
class Sinus{
double a;
this(){writeln("No Args");}
this(double a){writeln("U give 1 argument");
writeln(sin(a));}
On Thursday, September 6, 2018 3:15:59 PM MDT aliak via Digitalmars-d wrote:
> On Thursday, 6 September 2018 at 20:15:22 UTC, Jonathan M Davis
>
> wrote:
> > On Thursday, September 6, 2018 1:04:45 PM MDT aliak via
> >
> > Digitalmars-d wrote:
> >> D makes the code-point case default and hence that
On Saturday, 8 September 2018 at 18:10:50 UTC, Jonathan M Davis
wrote:
A related issue is projects that have dependencies outside of D
itself
- for instance, a project that wraps GTK or Qt or something C
or C++ library
that is on many systems but which isn't guaranteed to be
present. It would
On Saturday, 8 September 2018 at 06:59:28 UTC, Josphe Brigmo
wrote:
Having source code that doesn't show changes with dates is
pretty useless for diagnostics. I realize that git has the
changes but the source code should.
What problem did you encounter where you had trouble getting the
On Saturday, 8 September 2018 at 07:08:46 UTC, Colin wrote:
Some ad hoc comment system in source code to point out changes
will never be as good.
Just Use Git!
I'd agree for implementation changes, but *interface* changes
should be not just in the comment, but in a doc comment. Ddoc
On 08.09.2018 20:59, Marcin wrote:
void main()
{
snipped
}
This? https://run.dlang.io/is/SHyCXA
On Saturday, September 8, 2018 6:35:32 AM MDT tide via Digitalmars-d wrote:
> Dates won't help, if you have a comment with a date that states
> everything under it was modified at that date. What happens when
> there's a split of 3-4 lines between modifications? Just how many
> of these comments
On Saturday, September 8, 2018 7:28:53 AM MDT Nicholas Wilson via
Digitalmars-d wrote:
> On Thursday, 6 September 2018 at 16:50:32 UTC, H. S. Teoh wrote:
> > Again, this strongly suggests the idea I've mentioned a few
> > times now: *all* packages on code.dlang.org needs to be run
> > through a
On Saturday, September 8, 2018 7:44:09 AM MDT Nicholas Wilson via
Digitalmars-d wrote:
> On Friday, 7 September 2018 at 19:15:21 UTC, Jonathan M Davis
>
> wrote:
> > Honestly, I wouldn't rely on anything beyond dub build working
> > in a consistent manner across projects. As far as I can tell,
>
https://run.dlang.io/is/PQkOfF
How to make it work?
void main()
{
import core.stdc.math : sin;
import core.thread;
import std.stdio : write, writeln, writef, writefln;
class DerivedThread : Thread
{
double d;
this()
{
super();
}
On Saturday, 8 September 2018 at 17:01:33 UTC, Jacob Shtokolov
wrote:
So, modification of pointer values is prohibited (if I
understand this sentence correctly).
@safe code can't manipulate the pointer itself, in order to avoid
memory corruption.
So this is forbidden:
void main() @safe
{
Hi,
According to the docs: https://dlang.org/spec/memory-safe-d.html
Memory-safe code cannot use certain language features, such as:
Casts that break the type system.
Modification of pointer values.
Taking the address of a local variable or function parameter.
So, modification of
I made somthing else... it works at the moment.
https://run.dlang.io/is/KdOeRz
But i need somthing like this to work:
https://run.dlang.io/is/lGD5YQ
Ive got problem with https://run.dlang.io/is/4a4CJp
Why it prints 111 forever?
On Saturday, 8 September 2018 at 12:36:01 UTC, Paul Backus wrote:
On Saturday, 8 September 2018 at 11:29:15 UTC, Josphe Brigmo
wrote:
Um, I didn't say don't use Git!
Your illogic is that you believe that one can have only one or
the other when one can have both. Hence, you are excluding a
On 06.09.2018 23:47, Walter Bright wrote:
On 9/5/2018 4:55 PM, Timon Gehr wrote:
John rather explicitly states the opposite in the article.
I believe that his statement:
"it’s not an interpretation that is universally useful"
is much weaker than saying "the opposite". He did not say it was
On Saturday, 8 September 2018 at 03:12:56 UTC, Josphe Brigmo
wrote:
auto foo(bool update = false)()
{
static if(update)
{ }
}
and the compiler, after upgrading to 2.082 from 2.080 now says:
Error: expression `update` of type `void` does not have a
boolean value
when update is
https://issues.dlang.org/show_bug.cgi?id=17206
Issue 17206 depends on issue 18675, which changed state.
Issue 18675 Summary: std.experimental.checkedint.Checked has opEquals but no
toHash
https://issues.dlang.org/show_bug.cgi?id=18675
What|Removed |Added
https://issues.dlang.org/show_bug.cgi?id=18675
--- Comment #4 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/phobos
https://github.com/dlang/phobos/commit/f21833ff154cfd1a405115f2bf79dca55151721c
Fix Issue 18675 - Missing toHash in
https://issues.dlang.org/show_bug.cgi?id=18675
github-bugzi...@puremagic.com changed:
What|Removed |Added
Status|NEW |RESOLVED
On 09/03/2018 08:13 PM, Dr.No wrote:
But it in the middle of output, I got output like this:
outjson = {"barCode":"20","ade":"20"}♪◙outjson =
{"barCode":"X21","ade":"21"}
also there's that extra ♪◙ character. Thos sounds memory violation
somewhere.
This only happens when using
On Thursday, 6 September 2018 at 14:42:14 UTC, Chris wrote:
On Thursday, 6 September 2018 at 14:30:38 UTC, Guillaume Piolat
wrote:
On Thursday, 6 September 2018 at 13:30:11 UTC, Chris wrote:
And autodecode is a good example of experts getting it wrong,
because, you know, you cannot be an
On Thursday, 6 September 2018 at 20:15:22 UTC, Jonathan M Davis
wrote:
On Thursday, September 6, 2018 1:04:45 PM MDT aliak via
Digitalmars-d wrote:
D makes the code-point case default and hence that becomes the
simplest to use. But unfortunately, the only thing I can think
of
that requires
Does anyone have some tips to try trace the error with debug or
so?
I haven't fixed this issue yet... any help is very appreciated
On Friday, 7 September 2018 at 19:15:21 UTC, Jonathan M Davis
wrote:
Honestly, I wouldn't rely on anything beyond dub build working
in a consistent manner across projects. As far as I can tell,
you can't actually do anything properly custom with dub test,
and I'm inclined to think that how it
On Thursday, 6 September 2018 at 16:50:32 UTC, H. S. Teoh wrote:
Again, this strongly suggests the idea I've mentioned a few
times now: *all* packages on code.dlang.org needs to be run
through a CI tester, and success/failure to compile should be
reported back to dlang.org somehow. Then in
https://issues.dlang.org/show_bug.cgi?id=19235
--- Comment #1 from Johannes Pfau ---
Same problem with static nested functions:
-
struct FloatingPointControl
{
void foo() pure
{
static bool nested() {
On Friday, 7 September 2018 at 08:12:05 UTC, Nick Sabalausky
(Abscissa) wrote:
Personally, I think that's a really good way to go. However,
for awhile now, I've been starting to think: "Wouldn't it be
awesome to have a packager manager that AUTOMATICALLY picks up
compatibility information
On Saturday, 8 September 2018 at 11:24:50 UTC, rjframe wrote:
The beta might be better than dmd-nightly, as they would avoid
the churn and still provide maintainers with time to react to
problems with the upcoming release before the release is out.
Betas are often outdated and contain
On Saturday, 8 September 2018 at 11:29:15 UTC, Josphe Brigmo
wrote:
Um, I didn't say don't use Git!
Your illogic is that you believe that one can have only one or
the other when one can have both. Hence, you are excluding a
completely valid addition. You think it is an alternative. You
are
On Saturday, 8 September 2018 at 11:29:15 UTC, Josphe Brigmo
wrote:
On Saturday, 8 September 2018 at 07:08:46 UTC, Colin wrote:
On Saturday, 8 September 2018 at 06:59:28 UTC, Josphe Brigmo
wrote:
Having source code that doesn't show changes with dates is
pretty useless for diagnostics. I
https://issues.dlang.org/show_bug.cgi?id=19235
Issue ID: 19235
Summary: Repeatedly calling non-pure function in non-pure
literal nested in pure function is broken
Product: D
Version: D2
Hardware: All
OS: All
On Saturday, 8 September 2018 at 11:29:15 UTC, Josphe Brigmo
wrote:
On Saturday, 8 September 2018 at 07:08:46 UTC, Colin wrote:
On Saturday, 8 September 2018 at 06:59:28 UTC, Josphe Brigmo
wrote:
Having source code that doesn't show changes with dates is
pretty useless for diagnostics. I
On Friday, 7 September 2018 at 14:36:42 UTC, Russel Winder wrote:
From what I can see, processes created with std.process:
spawnProcess are not terminated when the creating process
terminates, i.e. it seems Config.detached is the default for
these process.
Is there a way of all spawned
https://issues.dlang.org/show_bug.cgi?id=17206
Issue 17206 depends on issue 18683, which changed state.
Issue 18683 Summary: std.containers.rbtree.RedBlackTree has opEquals but no
toHash
https://issues.dlang.org/show_bug.cgi?id=18683
What|Removed |Added
https://issues.dlang.org/show_bug.cgi?id=18683
--- Comment #1 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/phobos
https://github.com/dlang/phobos/commit/e61f89738131b25458d52b92b673517a5002ff0f
Fix Issue 18683 - no toHash in rbtree
https://issues.dlang.org/show_bug.cgi?id=18683
github-bugzi...@puremagic.com changed:
What|Removed |Added
Status|NEW |RESOLVED
On Saturday, 8 September 2018 at 07:30:35 UTC, Alex wrote:
On Saturday, 8 September 2018 at 06:56:40 UTC, Josphe Brigmo
wrote:
My project does not use the term update at all in any other
context except that one. But I did find:
void update(K, V, C, U)(ref V[K] aa, K key, scope C create,
On Saturday, 8 September 2018 at 07:08:46 UTC, Colin wrote:
On Saturday, 8 September 2018 at 06:59:28 UTC, Josphe Brigmo
wrote:
Having source code that doesn't show changes with dates is
pretty useless for diagnostics. I realize that git has the
changes but the source code should.
If some
On Fri, 07 Sep 2018 09:35:29 -0700, H. S. Teoh wrote:
> ([*] I was going to suggest including dmd-nightly as well, but that
> poses the problem of load: running it every night will cause a lot of CI
> churn, which also generates a lot of mostly-useless information -- no
> one will care about
On Sat, 2018-09-08 at 10:24 +, FreeSlave via Digitalmars-d-learn wrote:
> On Friday, 7 September 2018 at 14:36:42 UTC, Russel Winder wrote:
> > From what I can see, processes created with std.process:
> > spawnProcess are not terminated when the creating process
> > terminates, i.e. it seems
On Sat, 08 Sep 2018 10:22:38 +, SuperPrower wrote:
> Also, is this me and my bad English, or first comment in code in this
> paragraph (linked above, not in the discussion) is supposed to be
> something different? Shouldn't it be reference?
Static arrays are value types, so the values are
On Friday, 7 September 2018 at 16:44:09 UTC, Russel Winder wrote:
I guess this might work on Windows, but I am on Linux and OSX,
so I'll have to try another route.
On Posix systems you may try using SIGCHLD handler. Google for
exact examples.
On Saturday, 8 September 2018 at 10:05:31 UTC, rikki cattermole
wrote:
onReceive:
"The event handler that receives incoming data. Be sure to copy
the incoming ubyte[] since it is not guaranteed to be valid
after the callback returns."
It could be a buffer on the stack, either way, .dup it
On Friday, 7 September 2018 at 14:36:42 UTC, Russel Winder wrote:
From what I can see, processes created with std.process:
spawnProcess are not terminated when the creating process
terminates, i.e. it seems Config.detached is the default for
these process.
No, detached is not default. By
On Wednesday, 5 September 2018 at 16:53:42 UTC, NX wrote:
Is there a way to know what kind of context a delegate has
either in compile time or runtime?
Also is there any way to check whether a pointer legitimately
points to an Object instance?
No and no. I was fighting this problem in
On 08/09/2018 9:46 PM, SuperPrower wrote:
On Saturday, 8 September 2018 at 09:36:21 UTC, rikki cattermole wrote:
We're going to need to see a minified version of the code to see what
you're doing.
Sure, here it is:
```
auto getBoards()
{
string[] boardList;
auto url = baseUrl ~
On Saturday, 8 September 2018 at 08:32:58 UTC, Guillaume Piolat
wrote:
On Saturday, 8 September 2018 at 08:07:07 UTC, Peter Alexander
wrote:
I'd love to know if anyone is making good use of @nogc in a
larger code base and is happy with it. Weka.io?
Not Weka but we are happy with @nogc and
On Saturday, 8 September 2018 at 09:36:21 UTC, rikki cattermole
wrote:
We're going to need to see a minified version of the code to
see what you're doing.
Sure, here it is:
```
auto getBoards()
{
string[] boardList;
auto url = baseUrl ~ "/api/v2/boards";
auto http =
On 08/09/2018 9:34 PM, SuperPrower wrote:
I have a function that produces dynamic array of strings. I would like
to return this array from this function. I understand that dynamic
arrays are of reference type, and thus if I try to return array
variable, I will actually return a pointer to the
I have a function that produces dynamic array of strings. I would
like to return this array from this function. I understand that
dynamic arrays are of reference type, and thus if I try to return
array variable, I will actually return a pointer to the first
element of the array on the heap.
On Sat, 2018-09-08 at 02:38 +, Basile B. via Digitalmars-d-learn wrote:
>
[…]
> You can wrap in a Process struct or class and take advantage of
> the destructor to do that. Assuming you write standard GC-ed code
> the destructor should be called at the end or if you free
> manually the
Is it's correct to say that ALL types that can grow are place on
heap and types that not growing (int, char, pointer) are place on
stack?
Or there is some exceptions?
Is there any tools that can visualize place of data in memory?
On Saturday, 8 September 2018 at 08:07:07 UTC, Peter Alexander
wrote:
I'd love to know if anyone is making good use of @nogc in a
larger code base and is happy with it. Weka.io?
Not Weka but we are happy with @nogc and without @nogc our job
would be impossible.
You don't like it fine. But I
On Friday, 7 September 2018 at 17:01:09 UTC, Meta wrote:
You are allowed to call "@gc" functions inside @nogc functions
if you prefix them with a debug statement, e.g.:
Thanks! I was aware that debug is an escape hatch for pure, but
didn't consider it for @nogc.
I've been thinking lately
https://issues.dlang.org/show_bug.cgi?id=19228
github-bugzi...@puremagic.com changed:
What|Removed |Added
Status|NEW |RESOLVED
https://issues.dlang.org/show_bug.cgi?id=19228
--- Comment #2 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/phobos
https://github.com/dlang/phobos/commit/bcc9d57b204754771b0c75f213699b81bc5a7755
Fix issue 19228 - hasAliasing fails on static arrays
On Saturday, 8 September 2018 at 06:56:40 UTC, Josphe Brigmo
wrote:
My project does not use the term update at all in any other
context except that one. But I did find:
void update(K, V, C, U)(ref V[K] aa, K key, scope C create,
scope U update)
Ok... found something here:
On Saturday, 8 September 2018 at 01:32:19 UTC, Everlast wrote:
On Saturday, 8 September 2018 at 00:53:33 UTC, Neia Neutuladh
wrote:
[...]
There are ways around this:
[...]
Is there any other language that does any of this? I don't think
any language does all of it, so do you plan to wait
On Saturday, 8 September 2018 at 06:59:28 UTC, Josphe Brigmo
wrote:
Having source code that doesn't show changes with dates is
pretty useless for diagnostics. I realize that git has the
changes but the source code should.
If some code is added or changed it is very simple to add the
date of
On Saturday, 8 September 2018 at 05:39:39 UTC, Alex wrote:
On Saturday, 8 September 2018 at 03:12:56 UTC, Josphe Brigmo
wrote:
auto foo(bool update = false)()
{
static if(update)
{ }
}
and the compiler, after upgrading to 2.082 from 2.080 now says:
Error: expression `update` of type
Having source code that doesn't show changes with dates is pretty
useless for diagnostics. I realize that git has the changes but
the source code should.
If some code is added or changed it is very simple to add the
date of change in a comment.
// Date: Date1, Date2, Date3,
Anything
92 matches
Mail list logo