Le 29/12/2013 15:15, Suliman a écrit :
On Sunday, 29 December 2013 at 01:15:50 UTC, Xavier Bigand wrote:
Latest news of DQuick for this year.
The good news is, the project still alive and Bruno added some
interesting stuff to the DMLengine :
- Adding support of arrays
- Adding support of
Le 29/12/2013 02:15, Xavier Bigand a écrit :
Latest news of DQuick for this year.
The good news is, the project still alive and Bruno added some
interesting stuff to the DMLengine :
- Adding support of arrays
- Adding support of delegates
- Improve error reporting from Lua
Our
DDOX [1] has just gained support for a JavaScript based live search
function. I've uploaded new DMD 2.064.2 Phobos/Druntime docs [2] with
this (search box in the upper-left corner).
The vibe.d docs [3] are now also searchable and documentation for old
releases can now also be viewed in addition
Sönke Ludwig, el 29 de December a las 19:07 me escribiste:
DDOX [1] has just gained support for a JavaScript based live search
function. I've uploaded new DMD 2.064.2 Phobos/Druntime docs [2] with
this (search box in the upper-left corner).
The vibe.d docs [3] are now also searchable and
On Sunday, 29 December 2013 at 21:35:53 UTC, Sönke Ludwig wrote:
Am 29.12.2013 21:10, schrieb Leandro Lucarella:
Sönke Ludwig, el 29 de December a las 19:07 me escribiste:
DDOX [1] has just gained support for a JavaScript based live
search
function. I've uploaded new DMD 2.064.2
Am 29.12.2013 21:10, schrieb Leandro Lucarella:
Sönke Ludwig, el 29 de December a las 19:07 me escribiste:
DDOX [1] has just gained support for a JavaScript based live search
function. I've uploaded new DMD 2.064.2 Phobos/Druntime docs [2] with
this (search box in the upper-left corner).
The
On 12/29/2013 1:39 PM, extrawurst wrote:
On Sunday, 29 December 2013 at 21:35:53 UTC, Sönke Ludwig wrote:
Am 29.12.2013 21:10, schrieb Leandro Lucarella:
Sönke Ludwig, el 29 de December a las 19:07 me escribiste:
DDOX [1] has just gained support for a JavaScript based live search
function.
On 12/29/13, Sönke Ludwig slud...@outerproduct.org wrote:
DDOX [1] has just gained support for a JavaScript based live search
function.
[2]: http://vibed.org/temp/dlang.org/library/index.html
Nice! I have a few notes/suggestions:
- The result bubble should likely hide when you select another
Am 29.12.2013 22:46, schrieb Dicebot:
On Sunday, 29 December 2013 at 18:08:15 UTC, Sönke Ludwig wrote:
DDOX [1] has just gained support for a JavaScript based live search
function. I've uploaded new DMD 2.064.2 Phobos/Druntime docs [2] with
this (search box in the upper-left corner).
The
Am 29.12.2013 22:53, schrieb Andrej Mitrovic:
On 12/29/13, Sönke Ludwig slud...@outerproduct.org wrote:
DDOX [1] has just gained support for a JavaScript based live search
function.
[2]: http://vibed.org/temp/dlang.org/library/index.html
Nice! I have a few notes/suggestions:
- The result
Am Sat, 28 Dec 2013 15:23:55 +0100
schrieb Jacob Carlborg d...@me.com:
On 2013-12-28 03:46, Marco Leise wrote:
Wait a second, what about *setting* attributes? Some difficult
ones are:
o toggling read-only (for whom? user, group, others?)
o executable flag
o hidden flag
On
Am Sun, 29 Dec 2013 13:44:02 +0100
schrieb Jacob Carlborg d...@me.com:
On 2013-12-29 11:36, Marco Leise wrote:
Oh right, they have a hidden attribute as well. I guess if
Phobos should expose the 'hidden' state of a file it should
write to this attribute, but read both. E.g. for a file
On 12/29/13 3:09 AM, Dicebot wrote:
1)
Timon has raised the point that exact match between in naming between
built-in and library type will be confusing as they will actually differ
in behavior (http://forum.dlang.org/post/l99mke$q1o$1...@digitalmars.com).
Andrei has proposed
On 12/29/13 4:20 AM, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
On Sunday, 29 December 2013 at 11:01:05 UTC, Marco Leise wrote:
Basic OS level file-system I/O support is useful on its own,
especially in a systems programming language. You don't need
to pull in a whole bunch
On Sunday, 29 December 2013 at 15:01:03 UTC, Andrei Alexandrescu
wrote:
On 12/29/13 3:09 AM, Dicebot wrote:
1)
Timon has raised the point that exact match between in naming
between
built-in and library type will be confusing as they will
actually differ
in behavior
On 12/29/13 5:15 AM, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
On Sunday, 29 December 2013 at 06:00:31 UTC, Adam Wilson wrote:
I want to make a point here that many people come to do looking for
something that is as performant as C++ with the ease of C# or Java,
and for the
On 12/29/13 6:35 AM, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
On Sunday, 29 December 2013 at 13:46:07 UTC, Dicebot wrote:
This is not true. Assuming skilled use and same compiler backend those
are equally performant. D lacks some low-level control C has (which is
important
On 27 Dec 2013 20:33, H. S. Teoh hst...@quickfur.ath.cx wrote:
On Wed, Dec 25, 2013 at 02:30:45PM +, Francesco Cattoglio wrote:
On Wednesday, 25 December 2013 at 10:58:53 UTC, bearophile wrote:
[...]
(A less important enhancement is issue 11252).
On the other hand, I have honestly no
On Sunday, 29 December 2013 at 14:35:44 UTC, Ola Fosheim Grøstad
wrote:
That low-level control also matters for performance, when you
have hard deadlines. E.g. when the GC kicks in, it not only
hogs all the threads that participate in GC, it also trash the
caches unless you have a GC
On Sunday, 29 December 2013 at 11:10:00 UTC, Dicebot wrote:
Despite my initial desire to standardize API between library
types it seems that breakage will be much more damaging than I
have initially expected. Jakob example
(http://forum.dlang.org/post/vkeqyorptcobufzmm...@forum.dlang.org)
On Sunday, 29 December 2013 at 15:01:03 UTC, Andrei Alexandrescu
wrote:
I think a duo `TemplateArgumentList` (auto-expansion) and
`TemplateArgumentPack` (no auto-expansion) in the same module
is the ticket. It also makes for a wonderful opportunity to
explain the distinction in the
On Sunday, 29 December 2013 at 15:01:03 UTC, Andrei Alexandrescu
wrote:
I think a duo `TemplateArgumentList` (auto-expansion) and
`TemplateArgumentPack` (no auto-expansion) in the same module
is the ticket. It also makes for a wonderful opportunity to
explain the distinction in the
On Sunday, 29 December 2013 at 15:05:31 UTC, Andrei Alexandrescu
wrote:
Well one question is what other successful designs could we use
as precedent? I don't know of any successful unified APIs for
regular/remote filesystems that also allow full local file
functionality. The closest
On Sunday, 29 December 2013 at 15:35:50 UTC, Jakob Ovrum wrote:
...
Sorry, can you make a short summary about your position? You are
against adding packed list to library or just against removing
expanding one (from the library)?
On Sunday, 29 December 2013 at 15:45:59 UTC, Dicebot wrote:
On Sunday, 29 December 2013 at 15:35:50 UTC, Jakob Ovrum wrote:
...
Sorry, can you make a short summary about your position? You
are against adding packed list to library or just against
removing expanding one (from the library)?
On 12/29/13 7:42 AM, Jakob Ovrum wrote:
On Sunday, 29 December 2013 at 15:01:03 UTC, Andrei Alexandrescu wrote:
I think a duo `TemplateArgumentList` (auto-expansion) and
`TemplateArgumentPack` (no auto-expansion) in the same module is the
ticket. It also makes for a wonderful opportunity to
On 12/29/13 7:43 AM, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
On Sunday, 29 December 2013 at 15:05:31 UTC, Andrei Alexandrescu wrote:
Well one question is what other successful designs could we use as
precedent? I don't know of any successful unified APIs for
On 12/29/13 2:20 AM, monarch_dodra wrote:
There is precedence for this in phobos with schwatzSort: It use a
unaryFun, followed by a binaryFun.
I've found this works quite well: More often than not, a unary fun is
more than enough (the default a b/a == b is fine). And in the
cases where you
On Sunday, 29 December 2013 at 16:01:41 UTC, Andrei Alexandrescu
wrote:
I also think it should be shorter, because a) it's a
fundamental, and
thus very commonly used template, and b) code that manipulates
lists are
functional in nature which results in long lines that are also
hard to
split up
On 12/29/13 2:27 AM, bearophile wrote:
But another common need is to group by equivalent classes using an
associative array. Both C# and Clojure have this functionality (on LINQ
and in the functions toolkit). This means that a hashGroup builds an
associative array inside and returns it.
See
On 12/29/13 8:14 AM, Jakob Ovrum wrote:
On Sunday, 29 December 2013 at 16:01:41 UTC, Andrei Alexandrescu wrote:
I also think it should be shorter, because a) it's a fundamental, and
thus very commonly used template, and b) code that manipulates lists are
functional in nature which results in
On Sunday, 29 December 2013 at 16:19:57 UTC, Andrei Alexandrescu
wrote:
It's been discussed before - these are advanced notions that
won't be used frequently and naively.
I guess I'm biased by writing a lot of library code, where it's
quite frequently used. I can imagine application code
No. In D, struct are freely copied or moved depending on
whether the source is an lvalue or an rvalue. What is possible
is to define the post-blit function to work on the
already-blitted destination object.
For example, if you don't want the source and the destination
share a member slice,
On Sunday, 29 December 2013 at 16:06:32 UTC, Andrei Alexandrescu
wrote:
I think we (and others) have done a fine job so far at
abstracting away e.g. very different ways of figuring whether
an entry is a directory on Windows vs. Posix. Now we're to
throw all that away and go back to silex
On Sunday, 29 December 2013 at 12:57:43 UTC, Ivan Kazmenko wrote:
I can't access http://d.puremagic.com/issues/ for at least an
hour now. On a related note,
http://d.puremagic.com/test-results/ seems to be down, too.
works fine for me.
On Saturday, 28 December 2013 at 17:42:26 UTC, Jakob Ovrum wrote:
On Saturday, 28 December 2013 at 17:23:30 UTC, Jeroen Bollen
wrote:
Usually if you're working with a console though the input
stream won't exhaust and thus the blocking 'readln' would be a
better option, no?
The blocking
If nothing has happened recently the current situation of cross
referencing in Ddoc sucks. What's currently being used in the Phobos
documentation is the XREF, CXREF and ECXREF ddoc macros. These macros
take two arguments, append std, core or etc and form a link of the
arguments. The problem
On Sunday, 29 December 2013 at 15:22:29 UTC, Andrei Alexandrescu
wrote:
Wait, what? Go excused itself out of the competition, and you'd
Agree. I consider Go to be a web-service language atm.
need to bring some evidence that D is not as fast/tight as C++.
I have accumulated quite a bit of
On Sunday, 29 December 2013 at 17:25:39 UTC, Jeroen Bollen wrote:
Wouldn't byline return an empty string if the inputstream is
exhausted but not closed?
No, both `readln` and `byLine` will block until either EOL or
EOF. They differ in their handling of EOF - `readln` returns an
empty string,
Am 29.12.2013 17:22, schrieb Ritu:
No. In D, struct are freely copied or moved depending on whether the
source is an lvalue or an rvalue. What is possible is to define the
post-blit function to work on the already-blitted destination object.
For example, if you don't want the source and the
On Sun, 29 Dec 2013 17:54:51 +, Ola Fosheim Grøstad wrote:
C is so barebones that you can do your own coroutines without language
support if you wish.
You can do that in D too. core.thread.Fiber is implemented in D (with a
bit of inline assembly), without any special language support.
On Sunday, 29 December 2013 at 17:12:14 UTC, John Colvin wrote:
On Sunday, 29 December 2013 at 12:57:43 UTC, Ivan Kazmenko
wrote:
I can't access http://d.puremagic.com/issues/ for at least an
hour now. On a related note,
http://d.puremagic.com/test-results/ seems to be down, too.
works fine
Am 29.12.2013 18:38, schrieb Jacob Carlborg:
A. Automatic cross reference
This is done for the DDOX based docs that were supposed to end up on the
home page at some point:
http://forum.dlang.org/thread/l9poef$210u$1...@digitalmars.com
http://vibed.org/temp/dlang.org/library/index.html
* It
On Sunday, 29 December 2013 at 16:22:04 UTC, Ritu wrote:
I have a struct that wraps a class object and lazily
initializes it. Now in case the struct instance is passed as an
argument to a function and it has not been initialized yet, the
default copy constructor and the postblit do not offer a
28-Dec-2013 21:13, Vladimir Panteleev пишет:
On Saturday, 28 December 2013 at 17:07:58 UTC, Andrei Alexandrescu wrote:
On 12/28/13 8:50 AM, Jeroen Bollen wrote:
On Saturday, 28 December 2013 at 16:49:15 UTC, Jeroen Bollen wrote:
Why is when you do readln() the newline character (\n) gets read
On Sunday, 29 December 2013 at 15:26:35 UTC, Andrei Alexandrescu
wrote:
On 12/29/13 6:35 AM, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
On Sunday, 29 December 2013 at 13:46:07 UTC, Dicebot wrote:
This is not true. Assuming skilled use and same compiler
backend those
are
29-Dec-2013 20:01, Andrei Alexandrescu пишет:
On 12/29/13 7:42 AM, Jakob Ovrum wrote:
On Sunday, 29 December 2013 at 15:01:03 UTC, Andrei Alexandrescu wrote:
I also think it should be shorter, because a) it's a fundamental, and
thus very commonly used template, and b) code that manipulates
On Sunday, 29 December 2013 at 18:29:52 UTC, jerro wrote:
You can do that in D too. core.thread.Fiber is implemented in D
(with a
bit of inline assembly), without any special language support.
Yes, coroutines was a bad example, you probably can do that in
many stack-based languages. My point
On Sunday, 29 December 2013 at 18:40:07 UTC, Maxim Fomin wrote:
On Sunday, 29 December 2013 at 16:22:04 UTC, Ritu wrote:
I have a struct that wraps a class object and lazily
initializes it. Now in case the struct instance is passed as
an argument to a function and it has not been initialized
On Sunday, 29 December 2013 at 18:27:16 UTC, Benjamin Thaut wrote:
No unfortunately not. You could solve the issue by adding
another level of indirection. So always allocate the additional
indirection, then its save to copy it, and then you can lazy
instaniate the actual instance when needed
On Sunday, 29 December 2013 at 18:45:36 UTC, Dmitry Olshansky
wrote:
I've come to conclusion that the only sane line ending behavior
is to do what Unicode standard says, and detect the following
pattern as line separator:
\r\n | \r | \f | \v | \n | \u0085 | \u2028 | \u2029
This includes
29-Dec-2013 23:28, Vladimir Panteleev пишет:
On Sunday, 29 December 2013 at 18:45:36 UTC, Dmitry Olshansky wrote:
I've come to conclusion that the only sane line ending behavior is to
do what Unicode standard says, and detect the following pattern as
line separator:
\r\n | \r | \f | \v | \n |
On 2013-12-29 19:35, Sönke Ludwig wrote:
This is done for the DDOX based docs that were supposed to end up on the
home page at some point:
http://forum.dlang.org/thread/l9poef$210u$1...@digitalmars.com
http://vibed.org/temp/dlang.org/library/index.html
Right, forgot about that. When _are_
Am 29.12.2013 20:26, schrieb monarch_dodra:
Even with that, you'd still have to make sure the newly inserted
indirection gets initialized *prior* to the copy, so it's back to square
one...
For that you can easily disable the default constructor. And then make
the user call a constructor of
On 12/29/2013 05:17 PM, Andrei Alexandrescu wrote:
On 12/29/13 2:27 AM, bearophile wrote:
But another common need is to group by equivalent classes using an
associative array. Both C# and Clojure have this functionality (on LINQ
and in the functions toolkit). This means that a hashGroup builds
On 12/29/2013 5:46 AM, Dicebot wrote:
D lacks some low-level control C has
For instance?
On the other hand, D has an inline assembler and C (without vendor extensions)
does not. C doesn't even have (without vendor extensions) alignment control on
struct fields.
On Sunday, December 29, 2013 07:22:28 Andrei Alexandrescu wrote:
Clearly there's work we need to do on improving particularly the
standard library. But claiming that D code can't be efficient because of
some stdlib artifacts is like claiming C++ code can't do efficient I/O
because it must use
On Sunday, December 29, 2013 12:19:33 Walter Bright wrote:
On 12/29/2013 5:46 AM, Dicebot wrote:
D lacks some low-level control C has
For instance?
On the other hand, D has an inline assembler and C (without vendor
extensions) does not. C doesn't even have (without vendor extensions)
On 12/29/2013 11:15 AM, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
It is probably feasible to create a real-time friendly garbage collector that
can cooperate with realtime threads, but it isn't trivial. To get good cache
coherency all cores have to cooperate on what memory
On Sunday, 29 December 2013 at 20:36:27 UTC, Walter Bright wrote:
I'll reiterate that the GC will NEVER EVER pause your program
unless you are actually calling the GC to allocate memory. A
loop that does not GC allocate WILL NEVER PAUSE.
That's fine, except when you have real-time threads.
On Sunday, 29 December 2013 at 20:19:35 UTC, Walter Bright wrote:
On 12/29/2013 5:46 AM, Dicebot wrote:
D lacks some low-level control C has
For instance?
On the other hand, D has an inline assembler and C (without
vendor extensions) does not. C doesn't even have (without
vendor
I'm not sure if D's operator overloading is
sufficiently rich to
allow separate operators for matrix multiplication and
element-wise
multiplication in matrix. (Dealing with this is a pain in
numpy, the most common
Python matrix library, as well as in Eigen, a common c++
matrix library.)
I
On 12/29/13 12:47 PM, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
On Sunday, 29 December 2013 at 20:36:27 UTC, Walter Bright wrote:
I'll reiterate that the GC will NEVER EVER pause your program unless
you are actually calling the GC to allocate memory. A loop that does
not GC
On 12/29/2013 12:47 PM, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
On Sunday, 29 December 2013 at 20:36:27 UTC, Walter Bright wrote:
I'll reiterate that the GC will NEVER EVER pause your program unless you are
actually calling the GC to allocate memory. A loop that does not
On Sunday, 29 December 2013 at 19:02:57 UTC, Dmitry Olshansky
wrote:
And having to deal with all kinds of aliases people are
_expected_ to create? Why not pick something accessible in the
first place?
Because no good short name has ever been proposed so far. I'd
strongly discourage creating
Back to fighting :)
On Sunday, 29 December 2013 at 15:35:50 UTC, Jakob Ovrum wrote:
Breakage that causes errors in secondary locations and cannot
be automatically repaired (e.g. search replace) is the worst
kind of breakage, after silent failures, that I can think of.
This is why I have
On Sunday, 29 December 2013 at 18:13:30 UTC, Jakob Ovrum wrote:
On Sunday, 29 December 2013 at 17:25:39 UTC, Jeroen Bollen
wrote:
Wouldn't byline return an empty string if the inputstream is
exhausted but not closed?
No, both `readln` and `byLine` will block until either EOL or
EOF. They
Didn't mean this to be kind of under the tree .. Planned to post long
ago but I barely had the time to flesh it out.
TL;DR: Solve the input side of I/O problem with new kind of ranges.
I'm taking on the buffering primitive on top of the low-level unbuffered
I/O sources specifically.
Links
On Sunday, 29 December 2013 at 21:39:52 UTC, Walter Bright wrote:
Since you can control if and when the GC runs fairly simply,
this is not any sort of blocking issue.
I agree, it is not a blocking issue. It is a cache-trashing
issue. So unless the GC is cache-friendly I am concerned about
On 12/29/2013 2:10 PM, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
On Sunday, 29 December 2013 at 21:39:52 UTC, Walter Bright wrote:
Since you can control if and when the GC runs fairly simply, this is not any
sort of blocking issue.
Your reply doesn't take into account
On Sunday, 29 December 2013 at 22:02:57 UTC, Dmitry Olshansky
wrote:
[snip]
Hmm, just yesterday I was rewriting a parser to use a buffer
instead of loading the whole file in memory, so this is quite
timely for me.
Questions:
1. What happens when the distance between the pinned and current
On 29.12.2013 14:15, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
D/Rust/Go/this-C#-language all claim to be system levels programming
languages. I think they are not, as long as C/C++ is a better solution
for embedded programming it will remain THE system level programming
On 29.12.2013 23:27, Walter Bright wrote:
On 12/29/2013 2:10 PM, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
On Sunday, 29 December 2013 at 21:39:52 UTC, Walter Bright wrote:
Since you can control if and when the GC runs fairly simply, this is
not any
sort of blocking issue.
On Sunday, 29 December 2013 at 22:27:43 UTC, Walter Bright wrote:
Your reply doesn't take into account that you can control if
and when the GC runs fairly simply. So you can run it at a time
when it won't matter to the cache.
In a computer game GC should run frequently. You don't want to
On 12/29/13 3:14 PM, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
On Sunday, 29 December 2013 at 22:27:43 UTC, Walter Bright wrote:
Your reply doesn't take into account that you can control if and when
the GC runs fairly simply. So you can run it at a time when it won't
matter
On Sunday, 29 December 2013 at 23:58:34 UTC, Andrei Alexandrescu
wrote:
Then don't use the GC.
I agree!
Thus: any language that makes it hard to not use the GC is not
competing with C++ as a performant language. ;-]
On 12/29/13 4:08 PM, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
On Sunday, 29 December 2013 at 23:58:34 UTC, Andrei Alexandrescu wrote:
Then don't use the GC.
I agree!
Thus: any language that makes it hard to not use the GC is not competing
with C++ as a performant
On 12/29/2013 10:41 PM, Dicebot wrote:
...
Use in static foreach - works with alias this
Use in special expressions that operate on types, such as `is`,
`typeof` and `typeid` - any code that does on expanded lists right now
is completely broken and must be re-written according to existing spec.
On Sunday, 29 December 2013 at 23:14:59 UTC, Ola Fosheim Grøstad
wrote:
On Sunday, 29 December 2013 at 22:27:43 UTC, Walter Bright
wrote:
Your reply doesn't take into account that you can control if
and when the GC runs fairly simply. So you can run it at a
time when it won't matter to the
On Monday, 30 December 2013 at 01:09:26 UTC, develop32 wrote:
I work on a somewhat large game using D, there is no GC running
because there are no allocations.
That's cool!
As far as I know, people tend not to use system primitives like
malloc/free in C++ games either as even those are too
On Sunday, 29 December 2013 at 15:42:34 UTC, Jakob Ovrum wrote:
I think we should use this chance to rectify the capitalization
of the name. As the result is not exclusively a list of types,
current conventions state that the name should be
lowerCamelCase.
I believe you got this one the
Because you want to stream them to the GPU when you walk across
the land in a seamless engine?
Indeed, but the arrays that are used for holding the data are
allocated (not in GC heap) before the main loop and always reused.
On Sunday, 29 December 2013 at 15:42:34 UTC, Jakob Ovrum wrote:
I think we should use this chance to rectify the capitalization
of the name. As the result is not exclusively a list of types,
current conventions state that the name should be
lowerCamelCase.
I believe you got this one the
Indeed, but the arrays that are used for holding the data are
allocated (not in GC heap) before the main loop and always
reused.
Yes, I merely tried to point out that you don't want to spend a
lot of memory for dead objects waiting for the GC to kick in. You
can use that space for caching
I assumed GC would be useful for AI/game world. It will benefit
from GC because you have complex interdependencies, many
different classes and want to be able to experiment.
Experimentation and explicit memory deallocation is a likely
source for memory leaks… However this will only work well
On Monday, 30 December 2013 at 02:18:34 UTC, develop32 wrote:
In the end, AI/game logic uses the same mechanic as texture
streaming - reuse of the previously allocated memory.
That is a possibility of course, but for a heterogenous
environment you risk running out of slots. E.g. online games,
That is a possibility of course, but for a heterogenous
environment you risk running out of slots. E.g. online games,
virtual worlds, sandbox games where users build etc.
No, not really, just allocate more. The memory is managed by a
single closed class, I can do whatever I want with it.
On Monday, 30 December 2013 at 02:44:27 UTC, develop32 wrote:
The thing is, all of that game logic data takes a really
surprisingly small amount of memory.
In that case you probably could use GC, so why don't you?
On Monday, 30 December 2013 at 02:48:30 UTC, Ola Fosheim Grøstad
wrote:
On Monday, 30 December 2013 at 02:44:27 UTC, develop32 wrote:
The thing is, all of that game logic data takes a really
surprisingly small amount of memory.
In that case you probably could use GC, so why don't you?
Am Sun, 29 Dec 2013 22:03:14 +
schrieb Jeroen Bollen jbin...@gmail.com:
On Sunday, 29 December 2013 at 18:13:30 UTC, Jakob Ovrum wrote:
On Sunday, 29 December 2013 at 17:25:39 UTC, Jeroen Bollen
wrote:
Wouldn't byline return an empty string if the inputstream is
exhausted but not
On Monday, 30 December 2013 at 00:20:43 UTC, Timon Gehr wrote:
What would be an example of code that you consider to be broken?
(TemplateArgumentList!(int, double) is a valid type and
TemplateArgumentList!(1, 2.0) is a value of that type.)
Stuff that relies that, for example, that
Am Sat, 28 Dec 2013 17:08:38 +
schrieb Vladimir Panteleev vladi...@thecybershadow.net:
On Saturday, 28 December 2013 at 17:07:23 UTC, Andrei
Alexandrescu wrote:
On 12/28/13 8:49 AM, Jeroen Bollen wrote:
Why is when you do readln() the newline character (\n) gets
read too?
Wouldn't
On Monday, 30 December 2013 at 01:36:48 UTC, David Nadlinger
wrote:
On Sunday, 29 December 2013 at 15:42:34 UTC, Jakob Ovrum wrote:
I think we should use this chance to rectify the
capitalization of the name. As the result is not exclusively a
list of types, current conventions state that the
On Monday, 30 December 2013 at 03:01:08 UTC, Dicebot wrote:
Do we actually have guidelines about casing in context of
aliased content? I had impression that it is symbol on its own
that matters and thus TemplateArgumentPack needs to be
CamelCased simply because it is a type/template, whatever
On Monday, 30 December 2013 at 03:19:36 UTC, David Nadlinger
wrote:
On Monday, 30 December 2013 at 03:01:08 UTC, Dicebot wrote:
Do we actually have guidelines about casing in context of
aliased content? I had impression that it is symbol on its own
that matters and thus TemplateArgumentPack
On Monday, 30 December 2013 at 03:03:37 UTC, Marco Leise wrote:
Am Sat, 28 Dec 2013 17:08:38 +
schrieb Vladimir Panteleev vladi...@thecybershadow.net:
On Saturday, 28 December 2013 at 17:07:23 UTC, Andrei
Alexandrescu wrote:
On 12/28/13 8:49 AM, Jeroen Bollen wrote:
Why is when you do
On 12/30/2013 03:58 AM, Dicebot wrote:
On Monday, 30 December 2013 at 00:20:43 UTC, Timon Gehr wrote:
What would be an example of code that you consider to be broken?
(TemplateArgumentList!(int, double) is a valid type and
TemplateArgumentList!(1, 2.0) is a value of that type.)
Stuff that
On 12/29/13 6:58 PM, Dicebot wrote:
On Monday, 30 December 2013 at 00:20:43 UTC, Timon Gehr wrote:
What would be an example of code that you consider to be broken?
(TemplateArgumentList!(int, double) is a valid type and
TemplateArgumentList!(1, 2.0) is a value of that type.)
Stuff that relies
On Monday, 30 December 2013 at 03:44:49 UTC, Andrei Alexandrescu
wrote:
I don't understand the question. I think there's no particular
relation between TemplateArgument{List,Pack}!(int, double) and
TemplateArgument{List,Pack}!(1, 2.0). One is a list of two
types and the other is a list of two
On Sun, Dec 29, 2013 at 06:38:55PM +0100, Jacob Carlborg wrote:
If nothing has happened recently the current situation of cross
referencing in Ddoc sucks. What's currently being used in the Phobos
documentation is the XREF, CXREF and ECXREF ddoc macros. These
macros take two arguments, append
1 - 100 of 169 matches
Mail list logo
