Full macro system is not needed to implement it, just AST
reflection can do the trick (and has better fit with existing
features).
On Friday, 11 July 2014 at 22:38:36 UTC, Idan Arye wrote:
On Friday, 11 July 2014 at 17:00:32 UTC, Dicebot wrote:
Full macro system is not needed to implement it, just AST
reflection can do the trick (and has better fit with existing
features).
Wouldn't AST reflection be more complex to
On Friday, 11 July 2014 at 21:34:37 UTC, Robert burner Schadek
wrote:
Is it too late for an integration in std.expirimental with dmd
2.66?
ask Andrew, but I'm 99.9% sure it is to late
Despite how reasonable it may seem I believe that being stupid
formal about release process is the Right
On Friday, 11 July 2014 at 22:42:26 UTC, Ary Borenszweig wrote:
Also, what you want to do with an AST is definitely creating
code. And, in my opinion, it's much easier to create code by
writing it and not by creating the nodes.
Choice is very simple in my opinion. AST macro system overlaps
On Saturday, 12 July 2014 at 03:22:10 UTC, Jesse Phillips wrote:
On Friday, 11 July 2014 at 14:39:09 UTC, David Nadlinger wrote:
On Friday, 11 July 2014 at 14:36:34 UTC, Dicebot wrote:
Round of a formal review before proceeding to voting. Subject
for Phobos inclusion :
On Saturday, 12 July 2014 at 12:24:19 UTC, Katayama Hirofumi MZ
wrote:
Could you support importing from Internet feature? I think
that'll be very convenient.
import http://example.com/MyLibrary.d;;
dub : code.dlang.org
On Saturday, 12 July 2014 at 13:10:09 UTC, Katayama Hirofumi MZ
wrote:
https://github.com/D-Programming-Language/dub/issues/373
What I have meant is that importing from internet functionality
is currently provided by dub packages and does not belong to
compiler. URL imports in your proposed
I agree. Go approach my seem tempting in its simplicity but it
scales terribly. It is one of less wise decisions made by Go
authors.
On Saturday, 12 July 2014 at 14:43:13 UTC, Russel Winder via
Digitalmars-d wrote:
The decision wasn't made by the Go authors, it was proposed and
initially implemented by users, then incorporated into Go by the
official high priests.
As to whether it is wise, that is must be left to opinion and
On Saturday, 12 July 2014 at 16:38:35 UTC, Russel Winder via
Digitalmars-d wrote:
On Sat, 2014-07-12 at 15:41 +, Dicebot via Digitalmars-d
wrote:
[…]
Sorry but I am tired of endless appeal to history / usage - by
this logic Java and PHP are very good languages full of
wisdom
On Sunday, 13 July 2014 at 01:49:16 UTC, Nick Sabalausky wrote:
So I have some questions: What is the magic number that will
trigger the release? What happens if we never reach that
number?
Do we just continue waiting for it or do we make a decision at
some point that it's time? If so, how
On Friday, 11 July 2014 at 23:46:44 UTC, Idan Arye wrote:
AST(T) toAST(T)(macro(T) expr){
return expr;
}
And I mean something like this:
string takeAST(__ast expr)()
{
return expr.stringof; // need more detailed reflection than
that of course ;)
}
mixin(takeAST!(2 +
On Sunday, 13 July 2014 at 10:19:26 UTC, Jacob Carlborg wrote:
On 2014-07-12 01:02, Dicebot wrote:
Whatever is ideal solution, we better focus on something
practical that
can be realistically added to the language within current
priorities
(stability, minimizing addition of new features,
On Sunday, 13 July 2014 at 07:18:53 UTC, Walter Bright wrote:
On 7/10/2014 5:54 AM, Dicebot wrote:
No one but Walter / Andrei can do anything about it. Right now
we are in weird
situation when they call for lieutenants but are not ready
to abandon decision
power. It can't possibly work that
On Sunday, 13 July 2014 at 07:18:53 UTC, Walter Bright wrote:
On 7/10/2014 5:54 AM, Dicebot wrote:
No one but Walter / Andrei can do anything about it. Right now
we are in weird
situation when they call for lieutenants but are not ready
to abandon decision
power. It can't possibly work that
On Sunday, 13 July 2014 at 11:57:26 UTC, Robert burner Schadek
wrote:
- The functions error(), info(), fatal(), etc. don't follow
the usual rule for functions to start with a verb. The
question is if saving three characters over logError() is
worth making the code more ambiguous for the
On Sunday, 13 July 2014 at 12:18:40 UTC, Jacob Carlborg wrote:
logError is a lot more clear and descriptive. I think that's
important. If people don't like that they can use an alias.
It is effectively same as using static namespace class but
C-style - mangling namespace into function name.
On Sunday, 13 July 2014 at 12:33:21 UTC, Timon Gehr wrote:
Yes I know and likely would have preferred that approach if we
were
speaking about designing brand new language. But right now we
already
have string mixins
They are not a great liability. They are a simple feature. They
take up
On Sunday, 13 July 2014 at 12:41:59 UTC, sigod wrote:
I use my own log module like this:
```
import log = util.log;
log.info(...);
log.debug(...);
// etc
```
Exactly. I think this should be popularized as default style via
std.logger documentation.
On Sunday, 13 July 2014 at 12:55:30 UTC, sigod wrote:
Something like this would be possible if one could get string
representation of a lazy expression:
```
void _logfx(lazy int expr)
{
DebugLog(expr.stringof); // currently it outputs `expr()`
fx(expr);
}
```
lazy expressions are in
On Sunday, 13 July 2014 at 14:23:07 UTC, Timon Gehr wrote:
I am not saying it is insanely complicated but that it is not
orthogonal
to existing features. ...
I am saying that string mixins are way too simple a feature to
meaningfully block the way for features that are not
orthogonal to
On Sunday, 13 July 2014 at 14:12:56 UTC, Jacob Carlborg wrote:
On 2014-07-13 14:45, Dicebot wrote:
Exactly. I think this should be popularized as default style
via
std.logger documentation.
If that's the style everyone is encouraged to use, why not
force it then?
Because starting with
On Sunday, 13 July 2014 at 15:17:27 UTC, Timon Gehr wrote:
(Just to be sure: I was talking about string mixins, not
macros, I haven't implemented macros.)
Currently it isn't. It isn't really in a state where I'd like
to see it released. There are some language features still
missing, and its
On Sunday, 13 July 2014 at 14:37:15 UTC, Robert burner Schadek
wrote:
I would prefer:
info(%s is the answer, true);
write infof(%b is the answer, true); and it works write now
arbitrarily
I am kind of fine both ways, it is not that big deal but I
remember being very surprised that most
On Sunday, 13 July 2014 at 15:19:19 UTC, Robert burner Schadek
wrote:
On Sunday, 13 July 2014 at 15:12:19 UTC, Dragos Carp wrote:
* there is no reason to limit it arbitrarily
Simple is better than complex.
it is hardly complex
Of course it is... wasn't this one of the main reasons you
Added some basic implementation
(https://github.com/D-Programming-Language/dmd/pull/3758), need
some feedback from any DMD hackers who actually know how stuff is
supposed to work :(
On Sunday, 13 July 2014 at 16:12:02 UTC, Andrew Edwards wrote:
After adding back the v2.066.0-b3 tag, I get this:
dmd
Switched to branch 'master'
Your branch is up-to-date with 'origin/master'.
v2.066.0-b1-80-ga721850
Switched to branch '2.066'
Your branch is
On Sunday, 13 July 2014 at 16:32:15 UTC, Brian Rogoff wrote:
On Sunday, 13 July 2014 at 12:21:13 UTC, Jacob Carlborg wrote:
Yeah, there are many features that could have been implemented
as macros instead of in the language, if D had had them from
the beginning.
What's the status of that
On Monday, 14 July 2014 at 09:10:36 UTC, Jacob Carlborg wrote:
On 13/07/14 17:16, Dicebot wrote:
Because starting with documentation in Phobos and than
proceeding with
convincing Walter to add built-in support for such idiom is
much more
realistic way than the other way around ;)
built-in
On Thursday, 22 July 2004 at 23:35:36 UTC, Gold Dragon wrote:
But there's no official location, wiki, or otherwise. I
don't know..
I mean there's dsource.org and I know there is a wiki at the
moment
that's maintaining some documentation. But it'd be nice to
see something
more formal.
I
Ah I see. Your tag references merged commit but not merge
commit, former being implicit part of the latter when it comes
to git describe.
Printing HEAD for 2.066 shows this:
commit 2b795569cd892801050faec80054d91c1fb54d3c
Merge: d84aadd 601d478
As you may notice it mentions d84aadd (your
On Sunday, 13 July 2014 at 20:54:27 UTC, Ary Borenszweig wrote:
AST reflection + string mixins can do anything that AST macros
can do -
assuming one does not want to allow transparent macros
(without explicit
mixin/macro keyword at call site) which is a terrible idea in
my opinion
anyway.
Whoa, looks like a web-interface glitch that has resulted in
ancient thread being raised. Now I am feeling stupid :)
On Monday, 14 July 2014 at 08:45:12 UTC, Mike Parker wrote:
On 7/14/2014 12:55 PM, Vic wrote:
- Confusing forum. First listed forum on 'D' is not for D
users, but
it's called D! It is in fact for D commiters. This causes
frustration
for both users and commiters. (yes there is 'learn D' but
On Monday, 14 July 2014 at 15:13:21 UTC, Timon Gehr wrote:
On 07/14/2014 11:55 AM, Dicebot wrote:
I must admit D is far from perfect in that regard because
operator
overloading is still not limited enough
There is no real point in limiting it at all. It is just a
matter of naming your
On Monday, 14 July 2014 at 14:24:39 UTC, Jacob Carlborg wrote:
On 14/07/14 11:35, Dicebot wrote:
Yes, something like separate partially static import type.
I doesn't need language support. Just have a single function,
log, which returns a struct. The struct have all the error,
warning and
On Monday, 14 July 2014 at 15:34:12 UTC, Dicebot wrote:
On Monday, 14 July 2014 at 14:24:39 UTC, Jacob Carlborg wrote:
On 14/07/14 11:35, Dicebot wrote:
Yes, something like separate partially static import type.
I doesn't need language support. Just have a single function,
log, which
On Monday, 14 July 2014 at 15:43:33 UTC, Daniel Murphy wrote:
Dicebot wrote in message
news:veqlcdugugxpffajp...@forum.dlang.org...
D unit of encapsulation is module. Any other namespace
solutions must die after proper torture.
Just use this in the next release!
extern(C++, log)
{
On Monday, 14 July 2014 at 14:12:37 UTC, Andrew Edwards wrote:
cd dmd
git checkout 2.066
git tag -m git tag -m v2.066.0-b3 2.066
git push upstream v2.066.0-b3
http://wiki.dlang.org/Simplified_Release_Process_Proposal#Releases
It has worked correctly for me (resulted in 2b795569 tagged). Can
On Monday, 14 July 2014 at 16:10:54 UTC, Ary Borenszweig wrote:
Making macros look like regular function calls, that you might
not like. For me, it makes the code more readable. Instead of
this:
class Foo
mixin(property :foo)
end
Or this:
class Foo
property!(:foo)
end
You simple write
On Monday, 14 July 2014 at 16:10:59 UTC, Timon Gehr wrote:
Same principle of surprise minimization. Reader expects
arbitrary
actions done by function call.
No way.
?
Reader expects arithmetical semantics
Right, arithmetical semantics, which for built-in '+' can reach
from wrap-around
On Sunday, 13 July 2014 at 18:20:12 UTC, Walter Bright wrote:
On 7/13/2014 4:05 AM, Dicebot wrote:
Also I was not speaking originally about all good pull
requests just waiting
to be merged but about stuff that hits some controversial
language/Phobos parts
and requires some decision if it can
On Monday, 14 July 2014 at 17:44:37 UTC, Jeremy Powers via
Digitalmars-d wrote:
Is this where I talk about hierarchical logging?
There was some talk in the original review thread about having
each log
import create or tag the log with the module, so one could
refer to and
filter by modules.
On Monday, 14 July 2014 at 18:30:34 UTC, Walter Bright wrote:
On 7/14/2014 9:56 AM, Dicebot wrote:
I will keep an eye std.concurrency but I what should I do to
convince you say a
word or two about DMD PR that makes some language change? :)
I still believe that Andrei I need to approve
Yes, currently tags are OK in dmd repo:
https://github.com/D-Programming-Language/dmd/commits/2.066
https://github.com/D-Programming-Language/dmd/commits/v2.066.0-b3
..it was different at point Kenji had written his message. Have
you pushed new ones recently?
On Wednesday, 16 July 2014 at 01:34:58 UTC, Kiith-Sa wrote:
Just noticed this:
http://blog.octayn.net/blog/2014/06/30/this-week-in-rust-54/
This is precisely the kind of thing we need.
Huge amount of non-interesting effort. There was someone trying
to do similar digest for D but effort
On Wednesday, 16 July 2014 at 09:56:06 UTC, Vic wrote:
Any comments on Qt as choice?
Pros: mature and widely used framework
Cons: it is still C++ :)
On Wednesday, 16 July 2014 at 04:11:28 UTC, Kapps wrote:
On Wednesday, 16 July 2014 at 03:31:13 UTC, Pavel Evstigneev
wrote:
May I improve forum to support markdown?
The forum is actually an interface to a newsgroup, so most
forms of markdown would not be supported in the interest of
having
Slight correction : it is not a mangling of variable that is a
problem (local variables don't have any mangling) but mangling of
the function itself (it naively uses variable name for mangled
name generation). Should use something like unique id instead.
On Thursday, 17 July 2014 at 09:57:37 UTC, Walter Bright wrote:
I.e. it's why, not why not make a breaking change.
Especially since it is apparently a commonly used coding
pattern, appearing 25 times in Phobos alone.
It is used 0 times in Phobos. In fact I have not seen it used for
a single
On Thursday, 17 July 2014 at 17:11:29 UTC, Nick Treleaven wrote:
I want to add a static opCall with no arguments to simulate a
nullary-argument constructor.
Please don't do it unless you have a _very_ compelling use case.
As nullary static opCall doesn't conflict with a nullary
constructor
(for Unique probably disabling default constructor makes most
sense)
On Thursday, 17 July 2014 at 17:58:15 UTC, Chris wrote:
That's good news! See, we're getting there, just bear with us.
This begs the question of course, how will this affect existing
code? My code is string intensive.
Usually GC-free API is added by providing new overloads that take
an
On Thursday, 17 July 2014 at 17:28:02 UTC, Vic wrote:
If that is true, I may even do a $ bounty to make Phobos GC
free.
Unless you do some hard real-time barebone stuff it is quite
likely you can do with limited usage of GC. Hiring some of
experienced D user to make a one-time case study
On Thursday, 17 July 2014 at 18:22:11 UTC, H. S. Teoh via
Digitalmars-d wrote:
Actually, I've realized that output ranges are really only
useful when
you want to store the final result. For data in mid-processing,
you
really want to be exporting an input (or higher) range interface
instead,
Because applications with hard real-time requirements take hardly
any more than 5% of all software industry. And those almost never
used standard tools/libraries.
On Thursday, 17 July 2014 at 19:41:57 UTC, Jacob Carlborg wrote:
On 2014-07-17 18:35, Kapps wrote:
Also, there used to be a built in syntax, 'scope foo = new
Foo()' that
would allocate on the stack, but that's deprecated now (and
seemed to
segfault when I tried it).
It is still available
On Thursday, 17 July 2014 at 21:03:08 UTC, Walter Bright wrote:
Did you see my response?
I suggested recognizing in the parser:
( Identifier )
as a special case, in addition to using
Parser::isDeclaration(). Gradually we can turn that special
case into a warning, then deprecation.
On Thursday, 17 July 2014 at 20:52:15 UTC, Hannes Steffenhagen
wrote:
Last time I checked, D was advertised as a systems programming
language and a real alternative to C/C++. I think we're good
for languages that cover the needs of web application
developers, that 5% is where most people
On Thursday, 17 July 2014 at 21:51:54 UTC, bearophile wrote:
Walter Bright:
We need to STOP breaking existing code.
This is a small example case where I suggest to break
hypothetical existing code:
https://github.com/D-Programming-Language/phobos/pull/2077#issuecomment-49360265
The fear
On Thursday, 17 July 2014 at 22:06:01 UTC, Brad Anderson wrote:
I agreed with this for awhile but following the conversation
here
https://github.com/D-Programming-Language/phobos/pull/2149
I'm more inclined to think we should be adding lazy versions of
functions where possible rather than
On Thursday, 17 July 2014 at 22:21:54 UTC, Brad Anderson wrote:
Well the idea is that you then copy into an output range with
whatever allocation strategy you want at the end. There is
quite a bit of overlap I think. Not complete overlap and
OutputRange accepting functions will still be needed
On Friday, 18 July 2014 at 00:38:16 UTC, Mike wrote:
I take that back, this DConf 2014 video
(http://www.youtube.com/watch?v=TNvUIWFy02I) is streamed in HD.
I'm not sure why the others aren't.
Most likely this is exactly the re-encoding thing that was
mentioned - better qualities get added
Something like reduced hash from mangled name of parent scope +
incremental ID for each new stack instance.
On Friday, 18 July 2014 at 00:48:38 UTC, Andrei Alexandrescu
wrote:
That would be serious. What code would change behavior with
Walter's proposal? -- Andrei
That was an answer to bearophile, not Walter, false alarm ;)
On Friday, 18 July 2014 at 06:46:16 UTC, Jacob Carlborg wrote:
On 17/07/14 22:18, Dicebot wrote:
Discouraged and unmaintained is probably a better
description.
How does it need maintaining?
I mean that if you create bug report or enhancement request for
scope classes it is quite unlikely
On Friday, 18 July 2014 at 00:08:17 UTC, H. S. Teoh via
Digitalmars-d wrote:
On Thu, Jul 17, 2014 at 06:32:58PM +, Dicebot via
Digitalmars-d wrote:
On Thursday, 17 July 2014 at 18:22:11 UTC, H. S. Teoh via
Digitalmars-d
wrote:
Actually, I've realized that output ranges are really only
Also, vibe.d internal `cloneFunction` which generates copy of
method/function signature with fully qualified type names (for
mixin hygiene):
https://github.com/rejectedsoftware/vibe.d/blob/master/source/vibe/internal/meta/codegen.d#L177
http://dlang.org/phobos/std_traits.html#ParameterIdentifierTuple
http://dlang.org/phobos/std_traits.html#ParameterDefaultValueTuple
http://dlang.org/phobos/std_traits.html#ParameterTypeTuple
?
On Saturday, 19 July 2014 at 03:39:55 UTC, Andrei Alexandrescu
wrote:
Andrei: I'm about 90% sure you're doing something wrong. I've
never seen
a HD youtube video with such low quality.
Ask Dicebot, he's doing it.
All I did:
1) wget archive.org link for largest available .mp4
2) press
On Saturday, 19 July 2014 at 00:05:55 UTC, Brad Anderson wrote:
To summarize what I think are the best ideas so far:
std.string
--
EagerLazy
-
capitalize capitalized
center centered
detabdetabbed
entab
On Sunday, 20 July 2014 at 10:19:10 UTC, Jonathan M Davis wrote:
Do we really want to be naming functions which aren't
properties with adjectives instead of verbs?
Yes. We have parens for denoting functions.
Oh wait.
On Monday, 21 July 2014 at 17:32:53 UTC, Manu via Digitalmars-d
wrote:
I'm having all sorts of visibility problems.
I have this:
app/system/...
app/system/widgets/...
The 'system'/manager should be able to access all the widgets
internals,
but things outside the system shouldn't be able
On Wednesday, 23 July 2014 at 01:31:48 UTC, Alf wrote:
foreach (ref f; [bar.f1, bar.f2])
This allocates new array and copies struct values to it (as D
structs are value types). I think this should have been a
compile-time error btw, it never makes sense to do ref iteration
over an array
Also please post any further questions to
http://forum.dlang.org/group/digitalmars.D.learn instead
On Wednesday, 23 July 2014 at 17:15:12 UTC, Ary Borenszweig wrote:
Imagine you have a list of integers and strings denoting
integers: [1, 2, 100, 38]. Now you want to sort them
according to their numeric value. Of course, 1 and 1 would
have the same order. However, 1 and 1 are different, so ==
On Wednesday, 23 July 2014 at 18:49:49 UTC, Andrei Alexandrescu
wrote:
I'd say let's leave things as they are. opEquals may need to do
less work than opCmp, and it often sees intensive use. -- Andrei
You will be the one answering user complaints ;)
On Thursday, 24 July 2014 at 01:39:01 UTC, H. S. Teoh via
Digitalmars-d wrote:
Keep in mind, though, that due to current AA changes in 2.066
beta,
existing code WILL break unless we autogenerate opEquals to be
opCmp()=0. In fact, issue 13179 was originally filed because
2.066 beta
broke
Initial review period is closing soon. I will make a summary and
start a voting thread this weekend.
On Thursday, 24 July 2014 at 18:51:03 UTC, Andrei Alexandrescu
wrote:
3. I'm not sure I like the design using defaultLogger in
conjunction with free functions using it. It clearly makes for
comfortable casual logging by just calling log(whatevs) and it
uses a precedent set by stdout. But I
On Friday, 25 July 2014 at 07:11:06 UTC, Jacob Carlborg wrote:
On 22/07/14 11:43, ponce wrote:
NullLogger is there precisely because it's trivial and needed.
If it's so trivial then the users can implement that
themselves. A standard library isn't about implementing what's
trivial, it's
On Friday, 25 July 2014 at 22:15:15 UTC, Andrei Alexandrescu
wrote:
We've just open-sourced another D project at Facebook (just a
developer beta), an ODBC driver for the Presto database engine:
https://github.com/prestodb/presto-odbc.
Why no D.announce ?
On Saturday, 26 July 2014 at 01:24:31 UTC, Walter Bright wrote:
On 7/25/2014 6:13 PM, Mike wrote:
IMO breaking changes are justified if the changes fix a design
flaw in the
language or the changes break code that should have never been
permitted.
Ironically, today I'm being vehemently argued
On Friday, 25 July 2014 at 17:32:38 UTC, Andrei Alexandrescu
wrote:
Why? I don't have much context but a few people I talked to
were positive
about the community contribution to php docs. -- Andrei
You have not been reading latest discussions about it carefully
then ;)
(I also think it is
On Saturday, 26 July 2014 at 19:44:49 UTC, Iain Buclaw wrote:
Hi,
TypeTuples have a special mangling convention in the compiler.
As per the docs (ref: http://dlang.org/abi.html)
TypeTuple:
B Number Arguments
This is.. funny. Type tuples don't really have ABI, they don't
even have
On Saturday, 26 July 2014 at 17:55:55 UTC, Marc Schütz wrote:
The language reference on functions [1] says:
If a FunctionLiteral is immediately called, its inlining would
be enforced normally.
How is this to be interpreted?
[1] http://dlang.org/function
I can't PR but there were one by
On Sunday, 27 July 2014 at 00:38:14 UTC, Dicebot wrote:
All pages seem to miss all examples - simply not implemented
yet or oversight?
ah, nevermind:
I still haven't included syntax highlighting. This really isn't
hard, I just haven't gotten around to doing it yet.
..and fixed width docs again. Unfortunately I am not competent
enough to propose any change so user CSS it stays for me :(
All pages seem to miss all examples - simply not implemented yet
or oversight?
On Sunday, 27 July 2014 at 00:43:41 UTC, Iain Buclaw via
Digitalmars-d wrote:
I'd be the sceptic of that. Which file exactly did he change?
(hint:
It may be ignored by other compilers).
Oh crap it is still open :D (and judging by comments there you
should more aware of what does than me) :
On Sunday, 27 July 2014 at 15:15:31 UTC, Jim Hewes wrote:
I do try to learn more about things like Haskell and D and
meta-programming and ranges, etc., but there isn't so much time
when your regular job takes up over 40 hours a week. With
programming, I feel like you can read about something
On Monday, 28 July 2014 at 09:16:44 UTC, Gary Willoughby wrote:
Your problem is you are not able to take any criticism
whatsoever against this piece of work. The design is awful,
period.
Criticism is worthless if you are not ready to actually do
something about it - providing detailed list
(sorry for being a bit late, was distracted)
std.logger proposal by Robert Schadek enters voting period which
will last two weeks starting from now.
Discussion thread :
http://forum.dlang.org/post/zhvmkbahrqtgkptdl...@forum.dlang.org
This voting will be somewhat different from previous
Small foreword specifically about std.logger :
It is quite clear that something like logging system is very
opinionated thing with API/design preferences highly based on
actual use cases. I don't think that we will ever be able to come
up with decisions that will satisfy everyone - some
On Monday, 28 July 2014 at 11:35:21 UTC, Ola Fosheim Grøstad
wrote:
On Monday, 28 July 2014 at 11:16:39 UTC, Dicebot wrote:
going and getting stuff done - same principle apply here. If
you have professional web development experience that may help
here - start helping somehow.
You need to
Heh, have written a GitHub feature request about this ~2 weeks
ago, got answer we are already working on this, going to be
release soon. Have been eagerly awaiting announcement since then.
This can be very useful for improving pull request review
process. I think we should not duplicate PR
On Tuesday, 29 July 2014 at 01:35:30 UTC, Orvid King wrote:
How accessible is it possible to make the labels?
As far as I can see one needs admin access to the repo to define
new labels. Merge access is not enough - at least I don't seem to
be able define new label for Phobos.
Can they be
On Tuesday, 29 July 2014 at 06:09:25 UTC, Andrei Alexandrescu
wrote:
No in current form. Yes assuming the fixes below are
implemented.
...
No. I also think any new module should sit in std.experimental
for one release cycle.
Clarification, just to be sure you got it right - right now we
On Tuesday, 29 July 2014 at 06:32:15 UTC, Daniel Murphy wrote:
I'm thinking along the lines of:
- Needs review
- Needs work
Makes sense if we agree to add those only if nothing happens with
pull for relatively long time - otherwise it means lot of useless
routine of switching back and forth
On Tuesday, 29 July 2014 at 06:35:06 UTC, Daniel Murphy wrote:
The idea is you test your code with assertions enabled, and
then only use '-release' when you are sure your program
functions correctly.
If you are doing critical work or do not trust program input,
either do not disable
On Tuesday, 29 July 2014 at 06:24:26 UTC, Daniel Murphy wrote:
Dicebot wrote in message
news:dltkkijmuwhjcchej...@forum.dlang.org...
As far as I can see one needs admin access to the repo to
define new labels. Merge access is not enough - at least I
don't seem to be able define new label
301 - 400 of 2167 matches
Mail list logo
