On Thursday, 21 July 2016 at 22:47:38 UTC, Seb wrote:
On Thursday, 21 July 2016 at 20:56:07 UTC, eugene wrote:
On Thursday, 21 July 2016 at 20:46:24 UTC, eugene wrote:
Hi everyone,
could you,please, point out where can i find in the
"Documentation" sections info about concurrency and
parralle
On Wednesday, 20 July 2016 at 19:59:42 UTC, Jack Stouffer wrote:
I concur. If the root problem is slow compilation, then there
are much simpler, non-breaking changes that can be made to fix
that.
I don't think compilation time is a problem, actually. It more
has to do with dependency manageme
On Sunday, 7 February 2016 at 00:48:54 UTC, Jason White wrote:
I'm also interested in a discussion of what IO-related
functionality people are missing in Phobos.
This is still a very interesting approach that could even become
a candidate for std.io at some point. Would be great if we could
g
On Sunday, 7 February 2016 at 00:48:54 UTC, Jason White wrote:
I'm interested in feedback on this library. What is it missing?
How can be better?
I think making the actual read/write/open/accept/et.al. functions
used to talk to the kernel pluggable would be a good extension
point to hook in e
On Sun, 24 Jul 2016 12:53:50 +, Sebastien Alaiwan wrote:
> Speeding up compilation should never be considered as an acceptable
> solution here, as it's not scalable: it just pushes the problem away,
> until your project size increases enough.
In order to get an equivalent speedup by refactorin
After I started to get into a near usable state with my game
engine, which originally called as VDP-engine, now it's renamed
to Pixel Perfect ( https://github.com/ZILtoid1991/VDP-engine ), I
was thinking on creating some software synths, but I find the
conventional midi lacking in feature. Afte
DISCLAIMER: although I've been occasionally using D for a lot of
time, I only recently started to follow the forums and use it
intensively, so I may miss part of the history / long term vision.
So, the current guidelines to make a function usable in @nogc are:
1) use ranges as much as possible,
On Sunday, 24 July 2016 at 15:34:55 UTC, Lodovico Giaretta wrote:
DISCLAIMER: although I've been occasionally using D for a lot
of time, I only recently started to follow the forums and use
it intensively, so I may miss part of the history / long term
vision.
[...]
Note that for the arrays
On Sunday, 24 July 2016 at 15:44:48 UTC, lqjglkqjsg wrote:
Note that for the arrays you have @nogc routines in
std.experimental.allocators. (expand/shrink can infer @nogc
from Mallocator).
I know. In fact I'm proposing two possible solutions based on
std.experimental.allocators. Both have adv
On Sunday, 24 July 2016 at 15:33:24 UTC, solidstate1991 wrote:
After I started to get into a near usable state with my game
engine, which originally called as VDP-engine, now it's renamed
to Pixel Perfect ( https://github.com/ZILtoid1991/VDP-engine ),
I was thinking on creating some software sy
On Sunday, 24 July 2016 at 15:48:22 UTC, lqjglkqjsg wrote:
On Sunday, 24 July 2016 at 15:33:24 UTC, solidstate1991 wrote:
After I started to get into a near usable state with my game
engine, which originally called as VDP-engine, now it's
renamed to Pixel Perfect (
https://github.com/ZILtoid19
On Sunday, 24 July 2016 at 16:01:39 UTC, Jonathan Marler wrote:
On Sunday, 24 July 2016 at 15:48:22 UTC, lqjglkqjsg wrote:
On Sunday, 24 July 2016 at 15:33:24 UTC, solidstate1991 wrote:
After I started to get into a near usable state with my game
engine, which originally called as VDP-engine, n
On Sunday, 24 July 2016 at 15:34:55 UTC, Lodovico Giaretta wrote:
DISCLAIMER: although I've been occasionally using D for a lot
of time, I only recently started to follow the forums and use
it intensively, so I may miss part of the history / long term
vision.
So, the current guidelines to mak
On Sunday, 24 July 2016 at 17:02:08 UTC, lqjglkqjsg wrote:
On Sunday, 24 July 2016 at 16:01:39 UTC, Jonathan Marler wrote:
[...]
And inside software ? The only one I remember for implementing
OSC was Reaktor. actually even the hosts didn't implement it.
MIDI can't die because people still us
Hi,
I have my own conclusions with doing the following, but I'd thought
I'd ask for a second opinion before committing.
Given the freely available language specification linked below [1].
The order that all entries are listed in haven't changed since D1, or
at least to my memory. So would it be
On Sunday, 24 July 2016 at 17:08:27 UTC, Jonathan Marler wrote:
On Sunday, 24 July 2016 at 17:02:08 UTC, lqjglkqjsg wrote:
On Sunday, 24 July 2016 at 16:01:39 UTC, Jonathan Marler wrote:
[...]
[...]
This type of discussion sounds familiar, except MIDI=C++ and
OSC=D :)
MIDI=C++ and OSC=F#
Hello,
I found a way how to correctly implement multidimensional
functional map for ndslices and for packed ndslices (tensors
composed of tensors). It allows
1. a compiler to use vectorisation with SIMD instructions like
`fabs` or `sqrt` for example. But first [1] should be merged
2. to man
On Sunday, 24 July 2016 at 17:29:02 UTC, lqjglkqjsg wrote:
On Sunday, 24 July 2016 at 17:08:27 UTC, Jonathan Marler wrote:
On Sunday, 24 July 2016 at 17:02:08 UTC, lqjglkqjsg wrote:
On Sunday, 24 July 2016 at 16:01:39 UTC, Jonathan Marler
wrote:
[...]
[...]
This type of discussion sounds f
On Sunday, 24 July 2016 at 16:01:39 UTC, Jonathan Marler wrote:
On Sunday, 24 July 2016 at 15:48:22 UTC, lqjglkqjsg wrote:
On Sunday, 24 July 2016 at 15:33:24 UTC, solidstate1991 wrote:
[...]
The problem is that OSC is not used at all. People still use
MIDI. e.g all the master keyboards, dru
On 7/24/2016 10:10 AM, Iain Buclaw via Digitalmars-d wrote:
Given the freely available language specification linked below [1].
The order that all entries are listed in haven't changed since D1, or
at least to my memory. So would it be considered reasonably safe to
reference these parts in code?
On Sunday, 24 July 2016 at 19:02:32 UTC, Gorge Jingale wrote:
On Sunday, 24 July 2016 at 16:01:39 UTC, Jonathan Marler wrote:
On Sunday, 24 July 2016 at 15:48:22 UTC, lqjglkqjsg wrote:
[...]
Well the X32 mixer uses OSC. I actually started writing a
little program that would use MULTICAST to
On Friday, 22 July 2016 at 01:54:28 UTC, Yuxuan Shui wrote:
auto b = alloc.makeArray!A(10, A(1));
auto c = alloc.makeArray!A(2, A(2));
I noticed (using dpaste) if you edit the 'b' line to only
allocate 5 structs, and it won't crash. 6 or more, crash. Maybe a
bu
To allow for different debug versions without having to go full
blown version().
@mem debug do something memory wise
@see debug write a message to console
Then these different attributed versions can be disabled. it
could be something like
version(debug(see)) = none;
or
static if (hasAt
Any thoughts on an @gc attribute for bypassing @nogc?
As much as I like to cringe at the GC when I'm using C#, I can't
ignore my level of productivity, as it compares to projects I've
done in C++.
If I had to write a butter-smooth AAA game, it may be a problem,
but at present, my thoughts on
On Sunday, 24 July 2016 at 22:13:02 UTC, bitwise wrote:
There is the following, which is clever. But if it came down to
having to do this to bypass @nogc, I simply wouldn't use @nogc.
that's what i ended up with: not using @nogc. it is pure
parketing thing. for real world using it adds more tr
pure *marketing* thing, lol.
On Sunday, 24 July 2016 at 22:13:02 UTC, bitwise wrote:
Any thoughts on an @gc attribute for bypassing @nogc?
As much as I like to cringe at the GC when I'm using C#, I
can't ignore my level of productivity, as it compares to
projects I've done in C++.
If I had to write a butter-smooth AAA g
@nogc functions must never ever trigger GC collection cycle, not
under any possible circumstances. Otherwise the attribute serves
no purpose.
On Saturday, 23 July 2016 at 19:22:09 UTC, Jacob Carlborg wrote:
How does this relate to templates? Or is the suggestion to now
use templates on API boundaries?
Benjamin proposed to stop considering `export` a protection
attribute and mark all functions called from templates as
`export` (allo
On Sunday, 24 July 2016 at 22:21:51 UTC, ketmar wrote:
On Sunday, 24 July 2016 at 22:13:02 UTC, bitwise wrote:
There is the following, which is clever. But if it came down
to having to do this to bypass @nogc, I simply wouldn't use
@nogc.
that's what i ended up with: not using @nogc. it is pu
On Sunday, 24 July 2016 at 23:14:37 UTC, bitwise wrote:
I don't understand what you mean, saying it's useless.
exactly that. in the end i can't mark any code @nogc except very
trivial, where it doesn't matter at all (primitive getters and
setters). in other code i ocasionally need to allocate
On Sunday, 24 July 2016 at 23:10:18 UTC, Dicebot wrote:
@nogc functions must never ever trigger GC collection cycle,
not under any possible circumstances. Otherwise the attribute
serves no purpose.
The fact that you can use malloc() in a @nogc function
invalidates this argument. There are man
On Sunday, 24 July 2016 at 23:30:37 UTC, bitwise wrote:
On Sunday, 24 July 2016 at 23:10:18 UTC, Dicebot wrote:
@nogc functions must never ever trigger GC collection cycle,
not under any possible circumstances. Otherwise the attribute
serves no purpose.
The fact that you can use malloc() in a
On Sunday, 24 July 2016 at 21:33:20 UTC, Gorge Jingale wrote:
To allow for different debug versions without having to go full
blown version().
@mem debug do something memory wise
@see debug write a message to console
I don't get what would be the benefit.
Currently, you can write that like:
On Sunday, 24 July 2016 at 23:41:26 UTC, Ivan Kazmenko wrote:
On Sunday, 24 July 2016 at 21:33:20 UTC, Gorge Jingale wrote:
To allow for different debug versions without having to go
full blown version().
@mem debug do something memory wise
@see debug write a message to console
I don't get
On Sunday, 24 July 2016 at 23:30:37 UTC, bitwise wrote:
On Sunday, 24 July 2016 at 23:10:18 UTC, Dicebot wrote:
@nogc functions must never ever trigger GC collection cycle,
not under any possible circumstances. Otherwise the attribute
serves no purpose.
The fact that you can use malloc() in a
On Monday, 25 July 2016 at 00:05:16 UTC, ketmar wrote:
On Sunday, 24 July 2016 at 23:30:37 UTC, bitwise wrote:
On Sunday, 24 July 2016 at 23:10:18 UTC, Dicebot wrote:
@nogc functions must never ever trigger GC collection cycle,
not under any possible circumstances. Otherwise the attribute
serv
On Monday, 25 July 2016 at 00:26:05 UTC, bitwise wrote:
If someone knows all their code is @nogc, they can disable the
GC. If they do that, and then someone GC allocates anyways,
it's a leak. Based on this, an argument could be made that
@nogc should *never* be bypassed. But that argument is ma
On Sunday, 24 July 2016 at 21:33:20 UTC, Gorge Jingale wrote:
To allow for different debug versions without having to go full
blown version().
debug(whatever) thingy_here();
dmd -debug=whatever yourfile.d
works today.
On Monday, 25 July 2016 at 02:13:34 UTC, Adam D. Ruppe wrote:
On Sunday, 24 July 2016 at 21:33:20 UTC, Gorge Jingale wrote:
To allow for different debug versions without having to go
full blown version().
debug(whatever) thingy_here();
dmd -debug=whatever yourfile.d
works today.
You can't
On 25/07/2016 10:13 AM, bitwise wrote:
Any thoughts on an @gc attribute for bypassing @nogc?
As much as I like to cringe at the GC when I'm using C#, I can't ignore
my level of productivity, as it compares to projects I've done in C++.
If I had to write a butter-smooth AAA game, it may be a pro
On Monday, 25 July 2016 at 03:18:17 UTC, rikki cattermole wrote:
On 25/07/2016 10:13 AM, bitwise wrote:
[...]
I've been saying for a very long time we need @assumenogc
attribute like we have @trusted for @safe.
I havent seen this assumegc propsal before, could you provide the
definition yo
On 2016-07-25 01:12, Dicebot wrote:
Benjamin proposed to stop considering `export` a protection attribute
and mark all functions called from templates as `export` (allowing
`export private` if necessary).
Ah, forgot that detail.
--
/Jacob Carlborg
On Sunday, 24 July 2016 at 15:33:04 UTC, Chris Wright wrote:
Look at std.algorithm. Tons of methods, and I imported it just
for `canFind` and `sort`.
Look at std.datetime. It imports eight or ten different
modules, and it needs every one of those for something or
other. Should we split it int
44 matches
Mail list logo
