On 15 June 2017 at 12:00, Jakob Bornecrantz via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:
> On Thursday, 15 June 2017 at 01:34:01 UTC, Manu wrote:
>
>> Hey people, I haven't checked in for a while, I'm yet again tempted to
>> use D for a small work thing, but I'll need LDC for it, and de
Proposal: support reading multiple files (with fake file names) from stdin.
This is a natural extension of
https://issues.dlang.org/show_bug.cgi?id=9287 (Issue 9287 - DMD should
read from stdin when an input file is "-")
Example use case:
* simplify writing bug reports and trying out other people
> Msgpack rpc with vibe.d works. We used it.
you mean with msgpackrpc-d? If so, it works, until you run into
https://github.com/msgpack-rpc/msgpack-rpc-d/issues/16 (when server
sends >= 4090 bytes, client hangs forever).
> we switched towards http + asdf
not sure what asdf is?
On Wed, Jun 1
On 6/14/17 6:02 PM, Ali Çehreli wrote:
On 06/14/2017 12:22 PM, Steven Schveighoffer wrote:
foreach(i, v; hashmap) => i is counter, v is value
Later hashmap adds support for iterating key and value. Now i is key, v
is value. Code means something completely different.
Compare with
foreach(i, v
On 6/14/17 6:46 PM, Luís Marques wrote:
On Wednesday, 14 June 2017 at 19:22:24 UTC, Steven Schveighoffer wrote:
For example:
foreach(i, v; hashmap) => i is counter, v is value
Later hashmap adds support for iterating key and value. Now i is key,
v is value. Code means something completely diff
On Thursday, 15 June 2017 at 01:34:01 UTC, Manu wrote:
Hey people, I haven't checked in for a while, I'm yet again
tempted to use D for a small work thing, but I'll need LDC for
it, and debuginfo needs to work or it's a non-starter.
Does anyone know where that stuff stands? What are the limits
Hey people, I haven't checked in for a while, I'm yet again tempted to use
D for a small work thing, but I'll need LDC for it, and debuginfo needs to
work or it's a non-starter.
Does anyone know where that stuff stands? What are the limits? Last I
checked, some MS guys were personally introducing
On Wednesday, 14 June 2017 at 19:55:49 UTC, Yawniek wrote:
Msgpack rpc with vibe.d works. We used it.
Its extremely fast, youll never get that speed with thrift.
I don't think Thrift is fundamentally much different in
performance than MessagePack, see e.g.
https://github.com/thekvs/cpp-serial
On 06/14/2017 03:48 PM, bachmeier wrote:
On Wednesday, 14 June 2017 at 22:02:30 UTC, Ali Çehreli wrote:
Then, perhaps we're arguing in favor of
* writing .enumerate even for slices (implying that automatic indexing
for them has been a historical artifact and code that wants to be
portable shou
On Wednesday, 14 June 2017 at 22:02:30 UTC, Ali Çehreli wrote:
Then, perhaps we're arguing in favor of
* writing .enumerate even for slices (implying that automatic
indexing for them has been a historical artifact and code that
wants to be portable should always write .enumerate)
* making s
On Wednesday, 14 June 2017 at 19:22:24 UTC, Steven Schveighoffer
wrote:
For example:
foreach(i, v; hashmap) => i is counter, v is value
Later hashmap adds support for iterating key and value. Now i
is key, v is value. Code means something completely different.
If we take a step back, I think
On 06/14/2017 12:22 PM, Steven Schveighoffer wrote:
> foreach(i, v; hashmap) => i is counter, v is value
>
> Later hashmap adds support for iterating key and value. Now i is key, v
> is value. Code means something completely different.
>
> Compare with
>
> foreach(i, v; hashmap.enumerate)
>
> Int
On Wednesday, 14 June 2017 at 20:35:15 UTC, Ola Fosheim Grøstad
wrote:
On Wednesday, 14 June 2017 at 12:22:36 UTC, Russel Winder wrote:
If a code is to be left untouched but the compiler not
archived then the code must be recompiled and amended as
needed with each new compiler that is accepted
On Wednesday, 14 June 2017 at 12:22:36 UTC, Russel Winder wrote:
On Wed, 2017-06-14 at 11:57 +, bachmeier via Digitalmars-d
wrote:
[…]
I've been using D for four years. I can still compile code
that compiled with DMD at that time, with only a few minor
modifications. I expect to be able
H. S. Teoh wrote:
On Wed, Jun 14, 2017 at 11:45:43PM +0300, ketmar via Digitalmars-d wrote:
Ola Fosheim Grøstad wrote:
On Wednesday, 14 June 2017 at 12:22:36 UTC, Russel Winder wrote:
If a code is to be left untouched but the compiler not archived
then the code must be recompiled and amended
On Wed, Jun 14, 2017 at 11:45:43PM +0300, ketmar via Digitalmars-d wrote:
> Ola Fosheim Grøstad wrote:
>
> > On Wednesday, 14 June 2017 at 12:22:36 UTC, Russel Winder wrote:
> > > If a code is to be left untouched but the compiler not archived
> > > then the code must be recompiled and amended as
Ola Fosheim Grøstad wrote:
On Wednesday, 14 June 2017 at 12:22:36 UTC, Russel Winder wrote:
If a code is to be left untouched but the compiler not archived then the
code must be recompiled and amended as needed with each new compiler
that is accepted in the workflow.
I don't disagree with th
On Wednesday, 14 June 2017 at 12:22:36 UTC, Russel Winder wrote:
If a code is to be left untouched but the compiler not archived
then the code must be recompiled and amended as needed with
each new compiler that is accepted in the workflow.
I don't disagree with the general sentiment than one
On Monday, 12 June 2017 at 18:12:38 UTC, Timothee Cour wrote:
any help on this would be most welcome:
https://github.com/msgpack-rpc/msgpack-rpc-d/issues/16
Unfortunately I find the RPC support in D lacking. Having a
good RPC integration for D is key for production use of D where
one wants to
On 6/14/17 12:35 PM, Luís Marques wrote:
On Wednesday, 14 June 2017 at 16:17:50 UTC, Steven Schveighoffer wrote:
I don't know if there is room to allow range-defined indexes and
foreach-defined indexes. foreach(a, b; someRange) has to do one or the
other. Otherwise, changes to how someRange oper
On 2017-06-14 11:38, Martin Nowak wrote:
Also without a proposed feature list this discussion is somewhat lame.
You only need one, AST macros ;)
--
/Jacob Carlborg
On Wednesday, 14 June 2017 at 12:48:14 UTC, Russel Winder wrote:
On Wed, 2017-06-14 at 10:40 +, gzp via Digitalmars-d wrote:
[…]
cas
in all api I've seen on a failed swap, the current value is
retrieved
(in c/c++ there are intrinsic for them)
This appears to be in core.atomic.
There is a
Hi,
On Tuesday, 13 June 2017 at 06:12:46 UTC, gzp wrote:
the docs are quite minimal
That's true. In fact, this applies not only to atomic intrinsics,
but all of `shared`. We need to sit down and properly specify
things at some point. Andrei has been trying to get an initiative
going to do j
On Wednesday, 14 June 2017 at 16:17:50 UTC, Steven Schveighoffer
wrote:
I think opApply is kind of a forgotten piece of the language
since ranges have been introduced. We could resurrect it quite
easily this way, as opApply with template parameters that
return another range does not conflict wi
On 6/14/17 11:42 AM, Luís Marques wrote:
On Wednesday, 14 June 2017 at 14:35:32 UTC, Steven Schveighoffer wrote:
What I'd rather see is a better mechanism for ranges (or things that
provide ranges) to hook the foreach syntax to allow better control and
power from ranges without using traditional
On Wednesday, 14 June 2017 at 15:25:55 UTC, Russel Winder wrote:
Using Meson for D projects is so wonderful. If SCons is to
catch up a lot of work is needed, and I am increasingly
worrying it isn't worth it. So much so that I am wondering if
adding Dub package getting support to Meson should be
On Wednesday, 14 June 2017 at 14:35:32 UTC, Steven Schveighoffer
wrote:
What I'd rather see is a better mechanism for ranges (or things
that provide ranges) to hook the foreach syntax to allow better
control and power from ranges without using traditional opApply.
For example, if we had:
fore
Using Meson for D projects is so wonderful. If SCons is to catch up a
lot of work is needed, and I am increasingly worrying it isn't worth
it. So much so that I am wondering if adding Dub package getting
support to Meson should be a higher priority that finishing adding it
to SCons. Of course this
On 6/13/17 10:42 PM, Luís Marques wrote:
On Tuesday, 13 June 2017 at 21:44:43 UTC, Steven Schveighoffer wrote:
But I think leaving the definition of the index up to the range itself
is paramount -- I don't want every range to be able to have a size_t
index, as that's not always what you want, an
On Wednesday, 14 June 2017 at 12:15:49 UTC, Russel Winder wrote:
On Wed, 2017-06-14 at 12:28 +0100, rikki cattermole via
Digitalmars-d wrote:
> [...]
Step back a moment. C++ and Java are trying to stop programmers
using these features, in favour of using higher level
abstractions. In C++ and
On Wednesday, 14 June 2017 at 12:08:16 UTC, Mike wrote:
* Rust is probably the best, but it doesn't have the modeling
power of D and C++.
A lot of the points you mention, i also agree with but
implementing that list is akin to writing a new language. You do
not trow out the baby with the bath
Actually I've just found an isue from 2015 (still in NEW state):
https://issues.dlang.org/show_bug.cgi?id=15007
I've updated and linked this forum.
I am fairly sure it isn't, but why is this needed if you use a
parallelism oriented approach to the architecture and design?
Sorry to repeat but whilst there are circumstances where this
stuff is needed (operating systems), most other applications
should be written without the need for locks, m
On 14/06/2017 1:48 PM, Russel Winder via Digitalmars-d wrote:
On Wed, 2017-06-14 at 13:27 +0100, rikki cattermole via Digitalmars-d
wrote:
[…]
Yes. A N.G. post will be forgotten about quickly, but an issue in
the
bug tracker can send you updates as things progress.
OK. Feel free to sign me
On Wed, 2017-06-14 at 13:27 +0100, rikki cattermole via Digitalmars-d
wrote:
>
[…]
> Yes. A N.G. post will be forgotten about quickly, but an issue in
> the
> bug tracker can send you updates as things progress.
OK. Feel free to sign me up for the issue.
> At the end of the day, that module gre
On Wed, 2017-06-14 at 10:40 +, gzp via Digitalmars-d wrote:
> After digging into it the source for me it seems as D is lacking
> a "standardized" atomic library. It has some basic concepts, but
> far behind the c++ standards.
> I don't know if there are any RFC-s in this topic but it requires
On Tuesday, 13 June 2017 at 06:12:46 UTC, gzp wrote:
But what about compare_exchange (CAS) ? In C++ one have to
provide Memory ordering for success and failure, but not in D.
I have some difficulty already to comprehend MemoryOrder.rel and
MemoryOrder.acq
A cas with MemoryOrder.raw wouldn't b
On 14/06/2017 1:15 PM, Russel Winder via Digitalmars-d wrote:
snip
I don't know if D compiler is aware of the fences and won't move
out/in
instructions from guarded areas.
Thanks: gzp
Please create an issue here: issues.dlang.org for druntime atomic
support.
Clearly the requirements that we
On Wed, 2017-06-14 at 11:57 +, bachmeier via Digitalmars-d wrote:
>
[…]
> I've been using D for four years. I can still compile code that
> compiled with DMD at that time, with only a few minor
> modifications. I expect to be able to do the same four years from
> now.
I suggest this is the
On Wed, 2017-06-14 at 12:28 +0100, rikki cattermole via Digitalmars-d
wrote:
> On 14/06/2017 11:40 AM, gzp wrote:
> > After digging into it the source for me it seems as D is lacking a
> > "standardized" atomic library. It has some basic concepts, but far
> > behind the c++ standards.
> > I don't
On Saturday, 10 June 2017 at 23:30:18 UTC, Liam McGillivray wrote:
I think it's about time for D3 to start developing.
I would love to see a fork of D2 that attempts to address some
obstacles I encountered when I was using D. However, it is quite
apparent that there is little to no interest
On Wednesday, 14 June 2017 at 11:34:09 UTC, Wulfklaue wrote:
Just changing the library to D3 and not the base D name will
result in people finding old code, not getting it to work,
getting frustrated and simply ignoring the language. Hey,
despite loving the syntax, did the exact same thing wit
On Tuesday, 13 June 2017 at 06:12:46 UTC, gzp wrote:
(...)
There is no consume in D.
What do you currently use for in C++?
It is temporarily deprecated in C++17.
On Wednesday, 14 June 2017 at 09:18:58 UTC, Jonathan M Davis
wrote:
If you're maintaining your code and making the occasional,
required adjustments when the language or library changes
something that requires adjustments, then you should be just
fine without having to do massive code rewrites o
On 14/06/2017 11:40 AM, gzp wrote:
After digging into it the source for me it seems as D is lacking a
"standardized" atomic library. It has some basic concepts, but far
behind the c++ standards.
I don't know if there are any RFC-s in this topic but it requires a lot
of work. Just to mention som
After digging into it the source for me it seems as D is lacking
a "standardized" atomic library. It has some basic concepts, but
far behind the c++ standards.
I don't know if there are any RFC-s in this topic but it requires
a lot of work. Just to mention some by my first experience:
cas
in a
On Saturday, 10 June 2017 at 23:30:18 UTC, Liam McGillivray wrote:
I'd be in favor of finally deprecating all sub-standard phobos
module (moving them to https://github.com/dlang/undeaD) to make
room for good implementations. Having a vacant place might be
more encouraging than to wait for some
On Wednesday, June 14, 2017 08:33:26 Jacob Carlborg via Digitalmars-d wrote:
> On 2017-06-14 06:50, Timothee Cour via Digitalmars-d wrote:
> > eg:
> > Error: no property 'IF_gray' for type 'ImageFormat'
> > =>
> > Error: no property 'IF_gray' for type 'foo.bar.ImageFormat'
> >
> > and also, why not
On Wednesday, June 14, 2017 07:28:34 Wulfklaue via Digitalmars-d wrote:
> Unless i am wrong there seem to be only one or two people
> actually pushing this D3 idea...
It comes up periodically, because there's some change that someone wants
that will never make it into D2. Historically, it's the re
http://forum.dlang.org/post/fyzwknqumopldikti...@forum.dlang.org
http://forum.dlang.org/post/xpmpakmusudanwuzz...@forum.dlang.org
https://issues.dlang.org/show_bug.cgi?id=9631
On Wed, Jun 14, 2017 at 10:21 AM, Nicholas Wilson via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:
> On Wednesda
On Wednesday, 14 June 2017 at 06:33:26 UTC, Jacob Carlborg wrote:
On 2017-06-14 06:50, Timothee Cour via Digitalmars-d wrote:
eg:
Error: no property 'IF_gray' for type 'ImageFormat'
=>
Error: no property 'IF_gray' for type 'foo.bar.ImageFormat'
and also, why not show where the symbol is defined
Wulfklaue wrote:
On Tuesday, 13 June 2017 at 20:51:37 UTC, ketmar wrote:
Patrick Schluter wrote:
the main reason for D3 is not language changes, but workarounding "don't
break user code" thingy. it is completely impossible to experiment
freely or introduce breaking changes in D2 (for a reason
On 14/06/2017 8:28 AM, Wulfklaue wrote:
On Tuesday, 13 June 2017 at 20:51:37 UTC, ketmar wrote:
Patrick Schluter wrote:
the main reason for D3 is not language changes, but workarounding
"don't break user code" thingy. it is completely impossible to
experiment freely or introduce breaking chang
On Tuesday, 13 June 2017 at 20:51:37 UTC, ketmar wrote:
Patrick Schluter wrote:
the main reason for D3 is not language changes, but
workarounding "don't break user code" thingy. it is completely
impossible to experiment freely or introduce breaking changes
in D2 (for a reason, there is nothing
It's a bit unfortunate that I found this after DConf. For those that
have a need to create slides/presentation and are tried of PowerPoint or
Keynote. This is the great tool.
Remark [1] is a tool that generates/converts Markdown into slides and
let you view them in the browser. It's really sim
55 matches
Mail list logo
