On Tuesday, 16 October 2018 at 21:12:39 UTC, welkam wrote:
On Tuesday, 16 October 2018 at 20:58:54 UTC, Jabari Zakiya
wrote:
And they could be modded to catch semantics like this and
produce faster code.
Its hard to prove that you will only write 1 or 0 in the array
and even if you write such
On Tue, Oct 16, 2018 at 05:10:38PM -0400, Nick Sabalausky (Abscissa) via
Digitalmars-d wrote:
> On 10/16/18 4:16 PM, notna wrote:
> > another interesting discussion [1]... and old/stale pull requests
> > are also discussed here now and then... not sure if this [2] is
> &
On 10/16/18 4:26 PM, Manu wrote:
On Tue, Oct 16, 2018 at 11:30 AM Steven Schveighoffer via
Digitalmars-d wrote:
On 10/16/18 2:10 PM, Manu wrote:
On Tue, Oct 16, 2018 at 6:35 AM Steven Schveighoffer via Digitalmars-d
wrote:
On 10/16/18 9:25 AM, Steven Schveighoffer wrote:
On 10/15/18 2:46
On Tuesday, 16 October 2018 at 20:58:54 UTC, Jabari Zakiya wrote:
And they could be modded to catch semantics like this and
produce faster code.
Its hard to prove that you will only write 1 or 0 in the array
and even if you write such pass it wont fire very often. So
slower compile times for
On 10/16/18 4:16 PM, notna wrote:
another interesting discussion [1]... and old/stale pull requests are
also discussed here now and then... not sure if this [2] is known to
many ppl?!
- [1] https://marc.info/?t=15392665871&r=1&w=2
- [2] https://github.com/probot/stale
I've encountered st
On Tuesday, 16 October 2018 at 17:48:42 UTC, Jabari Zakiya wrote:
On Tuesday, 16 October 2018 at 02:34:47 UTC, Jabari Zakiya
wrote:
Just updated Atom editor and noticed D files read as plain
.txt and no D bindings in list of programs. Maybe someone
should bring that to Atom's devs attention.
On Tuesday, 16 October 2018 at 20:38:24 UTC, welkam wrote:
On Tuesday, 16 October 2018 at 17:57:23 UTC, Jabari Zakiya
wrote:
This is the exact same behavior I found with the Nim compiler
too.
Well Nim compiler is more like translator. It translates Nim
code to c or c++. Since gcc was responsi
On Tuesday, 16 October 2018 at 17:57:23 UTC, Jabari Zakiya wrote:
This is the exact same behavior I found with the Nim compiler
too.
Well Nim compiler is more like translator. It translates Nim code
to c or c++. Since gcc was responsible for optimizations and
instruction selection it would be
On Tue, Oct 16, 2018 at 11:30 AM Steven Schveighoffer via
Digitalmars-d wrote:
>
> On 10/16/18 2:10 PM, Manu wrote:
> > On Tue, Oct 16, 2018 at 6:35 AM Steven Schveighoffer via Digitalmars-d
> > wrote:
> >>
> >> On 10/16/18 9:25 AM, Steven Schveighoffer wr
another interesting discussion [1]... and old/stale pull requests
are also discussed here now and then... not sure if this [2] is
known to many ppl?!
- [1] https://marc.info/?t=15392665871&r=1&w=2
- [2] https://github.com/probot/stale
On Monday, 15 October 2018 at 21:26:52 UTC, solidstate1991 wrote:
I have done two mistakes: I underestimated the scope of the
project and overestimated my capabilities. This caused a chain
reaction, which in turn made the first milestone unreachable.
You've done the right thing by facing the s
On Tuesday, 16 October 2018 at 07:09:05 UTC, Vijay Nayar wrote:
On Monday, 15 October 2018 at 22:17:57 UTC, Jabari Zakiya wrote:
$ dub build --compiler=ldc2 -b=release && echo "30" |
./twinprimes
Enter integer number:
threads = 8
each thread segment is [1 x 65536] bytes array
twinprime
On 10/16/18 2:10 PM, Manu wrote:
On Tue, Oct 16, 2018 at 6:35 AM Steven Schveighoffer via Digitalmars-d
wrote:
On 10/16/18 9:25 AM, Steven Schveighoffer wrote:
On 10/15/18 2:46 PM, Manu wrote:
From there, it opens up another critical opportunity; T* -> shared(T)*
promotion.
Const wo
On Tue, Oct 16, 2018 at 6:35 AM Steven Schveighoffer via Digitalmars-d
wrote:
>
> On 10/16/18 9:25 AM, Steven Schveighoffer wrote:
> > On 10/15/18 2:46 PM, Manu wrote:
>
> >>> From there, it opens up another critical opportunity; T* -> shared(T)*
> >>
On Tue, Oct 16, 2018 at 6:25 AM Timon Gehr via Digitalmars-d
wrote:
>
> On 16.10.2018 13:04, Dominikus Dittes Scherkl wrote:
> > On Tuesday, 16 October 2018 at 10:15:51 UTC, Timon Gehr wrote:
> >> On 15.10.2018 20:46, Manu wrote:
> >>>
> >>> Assu
On Tuesday, 16 October 2018 at 16:57:12 UTC, welkam wrote:
So I run profiler and 97% of time is spent in void twinsSieve
function and hotspots are seg[k] = seg[k] | 1; lines. Since
seg[k] can only be 1 or 0 I removed that or operation. And the
results are. Queue the drum-roll... 5% slower.
I
On Tuesday, 16 October 2018 at 02:34:47 UTC, Jabari Zakiya wrote:
Just updated Atom editor and noticed D files read as plain .txt
and no D bindings in list of programs. Maybe someone should
bring that to Atom's devs attention.
Interesting, since my main editor, KDE's Kate, does have D file
sy
On Tuesday, 16 October 2018 at 07:09:05 UTC, Vijay Nayar wrote:
D has multiple compilers, but for the speed of the finished
binary, LDC2 is generally recommended. I used version 1.11.0.
https://github.com/ldc-developers/ldc/releases/tag/v1.11.0
I was using DUB to manage the project, but to b
On Tue, Oct 16, 2018 at 3:20 AM Timon Gehr via Digitalmars-d
wrote:
>
> On 15.10.2018 20:46, Manu wrote:
> >
> > Assuming the rules above: "can't read or write to members", and the
> > understanding that `shared` methods are expected to have threadsafe
On Tue, Oct 16, 2018 at 2:25 AM Kagamin via Digitalmars-d
wrote:
>
> On Monday, 15 October 2018 at 18:46:45 UTC, Manu wrote:
> > Current situation where you can arbitrarily access shared
> > members
> > undermines any value it has.
>
> The value of shared is existen
So I run profiler and 97% of time is spent in void twinsSieve
function and hotspots are seg[k] = seg[k] | 1; lines. Since
seg[k] can only be 1 or 0 I removed that or operation. And the
results are. Queue the drum-roll... 5% slower.
I thought that all of my studying was getting somewhere. That
On Tuesday, 16 October 2018 at 03:42:13 UTC, Russel Winder wrote:
Hi,
I am doing a presentation looking at DVB, GTK+, GStreamer, C,
C++, gtkmm, D, GtkD, GStreamerD, Rust, gtk-rs, and gstreamer-rs
in Norwich 2018-11-07. Anyone who wants to come and heckle
about ditching D and switching to Rust
On Monday, 15 October 2018 at 21:26:52 UTC, solidstate1991 wrote:
I try to resume my work on improving mago, but on a much
smaller scale and lower priority since I have to spend time
finding a job, which is a very hard thing in this fascist
country called Hungary, while also not supporting sa
On Tuesday, 16 October 2018 at 11:42:55 UTC, Tony wrote:
On Monday, 15 October 2018 at 08:21:11 UTC, Eugene Wissner
He doesn't argue against garbage collection.
Thanks, Eugene, I was starting to lose hope in humanity.
Well, can you state what he does argue against?
I did state what I was
On Monday, 15 October 2018 at 21:26:52 UTC, solidstate1991 wrote:
I have done two mistakes: I underestimated the scope of the
project and overestimated my capabilities. This caused a chain
reaction, which in turn made the first milestone unreachable.
Hello,
Just to say you seem like a nice
On 10/16/18 9:25 AM, Steven Schveighoffer wrote:
On 10/15/18 2:46 PM, Manu wrote:
From there, it opens up another critical opportunity; T* -> shared(T)*
promotion.
Const would be useless without T* -> const(T)* promotion. Shared
suffers a similar problem.
If you write a lock-free queue for in
On 10/15/18 2:46 PM, Manu wrote:
Okay, so I've been thinking on this for a while... I think I have a
pretty good feel for how shared is meant to be.
1. shared should behave exactly like const, except in addition to
inhibiting write access, it also inhibits read access.
I think this is the found
On 16.10.2018 13:04, Dominikus Dittes Scherkl wrote:
On Tuesday, 16 October 2018 at 10:15:51 UTC, Timon Gehr wrote:
On 15.10.2018 20:46, Manu wrote:
Assuming the rules above: "can't read or write to members", and the
understanding that `shared` methods are expected to have threadsafe
implement
On Tuesday, 16 October 2018 at 03:00:21 UTC, Manu wrote:
I don't see how an *implicit* cast can be a restriction. At
all.
Because a shared pointer can't access anything.
You can't do anything with a shared instance, so the can be no
harm done.
That just doesn't compute. You obviously *can*
On Sunday, 14 October 2018 at 15:27:07 UTC, Michael Coulombe
wrote:
On Sunday, 14 October 2018 at 14:35:36 UTC, lngns wrote:
On Sunday, 14 October 2018 at 13:18:37 UTC, lngns wrote:
That would require introducing a new type
Or just use int with a negative number... That's how it's done
in so
On Monday, 15 October 2018 at 08:21:11 UTC, Eugene Wissner wrote:
On Monday, 15 October 2018 at 05:26:56 UTC, Tony wrote:
Ideally you wouldn’t have chosen to even try D. You (and
others who spend so much time arguing against garbage
collection on a forum for a language designed with garbage
On Tuesday, 16 October 2018 at 10:15:51 UTC, Timon Gehr wrote:
On 15.10.2018 20:46, Manu wrote:
Assuming the rules above: "can't read or write to members",
and the
understanding that `shared` methods are expected to have
threadsafe
implementations (because that's the whole point), what are th
On 15.10.2018 20:46, Manu wrote:
Assuming the rules above: "can't read or write to members", and the
understanding that `shared` methods are expected to have threadsafe
implementations (because that's the whole point), what are the risks
from allowing T* -> shared(T)* conversion?
Unshared bec
On Sunday, 14 October 2018 at 12:14:06 UTC, bioinfornatics wrote:
Dear,
Some projects seem to have an extra directory for their include
directory, such as:
- stdx-allocator
- containers
- msgpack
- dparse
...
[...]
up
On Monday, 15 October 2018 at 18:46:45 UTC, Manu wrote:
Current situation where you can arbitrarily access shared
members
undermines any value it has.
The value of shared is existence of thread-local data that's
guaranteed to be not shared, so you don't need to worry about
thread-local data
On 2018-10-15 20:46, Manu wrote:
1. traditional; assert that the object become thread-local by
acquiring a lock, cast shared away
Instead of having to explicitly cast away shared we could leverage the
synchronized statement. It could be enhanced to allow the following:
shared int a;
Mutex m
On Monday, 15 October 2018 at 22:17:57 UTC, Jabari Zakiya wrote:
$ dub build --compiler=ldc2 -b=release && echo "30" |
./twinprimes
Enter integer number:
threads = 8
each thread segment is [1 x 65536] bytes array
twinprime candidates = 175324676; resgroups = 1298702
each 135 threads has
On Mon, Oct 15, 2018 at 8:55 PM Isaac S. via Digitalmars-d
wrote:
>
> On Tuesday, 16 October 2018 at 02:26:04 UTC, Manu wrote:
> >> I understand your point but I think the current shared (no
> >> implicit conversion) has its uses. It can be quite useful to
> >&g
--- ct_beer.d
static foreach_reverse(beer; 1..100)
{
pragma(msg, beer, " bottles of beer on the wall, ", beer, "
bottles of beer. Take one down, pass it around, ", beer-1, "
bottles of beer on the wall.");
}
void main(){}
---
On Tuesday, 16 October 2018 at 02:26:04 UTC, Manu wrote:
I understand your point but I think the current shared (no
implicit conversion) has its uses. It can be quite useful to
have one interface for when an object is shared and one for
when it is not (one with and without the synchronization
Hi,
I am doing a presentation looking at DVB, GTK+, GStreamer, C, C++, gtkmm, D,
GtkD, GStreamerD, Rust, gtk-rs, and gstreamer-rs in Norwich 2018-11-07. Anyone
who wants to come and heckle about ditching D and switching to Rust is most
welcome.
https://www.meetup.com/Norfolk-Developers-NorDev/ev
On Mon, Oct 15, 2018 at 7:25 PM Stanislav Blinov via Digitalmars-d
wrote:
>
> On Tuesday, 16 October 2018 at 00:15:54 UTC, Manu wrote:
> > On Mon, Oct 15, 2018 at 4:35 PM Stanislav Blinov via
> > Digitalmars-d wrote:
>
> >> What?!? So... my unshared methods shoul
I don't understand what is addthis
Just updated Atom editor and noticed D files read as plain .txt
and no D bindings in list of programs. Maybe someone should bring
that to Atom's devs attention.
Interesting, since my main editor, KDE's Kate, does have D file
syntax highlighting.
On Mon, Oct 15, 2018 at 7:15 PM Isaac S. via Digitalmars-d
wrote:
>
> On Tuesday, 16 October 2018 at 00:36:12 UTC, Manu wrote:
> > *snip*
> >
> > Yes, except maybe I didn't make it clear that I DO expect the
> > un-shared methods to be aware that a sibling sh
On Tuesday, 16 October 2018 at 00:15:54 UTC, Manu wrote:
On Mon, Oct 15, 2018 at 4:35 PM Stanislav Blinov via
Digitalmars-d wrote:
What?!? So... my unshared methods should also perform all
that's necessary for `shared` methods?
Of course! You're writing a threadsafe object... how
On Monday, 15 October 2018 at 21:26:52 UTC, solidstate1991 wrote:
I have done two mistakes: I underestimated the scope of the
project and overestimated my capabilities. This caused a chain
reaction, which in turn made the first milestone unreachable.
[...]
Have you tried melatonin? My doctor
On Tuesday, 16 October 2018 at 00:36:12 UTC, Manu wrote:
*snip*
Yes, except maybe I didn't make it clear that I DO expect the
un-shared methods to be aware that a sibling shared method does
exist
(you wrote it!), and that it may manipulate some state, so *if*
the
un-shared method does interact
On Mon, Oct 15, 2018 at 5:10 PM Nicholas Wilson via Digitalmars-d
wrote:
>
> On Monday, 15 October 2018 at 23:30:43 UTC, Stanislav Blinov
> wrote:
> > On Monday, 15 October 2018 at 21:51:43 UTC, Manu wrote:
> >
> >> I see it this way:
> >> If your object ha
On Mon, Oct 15, 2018 at 4:35 PM Stanislav Blinov via Digitalmars-d
wrote:
>
> On Monday, 15 October 2018 at 21:51:43 UTC, Manu wrote:
>
> > If a shared method is incompatible with an unshared method,
> > your class is broken.
>
> What?!? So... my unshared methods sho
On Monday, 15 October 2018 at 23:30:43 UTC, Stanislav Blinov
wrote:
On Monday, 15 October 2018 at 21:51:43 UTC, Manu wrote:
If a shared method is incompatible with an unshared method,
your class is broken.
What?!? So... my unshared methods should also perform all
that's necessary for `shared
On Mon, Oct 15, 2018 at 4:25 PM Peter Alexander via Digitalmars-d
wrote:
>
> On Monday, 15 October 2018 at 20:53:32 UTC, Manu wrote:
> > On Mon, Oct 15, 2018 at 1:05 PM Peter Alexander via
> > Digitalmars-d wrote:
> >>
> >> On Monday, 15 October 2018 at 18:46:
On Monday, 15 October 2018 at 21:51:43 UTC, Manu wrote:
If a shared method is incompatible with an unshared method,
your class is broken.
What?!? So... my unshared methods should also perform all that's
necessary for `shared` methods?
Explicit casting doesn't magically implement thread-saf
On Monday, 15 October 2018 at 20:53:32 UTC, Manu wrote:
On Mon, Oct 15, 2018 at 1:05 PM Peter Alexander via
Digitalmars-d wrote:
On Monday, 15 October 2018 at 18:46:45 UTC, Manu wrote:
1. A single producer, single consumer (SPSC) queue is
necessarily shared, but is only safe if there is one
$ dub build --compiler=ldc2 -b=release && echo "30" |
./twinprimes
Enter integer number:
threads = 8
each thread segment is [1 x 65536] bytes array
twinprime candidates = 175324676; resgroups = 1298702
each 135 threads has nextp[2 x 5566] array
setup time = 1 ms, 864 μs, and 7 hnsecs
perf
On Mon, Oct 15, 2018 at 2:25 PM Stanislav Blinov via Digitalmars-d
wrote:
>
> On Monday, 15 October 2018 at 20:57:46 UTC, Manu wrote:
> > On Mon, Oct 15, 2018 at 1:15 PM Stanislav Blinov via
> > Digitalmars-d wrote:
> >>
> >> On Monday, 15 Octo
I have done two mistakes: I underestimated the scope of the
project and overestimated my capabilities. This caused a chain
reaction, which in turn made the first milestone unreachable.
At the same time, my sleep disorder became even worse. I started
to sleep 10-12 hours a day while spending ar
On Monday, 15 October 2018 at 20:57:46 UTC, Manu wrote:
On Mon, Oct 15, 2018 at 1:15 PM Stanislav Blinov via
Digitalmars-d wrote:
On Monday, 15 October 2018 at 18:46:45 UTC, Manu wrote:
> Assuming the rules above: "can't read or write to members",
> and the under
On Monday, 15 October 2018 at 21:08:38 UTC, Manu wrote:
On Mon, Oct 15, 2018 at 2:05 PM Nicholas Wilson via
Digitalmars-d wrote:
I'm saying that while what you propose sounds very reasonable,
we should make sure that reading immutable variables is still
good ;)
I don't think what
On Mon, Oct 15, 2018 at 2:05 PM Nicholas Wilson via Digitalmars-d
wrote:
>
> On Monday, 15 October 2018 at 20:54:12 UTC, jmh530 wrote:
> > On Monday, 15 October 2018 at 20:44:35 UTC, Manu wrote:
> >> snip
> >>
> >> Are you saying `is(immutable(int) == sha
On Monday, 15 October 2018 at 20:54:12 UTC, jmh530 wrote:
On Monday, 15 October 2018 at 20:44:35 UTC, Manu wrote:
snip
Are you saying `is(immutable(int) == shared) == true)` ??
From the spec:
"Applying any qualifier to immutable T results in immutable T.
This makes immutable a fixed point of
On Mon, Oct 15, 2018 at 1:15 PM Stanislav Blinov via Digitalmars-d
wrote:
>
> On Monday, 15 October 2018 at 18:46:45 UTC, Manu wrote:
>
> > Assuming the rules above: "can't read or write to members", and
> > the understanding that `shared` methods
On Monday, 15 October 2018 at 20:44:35 UTC, Manu wrote:
snip
Are you saying `is(immutable(int) == shared) == true)` ??
From the spec:
"Applying any qualifier to immutable T results in immutable T.
This makes immutable a fixed point of qualifier combinations and
makes types such as const(immu
On Mon, Oct 15, 2018 at 1:05 PM Peter Alexander via Digitalmars-d
wrote:
>
> On Monday, 15 October 2018 at 18:46:45 UTC, Manu wrote:
> > Destroy...
>
> What you describe sounds better than what we currently have.
>
> I have at least two concerns:
>
> 1. A single p
On 10/15/2018 08:46 PM, Manu wrote:
1. traditional; assert that the object become thread-local by
acquiring a lock, cast shared away
2. object may have shared methods; such methods CAN be called on
shared instances. such methods may internally implement
synchronisation to perform their function.
I don't actually understand the underlying algorithm, but I at
least understand the flow of the program and the structure.
The algorithm utilized depends heavily on using shared memory
access, which can be done in D, but I definitely wouldn't call
it idiomatic. In D, message passing is prefer
On Mon, Oct 15, 2018 at 12:45 PM Nicholas Wilson via Digitalmars-d
wrote:
>
> On Monday, 15 October 2018 at 18:46:45 UTC, Manu wrote:
> > Destroy...
>
> Keep in mind immutable is implicitly shared (i.e. not in tls)
> because nobody can change it. It should stay readable fo
On Monday, 15 October 2018 at 20:22:54 UTC, Stanislav Blinov
wrote:
Neither are of any particular use.
Pot called, he wants to see Mr. kettle.
On Monday, 15 October 2018 at 18:46:45 UTC, Manu wrote:
If you write a lock-free queue for instance, and all the
methods are
`shared` (ie, threadsafe), then under the current rules, you
can't
interact with the object when it's not shared, and that's fairly
useless.
Unless the compiler can show
On Monday, 15 October 2018 at 20:12:47 UTC, 12345swordy wrote:
On Monday, 15 October 2018 at 19:57:59 UTC, Stanislav Blinov
wrote:
If you want to have an argument, I suggest you stop quote
mining and start paying attention.
If you wanted an argument from me, then you need to stop with
the "LO
On Monday, 15 October 2018 at 18:46:45 UTC, Manu wrote:
Assuming the rules above: "can't read or write to members", and
the understanding that `shared` methods are expected to have
threadsafe implementations (because that's the whole point),
what are the risks from allowing T* -> shared(T)* co
On Monday, 15 October 2018 at 19:57:59 UTC, Stanislav Blinov
wrote:
If you want to have an argument, I suggest you stop quote
mining and start paying attention.
If you wanted an argument from me, then you need to stop with the
"LOL YOU MAD BRO" rhetoric.
On Monday, 15 October 2018 at 18:46:45 UTC, Manu wrote:
Destroy...
What you describe sounds better than what we currently have.
I have at least two concerns:
1. A single producer, single consumer (SPSC) queue is necessarily
shared, but is only safe if there is one writing thread and one
rea
On Monday, 15 October 2018 at 18:00:24 UTC, 12345swordy wrote:
On Monday, 15 October 2018 at 17:30:28 UTC, Stanislav Blinov
wrote:
On Monday, 15 October 2018 at 16:46:45 UTC, 12345swordy wrote:
On Monday, 15 October 2018 at 00:02:31 UTC, Stanislav Blinov
wrote:
I'm arrogants, huh?
When you sa
On Sunday, 14 October 2018 at 10:51:11 UTC, Vijay Nayar wrote:
Once I get the bugs out, I'm curious to see if any performance
differences crop up. There's the theory that says they should
be the same, and then there's the practice.
I don't actually understand the underlying algorithm, but I a
On Monday, 15 October 2018 at 18:46:45 UTC, Manu wrote:
Destroy...
Keep in mind immutable is implicitly shared (i.e. not in tls)
because nobody can change it. It should stay readable for this
reason.
On Monday, 15 October 2018 at 18:46:45 UTC, Manu wrote:
Okay, so I've been thinking on this for a while... I think I
have a pretty good feel for how shared is meant to be.
1. shared should behave exactly like const, except in addition
to inhibiting write access, it also inhibits read access.
On Monday, 15 October 2018 at 19:14:58 UTC, Peter Alexander wrote:
On Monday, 15 October 2018 at 18:46:45 UTC, Manu wrote:
2. object may have shared methods; such methods CAN be called
on
shared instances. such methods may internally implement
synchronisation to perform their function. perhaps
On Mon, Oct 15, 2018 at 12:15 PM Peter Alexander via Digitalmars-d
wrote:
>
> On Monday, 15 October 2018 at 18:46:45 UTC, Manu wrote:
> > 2. object may have shared methods; such methods CAN be called on
> > shared instances. such methods may internally implement
> > sy
On Mon, Oct 15, 2018 at 12:15 PM Peter Alexander via Digitalmars-d
wrote:
>
> On Monday, 15 October 2018 at 18:46:45 UTC, Manu wrote:
> > 2. object may have shared methods; such methods CAN be called on
> > shared instances. such methods may internally implement
> > sy
On Monday, 15 October 2018 at 18:46:45 UTC, Manu wrote:
2. object may have shared methods; such methods CAN be called on
shared instances. such methods may internally implement
synchronisation to perform their function. perhaps methods of a
lock-free queue structure for instance, or operator over
Okay, so I've been thinking on this for a while... I think I have a
pretty good feel for how shared is meant to be.
1. shared should behave exactly like const, except in addition to
inhibiting write access, it also inhibits read access.
I think this is the foundation for a useful definition for s
On Monday, 15 October 2018 at 17:30:28 UTC, Stanislav Blinov
wrote:
On Monday, 15 October 2018 at 16:46:45 UTC, 12345swordy wrote:
On Monday, 15 October 2018 at 00:02:31 UTC, Stanislav Blinov
wrote:
I'm arrogants, huh?
When you say statements like this.
you don't give a flying duck about your
On Monday, 15 October 2018 at 16:46:45 UTC, 12345swordy wrote:
On Monday, 15 October 2018 at 00:02:31 UTC, Stanislav Blinov
wrote:
I'm arrogants, huh?
When you say statements like this.
you don't give a flying duck about your impact on the industry.
It come across as condescending and arroga
On Monday, 15 October 2018 at 00:02:31 UTC, Stanislav Blinov
wrote:
I'm arrogants, huh?
When you say statements like this.
you don't give a flying duck about your impact on the industry.
It come across as condescending and arrogant.
import std.format;
template Bootle(alias Beer = 0)
{
static if(Beer < 99)
enum Bootle = Bootle!(Beer + 1);
else
enum Bootle = Beer;
pragma(msg,
format!"%d bottles of beer on the wall, %d bottles of beer.
Take one down, pass it around, %d bottles of beer on the wall."
On Monday, 15 October 2018 at 10:11:15 UTC, rjframe wrote:
On Sat, 13 Oct 2018 12:22:29 +, Stanislav Blinov wrote:
And?.. Would you now go around preaching how awesome the GC is
and that everyone should use it?
For something like I did, yes.
The article the OP links to may want GC for e
On 10/14/18 7:36 AM, notna wrote:
Hi D gurus.
Did read an interesting post form GitLab [1] how they improved
performance by 30x by just going to go_v1.9... because they again went
from "fork" to "posix_spawn"...
I've searched the GitHub DLANG org for "posix_spawn" and didn't find a
hit... s
On Monday, 15 October 2018 at 07:23:07 UTC, Laurent Tréguier
wrote:
If it's about old programs, then Windows should apply their
hacks only for old executables.
It kinda does - this only applies to 32 bit exes without a
manifest resource. If you compile with -m64, it will go away, or
if you ad
On Sat, 13 Oct 2018 12:22:29 +, Stanislav Blinov wrote:
> On Saturday, 13 October 2018 at 12:15:07 UTC, rjframe wrote:
>
>> ...I didn't even keep the script; I'll never need it again. There are
>> times when the easy or simple solution really is the best one for the
>> task at hand.
>
> And?
On Sunday, 14 October 2018 at 17:33:37 UTC, Petar Kirov
[ZombineDev] wrote:
I'll look into making a pull request to druntime about
posix_spawn [..]
Here's the full deal:
https://github.com/dlang/druntime/pull/2329/files
with support for:
Linux Glibc
Linux Bionic libc
Linux Musl libc
Linux uC
On Thursday, 11 October 2018 at 23:17:15 UTC, Jonathan Marler
wrote:
For example, the "Conditional operator" in D actually has a
higher priority than an assignment, but in C++ it's the same
and is evaluated right-to-left. So this expression would be
different in C++ and D:
a ? b : c = d
In
On Monday, 15 October 2018 at 05:26:56 UTC, Tony wrote:
On Sunday, 14 October 2018 at 07:51:09 UTC, Stanislav Blinov
wrote:
That's a lamest excuse if I ever seen one. If you can't be
bothered to acquire one of the most relevant skills for
writing code for modern systems, then:
a) Ideally, y
On Sunday, 14 October 2018 at 17:49:11 UTC, Adam D. Ruppe wrote:
On Sunday, 14 October 2018 at 15:46:57 UTC, Laurent Tréguier
wrote:
Why should an OS decide whether an executable should be run
with admin privileges ? If it has to, then it's up to the
developer to explicitly ask for it...
Wind
On 10/15/18 2:00 AM, Nick Sabalausky (Abscissa) wrote:
Unfortunately, Tilix doesn't appear to support using envvars from the
current terminal in the custom command above (if that would even be
possible), so I'll have to manually change SESSION_NAME_HERE to my
KDevelop session name once per sess
On 10/14/18 10:31 PM, Gerald wrote:
Tilix supports this. You can define a custom regex and then use the
values extracted by the regex to launch an editor to load the file at
the right line number.
https://gnunn1.github.io/tilix-web/manual/customlinks/
The screenshot shows a configuration th
On 10/14/18 10:28 PM, Basile B. wrote:
VTE can certainly do this. It's the library many people use to embed a
terminal in their app (or to make terminals, like Tilix). You can look
at the API to get a better idea of what's possible
https://developer.gnome.org/vte/0.48/VteTerminal.html. Click
On Sunday, 14 October 2018 at 07:51:09 UTC, Stanislav Blinov
wrote:
That's a lamest excuse if I ever seen one. If you can't be
bothered to acquire one of the most relevant skills for writing
code for modern systems, then:
a) Ideally, you shouldn't be writing code
b) At the very least, you're
On Sunday, 14 October 2018 at 23:28:04 UTC, Nick Sabalausky
(Abscissa) wrote:
But it just occurred to me: There's no reason any ordinary
terminal emulator couldn't be written to do the same thing. A
setting for a custom regex to look for, another setting for a
command to run when the line is cl
On Sunday, 14 October 2018 at 23:28:04 UTC, Nick Sabalausky
(Abscissa) wrote:
Was just thinking about this: I've often liked the idea of
having a terminal emulator built-into my code editor, so it
could auto-highlight errors/etc and do jump-to-line on ANY
variation of build command, without hav
401 - 500 of 90926 matches
Mail list logo
