On Sunday, 2 April 2017 at 04:34:34 UTC, H. S. Teoh wrote:
On Sat, Apr 01, 2017 at 05:06:14PM +, Inquie via
Digitalmars-d wrote: [...]
How far off until newCTFE is usable to compile the majority of
templates out there?
CTFE and templates are two separate things. You may want to
read this
On Tuesday, 7 February 2017 at 13:39:38 UTC, Vladimir Panteleev
wrote:
On Tuesday, 7 February 2017 at 10:25:13 UTC, Joakim wrote:
Maybe you just need to regenerate those pages in the cache or
something, but when I load both the links we gave and then
reload them, they're still broken for me.
On Wednesday, 23 March 2016 at 20:40:10 UTC, Joseph Rushton
Wakeling wrote:
On Saturday, 19 March 2016 at 07:41:16 UTC, Timothee Cour wrote:
can https://github.com/msoucy/dproto be used as a starting
point?
Out of curiosity, what's actually missing in dproto that a GSoC
project could address?
On Saturday, 19 March 2016 at 06:18:06 UTC, Rajat Kumar wrote:
Hello.
I am Rajat Kumar, a junior year university student from India.
I have working experiences in languages like C,C++ and Python.
I am really really interested in working in D language. I want
to work in the project - Flatbuffer
On Monday, 8 February 2016 at 13:25:38 UTC, CraigDillabaugh wrote:
Awesome! Thanks. I will write up something on the idea's page
in the next day or two (which you are welcome to edit of
course). Also, if a student were interested in working on
Protocol Buffers, would there be opportunities th
On Saturday, 6 February 2016 at 20:18:57 UTC, Craig Dillabaugh
wrote:
Anyone interested and capable of mentor a student interested in
doing FlatBuffers for D.
I could do that. Currently, as a side project, I'm working on
adding D support for Protocol Buffers v3 [1].
Main goals of the new des
On Thursday, 4 February 2016 at 08:29:46 UTC, Dragos Carp wrote:
I will prepare a PR for the binary function implementation.
The PR is ready for review:
https://github.com/D-Programming-Language/phobos/pull/3972
On Wednesday, 3 February 2016 at 16:39:26 UTC, Andrei
Alexandrescu wrote:
On 02/01/2016 03:46 AM, Dragos Carp wrote:
On Friday, 29 January 2016 at 20:40:18 UTC, Andrei
Alexandrescu wrote:
That'd be interesting if (a) lazy and (b) general a la
https://dlang.org/library/std/range/recurrence.html.
On Friday, 29 January 2016 at 20:40:18 UTC, Andrei Alexandrescu
wrote:
That'd be interesting if (a) lazy and (b) general a la
https://dlang.org/library/std/range/recurrence.html. -- Andrei
To be clear, by general you mean to allow functions with more
than 2 arguments?
For example if you have
On Friday, 29 January 2016 at 13:11:34 UTC, Luís Marques wrote:
Just to bikeshed a little, I remember that when I first started
using std.algorithm I was ctrl-F'ing for "accumulate" and not
finding it quite often. D competes with C++ directly, so do
consider that name :-)
But not in python, w
On Tuesday, 19 January 2016 at 11:56:38 UTC, tcak wrote:
On Tuesday, 19 January 2016 at 10:09:01 UTC, Ola Fosheim
Grøstad wrote:
On Monday, 18 January 2016 at 05:59:15 UTC, tcak wrote:
Is there anything like this in Phobos, or shall I start my
own implementation?
It isn't really clear to me w
On Saturday, 16 January 2016 at 16:43:35 UTC, Russel Winder wrote:
On Fri, 2016-01-15 at 21:13 +, Dibyendu Majumdar via
Digitalmars-d
wrote:
[…]
Hi - Thanks for this; I currently use CMake for C/C++
projects, but due to lack of support for D in CMake, planning
to migrate to premake.
Is
On Friday, 18 December 2015 at 13:15:54 UTC, Andrei Alexandrescu
wrote:
On 12/18/15 3:06 AM, Jacob Carlborg wrote:
On 2015-12-17 23:40, Andrei Alexandrescu wrote:
We are already using vibe.d for the Phobos page-per-name
documentation.
As far as I can tell the initiative has been a qualified
s
On Thursday, 26 November 2015 at 11:49:25 UTC, John Colvin wrote:
Pretty sure it works fine with anything that dub knows about.
dub add-path or dub add-local should put things on an even
footing with ~/.dub in that regard.
`dub add-path` and `dub add-local` permanently add the specified
pat
On Thursday, 26 November 2015 at 10:19:13 UTC, Mike Parker wrote:
This is not even an issue. IDEs can create a dub.json for all
new projects and call 'dub describe' on imported projects
without ever touching SDLang. Again, *there is no problem here*.
'dub describe' has one big issue. It work
On Thursday, 12 November 2015 at 13:42:36 UTC, Andrei
Alexandrescu wrote:
Could someone take up the task outlined in
https://issues.dlang.org/show_bug.cgi?id=15320 and
https://github.com/D-Programming-Language/phobos/pull/3804?
I assigned the issue to you. Thank you!! -- Andrei
PR is ready:
On Wednesday, 11 November 2015 at 18:43:01 UTC, Andrei
Alexandrescu wrote:
Could someone take up the task outlined in
https://issues.dlang.org/show_bug.cgi?id=15320 and
https://github.com/D-Programming-Language/phobos/pull/3804?
Thanks,
Andrei
If nobody already started, I'll do this today.
On Tuesday, 20 October 2015 at 13:18:39 UTC, Shriramana Sharma
wrote:
Since TypeTuple is now an alias of AliasSeq, I suppose it's OK
to replace all occurrences of TypeTuple in std.traits by
AliasSeq?
Unfortunately it is not so easy. I think that we can proceed to
replace `TypeTuple` in `std.t
On Monday, 22 June 2015 at 19:09:40 UTC, weaselcat wrote:
I never seem to use them for anything, has anyone else done
anything interesting with them?
https://github.com/linkrope/dunit#user-defined-attributes
On Saturday, 20 June 2015 at 12:35:11 UTC, weaselcat wrote:
I recently read this facebook post on their future
implementation in their Folly library.
https://code.facebook.com/posts/1661982097368498
This made me slightly envious. Thoughts on a D implementation?
Even if the callbacks are sequ
On Thursday, 18 June 2015 at 02:22:13 UTC, Vladimir Panteleev
wrote:
I would like to ask, what can we improve in our tooling and
infrastructure to lessen the burden on release czars?
Merge dmd, druntime, phobos repos.
On Monday, 1 June 2015 at 12:06:39 UTC, w0rp wrote:
...
If you are writing code where you just want to grab large
chunks of data from a socket at a time, and you don't care
about the rest of the code operating on characters, you can do
this.
someSocket.byChunk(bufferSize).joiner.doSomething;
Hardly. In fact, I've spent quite some time trying to figure
this out.
Doing bulk read to some array is the pushing burden of
maintaining
some buffer on the user and adding the overhead of extra copy
on
buffered streams. Not to mention that the more methods we put
in range
API the more if/el
On Sunday, 31 May 2015 at 22:53:58 UTC, Andrei Alexandrescu wrote:
There's some misunderstanding along the way. Input ranges use
buffering internally as a matter of course, nothing scary about
that. In addition to that, primitives that transfer data in
bulk are welcome too. That's how many lan
On Sunday, 31 May 2015 at 17:50:41 UTC, Dmitry Olshansky wrote:
On 31-May-2015 18:58, Andrei Alexandrescu wrote:
On 5/31/15 8:44 AM, Nick Sabalausky wrote:
On 05/30/2015 07:06 AM, short2cave wrote:
Do the classic streams still make sense when we have Ranges ?
I've been thinking the same thi
On Wednesday, 20 May 2015 at 16:45:44 UTC, Bastiaan Veelo wrote:
Bummer. I was looking forward to the streams.
Maybe somebody in the first rows can live-stream the keynotes, at
least.
A low-quality video or even just audio would suffice.
Last year a couple of colleagues watched the whole conf
On Thursday, 14 May 2015 at 16:28:01 UTC, Andrei Alexandrescu
wrote:
On 5/14/15 8:14 AM, Dragos Carp wrote:
On Wednesday, 13 May 2015 at 15:24:02 UTC, Andrei Alexandrescu
wrote:
It should be easy to update by the community, so a wiki might
be a
good start. So I saw three links, any others? -
On Wednesday, 13 May 2015 at 15:24:02 UTC, Andrei Alexandrescu
wrote:
It should be easy to update by the community, so a wiki might
be a good start. So I saw three links, any others? -- Andrei
My company have 2-3 positions open in Munich, unfortunately the
current job listing is just in Germ
On Tuesday, 28 April 2015 at 11:18:14 UTC, Gan wrote:
I found this: https://github.com/p0nce/dplug
Which seems to be a good analysis library but I haven't found a
library to play sounds.
Is there one?
https://github.com/D-Programming-Deimos/portaudio
On Thursday, 26 March 2015 at 17:41:58 UTC, w0rp wrote:
If enough people are interested and have a few suggestions for
some features they like which aren't crazy massive feature
lists, I'd be willing to expand it a bit, add some
documentation, and offer it as a DUB package.
Very nice! PlantUM
On Saturday, 14 March 2015 at 23:49:00 UTC, Walter Bright wrote:
On 3/14/2015 4:15 PM, Brian Schott wrote:
What am I missing?
I suggest defining "The One True Way" and have no configuration
options.
+1
You're right it did sound like that. It was partly preference
and partly a need for the circular buffer to solve futures and
promises following this issue:
Some weeks ago I made a PR [1] which adds popFrontN to
std.array.Appender transforming it in a circular buffer. Please
provide your feedb
BTW, CMake output support (using "dub generate cmake") has
recently been added to GIT master.
Very nice!
On Thursday, 5 February 2015 at 01:09:15 UTC, Andrei Alexandrescu
wrote:
On 2/4/15 4:50 PM, Jonathan Marler wrote:
On Thursday, 5 February 2015 at 00:42:01 UTC, Andrei
Alexandrescu wrote:
On 2/4/15 4:40 PM, Jonathan Marler wrote:
On Thursday, 5 February 2015 at 00:35:50 UTC, bearophile
wrote:
On Monday, 2 February 2015 at 16:26:45 UTC, Atila Neves wrote:
This thread has just made me decide to write a D build system,
in D and configured in D that builds on dub and its packages
intead of reinventing the wheel. I might ask the community for
inputs on requirements. Maybe this will be my
github and http://downloads.dlang.org/releases/2014/ say YES, but
http://dlang.org/ and
http://forum.dlang.org/group/digitalmars.D.announce say NO...
On Tuesday, 9 September 2014 at 22:41:39 UTC, Nick Sabalausky
wrote:
Most of that is unavoidable without salaried devs on it. D is
100% volunteer, deadlines and such aren't realistically
feasible.
I'm talking about the deadlines for your own PRs. If you miss one
release, you will have your c
On Tuesday, 9 September 2014 at 18:56:16 UTC, Brad Roberts via
Digitalmars-d wrote:
Of course the process can be better. But NONE of those are a
result of the repository split that you're advocating removing.
I think these are related. It will be a real challenge to keep in
sync three in par
On Tuesday, 9 September 2014 at 12:31:26 UTC, Dicebot wrote:
Also it sounds as if you think that someone actually does any
coordination about what must go into release. As far as I am
aware there is no such thing, even http://wiki.dlang.org/Agenda
is just a convention. Currently releases are ba
ne important (in my opinion) disadvantage misssing:
considerably harder PR maintenance (missing automatic
categorization and separation between phobos / dmd teams).
Being forced to look ar DMD pull requests to do Phobos
maintenance will add lot of context overhead for me.
This kind of attit
On Monday, 8 September 2014 at 21:55:47 UTC, Trass3r wrote:
You could also use submodules (or subtrees, haven't tried them
yet).
AFAIK the tags and branches does not work over
submodules/subtrees and you would still have 3 github repos with
3 pull request queues.
On Monday, 8 September 2014 at 21:03:07 UTC, Jeremy Powers via
Digitalmars-d wrote:
On Mon, Sep 8, 2014 at 12:51 PM, Dragos Carp via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:
It may sound a bit radical, but I think the release process can
be simplified a lot, if the 3
On Monday, 8 September 2014 at 20:56:51 UTC, Vladimir Panteleev
wrote:
On Monday, 8 September 2014 at 19:51:58 UTC, Dragos Carp wrote:
I have collected a few pros/cons about merging the
repositories:
This topic has been discussed in the past. Some more points
that I can think of:
Pro:
- si
On Monday, 8 September 2014 at 01:30:02 UTC, Andrei Alexandrescu
wrote:
Andrew Edwards has done a great job with the recent release,
but needs to step down because he's busy with other pursuits.
We need a release lieutenant who would carry us through the
release process. Please tender your app
Any links to quickly get into the topic? This is first time I
hear about
it.
What's really bad is that there is also CETA, which is an
agreement between the EU and Canada, and which is nothing than
an inconspicuous back door to achieve much of the same thing as
TTIP. Unfortunately it has g
isSliceOf -> yum
PR created:
https://github.com/D-Programming-Language/phobos/pull/2416
Correction: This is what I think you mean:
bool sliceOf(T)(in T[] part,
in T[] whole)
{
return (whole.ptr <= part.ptr &&
part.ptr + part.length <=
whole.ptr + whole.length);
}
Yes, of course. I had lhs, rhs and messed up the renaming of
those.
https://
On Monday, 11 August 2014 at 10:09:53 UTC, Nordlöw wrote:
On Monday, 11 August 2014 at 06:56:52 UTC, Dragos Carp wrote:
bool sliceOf(T)(in T[] whole, in T[] slice)
{
return whole.ptr <= slice.ptr &&
whole.ptr + slice.length <= whole.ptr + slice.length;
}
Correction: This is what I th
Nice work!
Implementation is at http://dpaste.dzfl.pl/a0effbaee0a9. For
historical reasons I've reused an undocumented function
sameHead.
sameHead is documented. I already use it a couple of times.
The algorithm assumes that "right" is a subrange of "whole"
sitting at its tail, ...
sameTa
On Wednesday, 30 July 2014 at 15:24:22 UTC, David Nadlinger wrote:
On Wednesday, 30 July 2014 at 15:21:12 UTC, Dragos Carp wrote:
As far as I recall, there was extensive bike-shedding about
this a while back. The decision (which I support) was to go
with std.experimental,
Sorry, probably thi
Now that I see several comments here seeking for certain
stability even in std.experimental and can understand why later
exposure can be a good thing. That, however, makes me even more
convinced that "experimental" is a terrible name for that
package and we are using it purely as staging are in
It does the right thing... there is an overload: without
additional arguments, the first argument (not necessary a
string) is not a format string.
Now if write a bug:
warning("there was an error because the file %s is missing!");
and I forgot the argument, no problem, it will run without
er
I'm in 100% disagreement. If you don't add the f suffix, users
will write:
info();
This is a crash if the user provided string happens to contains
"%s".
I wouldn't use such an API which makes format bugs hard to find.
It does the right thing... there is an overload: without
additional a
+1 for not having the conditional log
Not so sure about that. -- Andrei
I agree that the conditional could be useful. But I think that
the current API definition where we already have some strange
letter combinations ('l', 'c', 'f') is an one-way street, that
throws away some good possibili
Basically, limiting to string format logging limits to thinking
of logging
as purely strings. Using an API of 'list of items' decouples
it to the
more abstract 'logging stuff', with the actual string only
mattering for
final output.
This is really valid point.
There is still a problem: the a
Having consistency with the already existing write methods is a
good thing.
And having both options is useful, as some prefer one over the
other (and
you can do more interesting logging things with a list of items
to log when
you aren't restricted by a format string).
Could you provide an
This is a library: you can always add names, but it is very
hard
to remove them. If next version of std.logger should support
something like logFirstN or logEveryN (ideas from Google log
library). How this should look like? logfnf, logenf...?
c++ does not have foreach(i; 1 .. n)
Sorry that
I am kind of fine both ways, it is not that big deal but I
remember being very surprised that most common use case is
called `logf` and much less common - `log`. For `write`
function family common usage pattern is a bit different.
If we get rid of the write style variant, then you need to
re
* 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 chose
the mixin solution?
write infof("%b is the answer", true); and it works write now
This is clear... the argument was against "info" (without format
specifier).
there also good points for it.
* people expect it after using write
This is a different module. Btw. std.file.write looks completely
different :)
* so
On Sunday, 13 July 2014 at 13:37:13 UTC, Robert burner Schadek
wrote:
On Sunday, 13 July 2014 at 13:30:20 UTC, Dragos Carp wrote:
But creating x , necessary, function with only slightly
different names is also very non idiomatic D code. Anyway I'm
working on that.
For the conditional varian
But creating x , necessary, function with only slightly
different names is also very non idiomatic D code. Anyway I'm
working on that.
For the conditional variants, wouldn't be enough an overload with
the condition on the first position?
On Sunday, 13 July 2014 at 07:14:50 UTC, Jeremy Powers via
Digitalmars-d wrote:
... I'd almost always prefer a non-string-mixin solution.
... actually writing out the different signatures ...
+1
I also think that the usage of mixins in std.log is an "unforced
error" and non-idiomatic D
Yes, most definitely. e.g., there may be several serialization
libraries in code.dlang.org. But there would only ever be one
in std.experimental. It says "this is the one we are
considering for inclusion." By definition, more people would
use it, and consider it semi-official.
So this wil
On Tuesday, 6 May 2014 at 02:20:46 UTC, Lionello Lunesu wrote:
Hi all,
After last year's incident with my tires getting slashed, I'm
really hoping I can do without a car during this year's DConf.
How feasible is this?
I'll be staying at Aloft. Would be great if there's someone I
can share a
65 matches
Mail list logo
