Am Fri, 22 Apr 2016 01:53:02 +
schrieb Adam D. Ruppe :
> On Friday, 22 April 2016 at 00:35:21 UTC, Mithun Hunsur wrote:
> > supporting the presentation rather than _being_ the
> > presentation).
>
> Powerpoints have a bad habit of damaging presentations rather
> than supporting them...
>
On Wednesday, 20 April 2016 at 07:53:53 UTC, Benjamin Thaut wrote:
Is there a official presentation template for Dconf 2016? If
not it would be greate if someone could create one. Many
programmers (me included) are not good with picking colors and
thus presentations usually don't look as good a
On Thursday, 21 April 2016 at 15:41:17 UTC, Matthias Klumpp wrote:
Asgen is super-boring code ;-) Mainly because the task it
performs can be represented without using much black magic.
One interesting possibility with D is that you can test what
performance impact boundschecking has on your co
I am referring to threads [1], [2] and [3].
1. DlangUI is making progress and looks very promising. Is there
any chance that the DLang foundation/community would embrace this
project (more manpower)? I've been fiddling around with GUIs a
bit recently. GtkD is great and all the other wrappers a
On 04/22/2016 01:42 PM, Chris wrote:
> I am referring to threads [1], [2] and [3].
>
> 1. DlangUI is making progress and looks very promising. Is there any
> chance that the DLang foundation/community would embrace this project
> (more manpower)?
Common misconception is that D team has any manpow
FYI: I don't want to comment here for now because Debian packaging is
very different from Arch packaging but I am keeping my eyes on the thread :)
On 04/18/2016 07:13 PM, Dejan Lekic wrote:
> On Sunday, 17 April 2016 at 06:10:34 UTC, Ilya Yaroshenko wrote:
>> We plan to add a set of numeric packages and this would be real pain
>> if they would be one-by-one moved from experimental to stable std. So
>> sci.* should be considered as experimenta
On Friday, 22 April 2016 at 10:59:16 UTC, Dicebot wrote:
On 04/22/2016 01:42 PM, Chris wrote:
I am referring to threads [1], [2] and [3].
1. DlangUI is making progress and looks very promising. Is
there any chance that the DLang foundation/community would
embrace this project (more manpower)?
D has taken some giant steps
s/taken/made
On Friday, 22 April 2016 at 09:18:48 UTC, Kagamin wrote:
Looks like an LDC bug.
Or not. If template constraint doesn't match, the error should be
"template instance does not match template declaration".
On 04/22/2016 02:34 PM, Chris wrote:
>> Common misconception is that D team has any manpower it can
>> potentially invest into promising projects. It doesn't. Some
>> volunteers are more commited than others but there is no one (not even
>> Andrei or Walter) who can tell others what spend their tim
On Friday, 22 April 2016 at 11:46:12 UTC, Dicebot wrote:
But who are those "we" you refer to? :) Or, to rephrase, do you
really envision a volunteer abandoning any project/task he has
current personal interest in to work on some third-party
project (he doesn't need) because of its strategical
On Monday, 18 April 2016 at 15:15:26 UTC, Atila Neves wrote:
Here's[1] another attempt at converting the Makefile for POSIX
systems to D using reggae[2].
...
Destroy!
Atila
I know you your intention was to keep it similar to makefile, but
for me it looks unnecessarily complex.
What whould
On Friday, 22 April 2016 at 09:18:48 UTC, Kagamin wrote:
RMW operations on shared data are deprecated. The template
filter on atomicOp is a little different:
https://dlang.org/phobos/core_atomic.html#.atomicOp
Looks like an LDC bug.
Yes, this was indeed an LDC issue. We have our own
implemen
On Saturday, 16 April 2016 at 13:58:28 UTC, Johan Engelen wrote:
On Friday, 15 April 2016 at 19:32:46 UTC, David Nadlinger wrote:
Another "quick fix" if we have to keep the order would be to
add a Bloom filter/… on the side to eliminate most array
searches.
In rare cases, symbols are removed
On Friday, 22 April 2016 at 18:51:57 UTC, David Nadlinger wrote:
As long as elements are not removed too frequently (what do
your numbers say?), the performance impact of doing a full
linear search in those cases shouldn't be too bad.
Note that a (properly tuned) probabilistic data structure l
On Friday, 15 April 2016 at 18:33:44 UTC, Johan Engelen wrote:
I'm thinking about removing the old array all-together.
My question is: is it essential to keep an ordered list? (I see
a `.shift(...)` call on the array, to put something in first
position. If so, could that be solved by having *tw
List of accepted projects : D:
https://summerofcode.withgoogle.com/organizations/5078256051027968/#projects
On Friday, 22 April 2016 at 18:51:57 UTC, David Nadlinger wrote:
On Saturday, 16 April 2016 at 13:58:28 UTC, Johan Engelen wrote:
In rare cases, symbols are removed from the members list, so
the shadow data structure needs the ability to delete elements.
Bloom filters can have false positive
On 4/22/2016 11:55 AM, David Nadlinger wrote:
On Friday, 22 April 2016 at 18:51:57 UTC, David Nadlinger wrote:
As long as elements are not removed too frequently (what do your numbers
say?), the performance impact of doing a full linear search in those cases
shouldn't be too bad.
Note that a (
On Friday, 22 April 2016 at 21:48:09 UTC, Walter Bright wrote:
Why not just use a hash table? D's builtin one?
Apparently, some parts rely on the insertion order, although I'm
not convinced they should. Module::importAll is one of them, but
in a way that's trivial to avoid. I didn't check any
On 4/22/2016 2:38 PM, Johan Engelen wrote:
I don't understand exactly what you mean; do you propose to resort to linear
search after a removal happened? Or only do a linear search when the shadow data
structure says the item is present?
I don't know how often removals happen, but for the 140k ele
On Sunday, 17 April 2016 at 09:09:52 UTC, Ilya Yaroshenko wrote:
On Sunday, 17 April 2016 at 08:49:53 UTC, Seb wrote:
On Sunday, 17 April 2016 at 07:35:19 UTC, Ilya Yaroshenko
wrote:
On Sunday, 17 April 2016 at 07:30:38 UTC, Vladimir Panteleev
I don't understand, what's wrong with std.sci or e
On Friday, 22 April 2016 at 22:10:47 UTC, Walter Bright wrote:
On 4/22/2016 2:38 PM, Johan Engelen wrote:
I don't understand exactly what you mean; do you propose to
resort to linear
search after a removal happened? Or only do a linear search
when the shadow data
structure says the item is pre
On Friday, 22 April 2016 at 21:38:41 UTC, Johan Engelen wrote:
I don't understand exactly what you mean; do you propose to […]
do a linear search when the shadow data structure says the item
is present?
That's the idea. As long as you can reduce the need to do a full
linear search by, say, 1
On 4/22/2016 3:16 PM, David Nadlinger wrote:
One of them is
https://github.com/dlang/dmd/blob/5ea445c68451152d43595c9de4797b6ec1e4f57d/src/dtemplate.d#L6503,
I think.
Definitely one.
On 4/22/2016 3:07 PM, David Nadlinger wrote:
On Friday, 22 April 2016 at 21:48:09 UTC, Walter Bright wrote:
Why not just use a hash table? D's builtin one?
Apparently, some parts rely on the insertion order, although I'm not convinced
they should. Module::importAll is one of them, but in a way
On 4/22/2016 4:31 PM, Walter Bright wrote:
On 4/22/2016 3:16 PM, David Nadlinger wrote:
One of them is
https://github.com/dlang/dmd/blob/5ea445c68451152d43595c9de4797b6ec1e4f57d/src/dtemplate.d#L6503,
I think.
Definitely one.
BTW, this looks like a particularly bad piece of engineering. Th
On 4/15/2016 11:33 AM, Johan Engelen wrote:
The culprit is the linear search at the end of appendToModuleMember, because the
members list with Dsymbols gets pretty large (50k+ members).
https://github.com/D-Programming-Language/dmd/blob/master/src/dtemplate.d#L8012-L8026
https://github.com/dlan
On Friday, 22 April 2016 at 23:49:22 UTC, Walter Bright wrote:
BTW, this looks like a particularly bad piece of engineering.
The trouble is, it saves an index to the member, then does a
bunch of semantic processing, then deletes what is on that
index. But what if the members[] in the meantime s
30 matches
Mail list logo
