On 2013-09-25 21:55, Dicebot wrote:
UDAs + recent trait to get all unit-tests during compile-time really
favors instead having lot of small independent annotated unit-test blocks.
If you have more than one test per unit test block you always need to
run them together, and in the declared
On Thursday, 26 September 2013 at 06:07:50 UTC, Jacob Carlborg
wrote:
On 2013-09-25 21:55, Dicebot wrote:
UDAs + recent trait to get all unit-tests during compile-time
really
favors instead having lot of small independent annotated
unit-test blocks.
If you have more than one test per unit
On Wednesday, 25 September 2013 at 21:00:00 UTC, Jacob Carlborg
wrote:
There are property functions at line 374 and below to set the
assert handler.
Only the deprecated version works as expected.
import core.exception;
import std.stdio;
alias void function(string file, size_t line, string
On 2013-09-26 20:18, Gary Willoughby wrote:
Only the deprecated version works as expected.
import core.exception;
import std.stdio;
alias void function(string file, size_t line, string msg) AssertHandler;
AssertHandler handler = function(string file, size_t line, string msg)
{
On Thursday, 26 September 2013 at 19:25:46 UTC, Jacob Carlborg
wrote:
I don't know which version of DMD you're using or when this
part of druntime was update, but it's clearly not private
according to the source code:
Joseph Rushton Wakeling:
I have not found this -- using minimallyInitializedArray for
the arrays of built-in types is slower than if I use
uninitializedArray.
Then minimallyInitializedArray should be improved :-)
You seem to be suggesting that using uninitializedArray could
cause general
On Thursday, 26 September 2013 at 20:56:39 UTC, bearophile wrote:
Joseph Rushton Wakeling:
I have not found this -- using minimallyInitializedArray for
the arrays of built-in types is slower than if I use
uninitializedArray.
Then minimallyInitializedArray should be improved :-)
It's odd,
Joseph Rushton Wakeling:
So it's bizarre that there is a performance difference here.
Bizarre findings deserve more experiments and studies :-)
Incidentally, this was why I felt safe using uninitializedArray
for arrays of e.g. long, size_t, etc., because the only
difference at the end of
On Thursday, 26 September 2013 at 21:29:42 UTC, bearophile wrote:
You also have arrays of T. Someday T could be something with
indirections :-) So minimallyInitializedArray is safer
regarding future changes in your code.
T is qualified via isFloatingPoint :-)
Joseph Rushton Wakeling:
T is qualified via isFloatingPoint :-)
I know, but that qualification could change in future evolutions
of your code. Strong type safety means that if you change a type
in your code, with a localized change (like removing
isFloatingPoint at the top of your
On Sunday, 22 September 2013 at 13:13:29 UTC, linkrope wrote:
Have a look at https://github.com/linkrope/dunit, especially at
the Related Projects.
Thanks for the link to
https://github.com/atilaneves/unit-threaded!
My library, unit-threaded, does just that. All unittest blocks
from a module show up as one test case in the output.
On Thursday, 26 September 2013 at 14:56:49 UTC, Dicebot wrote:
On Thursday, 26 September 2013 at 14:51:16 UTC, Jacob Carlborg
wrote:
Exactly. I guess I misunderstood you.
On 2013-09-25 17:16, JohnnyK wrote:
+1 here
yeah DMD is easy to use in linux. I have installed and used it in
several Linux distros and everytime it has just worked. I just
installed DMD on Slackware 14 x86_64 and it was a copy/paste of the
binaries fix up the paths in dmd.comf and Hello
On 2013-09-25 15:36, Nick Sabalausky wrote:
I admit, the VBScript thing is a bit of a hack.
If I recall correctly, you can use JavaScript as an alternative. I would
consider that slightly better. It would of course be better if both
could be avoided.
--
/Jacob Carlborg
On 2013-09-25 18:14, Bruno Medeiros wrote:
But this is all for development-time usage. To have the same tool try to
be an executable installation manager is another thing entirely and, in
my opinion quite ill-suited for dub (see related OP). Where did this
idea even come from??
If dub doesn't
On 2013-09-25 17:51, Bruno Medeiros wrote:
Whoa, no. Application/executable install management as a goal would be a
ridiculously bad idea.
Because that would sit at the wrong abstraction level. The OS package
manager should not be tied to a particular language to compile packages
from. Does it
On Wednesday, 25 September 2013 at 18:34:14 UTC, Jacob Carlborg
wrote:
On Wednesday, 25 September 2013 at 14:46:20 UTC, Bruno Medeiros
wrote:
What are the implications? Does this mean you canr create a
breakpoint for a given source file line?
I have tried that. But want I do know is that
On 2013-09-25 18:13, kraybit wrote:
I believe Manu's example was about X having template parameters as well.
As in
auto v = new Vec3!float(0,0,0);
Either way, what would it be then? a) or b)?
auto v = new!(Vec3!float)(0,0,0); // a)
auto v = new!(Vec3!float(0,0,0)); // b)
?
On 11 September 2013 06:48, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
We've been experimenting with http://code.dlang.org for a while and
things are going well. In particular Sönke has been very active about
maintaining and improving it, which brings further confidence in the
On 2013-09-25 20:27, Johannes Pfau wrote:
Having the compiler rewrite
new(MallocAllocator) MyClass(a,b,c)
to
void[] __buf = MallocAllocator.it.allocate(MyClass.instancesize);
__construct!MyClass(__buf, a, b, c); //Has to handle context ptr
seems like a good solution. It probably has to
On 25.09.2013 19:36, Bruno Medeiros wrote:
On 24/09/2013 19:19, Rainer Schuetze wrote:
the result can be seen here:
http://rainers.github.io/visuald/download.html
Should we add links to Mono-D and DDT aswell?
I think so.
Ok, will add these. Bruno and Alex, is it ok for you? What are the
On 2013-09-25 16:46, Bruno Medeiros wrote:
* Line numbers don't work. Probably some issue with incorrect DWARF
generated
What are the implications? Does this mean you canr create a breakpoint
for a given source file line?
Hmm, I was wrong. Line numbers do work, including stack trace and
On 2013-09-26 09:27, Paolo Invernizzi wrote:
I can confirm that line numbers are missing from the traces, but at
least something like:
(lldb) b test.d:12
Breakpoint 1: where = test_dmd-head_g`D4test3mooFZi + 8, address =
0x000113a0
works correctly, and with tabbed
On 25.09.2013 17:12, Bruno Medeiros wrote:
On 24/09/2013 07:16, Rainer Schuetze wrote:
On 23.09.2013 21:50, Bruno Medeiros wrote:
For DMD+Windows, is there only good debugger support with VisualD? :-(
And how well does that work with 32/64 bit platform variations?
Current options that I
On 25.09.2013 20:49, Jacob Carlborg wrote:
On Wednesday, 25 September 2013 at 17:01:34 UTC, Brad Anderson wrote:
[Environment64]
; VS2008 and VS2012
LINKCMD64=%VCINSTALLDIR%\bin\amd64\link.exe
; VS2012
; LINKCMD64=%VCINSTALLDIR%\bin\x86_amd64\link.exe
Two different for VS2012? Should the
On 2013-09-26 09:44, Manu wrote:
Is there a front-end for dub floating around?
Something like the cygwin package installer comes to mind... (nothing fancy)
I've used dub once, I was very satisfied with the experience. I think a
front-end where you can browse the repository and select/deselect
On 26 September 2013 18:24, Jacob Carlborg d...@me.com wrote:
On 2013-09-26 09:44, Manu wrote:
Is there a front-end for dub floating around?
Something like the cygwin package installer comes to mind... (nothing
fancy)
I've used dub once, I was very satisfied with the experience. I think a
On 26 September 2013 18:11, Rainer Schuetze r.sagita...@gmx.de wrote:
On 25.09.2013 20:49, Jacob Carlborg wrote:
On Wednesday, 25 September 2013 at 17:01:34 UTC, Brad Anderson wrote:
[Environment64]
; VS2008 and VS2012
LINKCMD64=%VCINSTALLDIR%\bin\**amd64\link.exe
; VS2012
;
On Thursday, 26 September 2013 at 08:02:52 UTC, Jacob Carlborg
wrote:
On 2013-09-26 09:27, Paolo Invernizzi wrote:
I can confirm that line numbers are missing from the traces,
but at
least something like:
(lldb) b test.d:12
Breakpoint 1: where = test_dmd-head_g`D4test3mooFZi + 8,
On Thursday, 26 September 2013 at 06:59:05 UTC, Jacob Carlborg
wrote:
On 2013-09-25 18:14, Bruno Medeiros wrote:
But this is all for development-time usage. To have the same
tool try to
be an executable installation manager is another thing
entirely and, in
my opinion quite ill-suited for dub
On Thursday, 26 September 2013 at 07:44:25 UTC, Manu wrote:
I've used dub once, I was very satisfied with the experience. I
think a
front-end where you can browse the repository and
select/deselect packages
conveniently would be a great addition to the experience, if
it's not
already
On Thursday, 26 September 2013 at 06:59:05 UTC, Jacob Carlborg
wrote:
On 2013-09-25 18:14, Bruno Medeiros wrote:
But this is all for development-time usage. To have the same
tool try to
be an executable installation manager is another thing
entirely and, in
my opinion quite ill-suited for dub
On Thursday, 26 September 2013 at 11:17:29 UTC, Dicebot wrote:
..
:%s/look/luck/g
On Thursday, 26 September 2013 at 10:18:07 UTC, John Colvin wrote:
Install packages: yes, but locally, primarily for
dub/development use. Not system-level library installations for
end-users.
I think when people are talking about not wanting it to install
things they are talking about the
On Thursday, 26 September 2013 at 06:25:17 UTC, Jacob Carlborg
wrote:
On 2013-09-25 15:36, Nick Sabalausky wrote:
I admit, the VBScript thing is a bit of a hack.
If I recall correctly, you can use JavaScript as an
alternative. I would consider that slightly better. It would of
course be
On Thursday, 26 September 2013 at 06:57:34 UTC, Jacob Carlborg
wrote:
Instead I need to package my application and libraries for all
the various of package managers out there. Not to mention
neither Mac OS X or Windows comes with a package manager
installed by default.
No, you just let
On Thursday, 26 September 2013 at 12:12:04 UTC, eles wrote:
On Thursday, 26 September 2013 at 11:39:50 UTC, Dicebot wrote:
On Thursday, 26 September 2013 at 06:57:34 UTC, Jacob Carlborg
wrote:
It is neither a build tool nor package manager. It is a tool
While speaking about the dub, somebode
On Thursday, 26 September 2013 at 11:39:50 UTC, Dicebot wrote:
On Thursday, 26 September 2013 at 06:57:34 UTC, Jacob Carlborg
wrote:
It is neither a build tool nor package manager. It is a tool
that aggregates different possible build tools backends and
takes care of resolving build
On Thursday, 26 September 2013 at 10:18:07 UTC, John Colvin wrote:
On Thursday, 26 September 2013 at 06:59:05 UTC, Jacob Carlborg
wrote:
On 2013-09-25 18:14, Bruno Medeiros wrote:
Install packages: yes, but locally, primarily for
dub/development use. Not system-level library installations for
On 25/09/2013 18:09, Sean Kelly wrote:
On Sep 25, 2013, at 7:46 AM, Bruno Medeiros brunodomedeiros+...@gmail.com
wrote:
On 24/09/2013 07:19, Jacob Carlborg wrote:
On 2013-09-23 21:50, Bruno Medeiros wrote:
(what about Mac though?)
The sate of debugging on Mac OS X is worse than on Linux.
On 26/09/2013 09:06, Rainer Schuetze wrote:
I'm not that pessimistic. Every decent debugger on Windows understands
PDB as there are standard libraries to use them. I guess they can be
used (after conveting debug information with cv2pdb for win32) as much
as Visual Studio. The visualization
On 26/09/2013 08:45, Rainer Schuetze wrote:
I'm ok with links being added, although I'm not sure what all this
would help to achieve. It partially duplicates the
http://wiki.dlang.org/IDEs wiki entry, which is linked in the
downloads navigation sidebar.
BTW that sub-sidebar could use a
On Tuesday, 10 September 2013 at 20:48:58 UTC, Andrei
Alexandrescu wrote:
We've been experimenting with http://code.dlang.org for a while
and things are going well. In particular Sönke has been very
active about maintaining and improving it, which brings further
confidence in the future of the
On 26/09/2013 07:57, Jacob Carlborg wrote:
On 2013-09-25 17:51, Bruno Medeiros wrote:
I have to figure out myself how to compile and install the tool. It's only half
way there.
You have to install the yourself, yes. Not compile it. Dub should take
care of the compiling aspect.
If you just
On 25/09/13 19:21, ponce wrote:
On Wednesday, 25 September 2013 at 17:15:25 UTC, ponce wrote:
On Wednesday, 25 September 2013 at 16:59:15 UTC, H. S. Teoh wrote:
Does anybody happen to have a working rational number library in D?
Also David Simcha wrote a better one:
I assume D can do incremental builds? How fast is the compile
time compared to C++? Is it slower? C++ only has to read its
header files and D would need to look at the entire project
source code (or obj files?).
Joseph Rushton Wakeling:
Why was this never incorporated into Phobos?
First it needs the normal review process for Phobos modules :) It
should go in the review queue, if it's good enough for Phobos.
Rational!(BigInt) getTerm(int termNumber) {
I suggest to add inside that rational.d
On Thursday, 26 September 2013 at 14:02:53 UTC, ProgrammingGhost
wrote:
I assume D can do incremental builds? How fast is the compile
time compared to C++? Is it slower? C++ only has to read its
header files and D would need to look at the entire project
source code (or obj files?).
AFAIK,
On 26/09/2013 07:59, Jacob Carlborg wrote:
On 2013-09-25 18:14, Bruno Medeiros wrote:
But this is all for development-time usage. To have the same tool try to
be an executable installation manager is another thing entirely and, in
my opinion quite ill-suited for dub (see related OP). Where did
On 26/09/2013 12:39, Dicebot wrote:
During development you can pretty much run in locally from the source
dir. For end user distribution you must go system-specific way.
To be fair, I don't entirely agree with this. End user
distribution/installation doesn't have to be system-specific. I can
On 26/09/2013 15:16, Bruno Medeiros wrote:
To automatically fetch the required dependencies, making sure they are
correct for you application.
When I say correct here, I also mean compatible, in case that's not
clear.
--
Bruno Medeiros - Software Engineer
On Thursday, 26 September 2013 at 14:20:53 UTC, Bruno Medeiros
wrote:
On 26/09/2013 12:39, Dicebot wrote:
During development you can pretty much run in locally from the
source
dir. For end user distribution you must go system-specific way.
To be fair, I don't entirely agree with this. End
On 2013-09-26 13:37, PauloPinto wrote:
Powershell :)
I have never used that for scripting so I have no idea how it is. Also,
it's not installed by default, at least not on all versions of Windows.
--
/Jacob Carlborg
On 2013-09-26 14:22, Bruno Medeiros wrote:
Why would that be nice? It saves you the small hassle of downloading
GCC+GDB+GDC into it's own installation. With precompiled binaries for
your platform, that should take only 15 minutes of your time and then
you're set (well, a bit again when you want
Hello.
I'm not sure if this belongs here, but I think there is bug at
the very start of the Lexer chapter:
Is U+001A really meant to end the source file?
According to the Unicode specification this is a replacement
character, like the newer U+FFFC. Or is it simply a spelling
error and
On 26-9-2013 17:41, Dominikus Dittes Scherkl wrote:
Hello.
I'm not sure if this belongs here, but I think there is bug at the very start
of the Lexer chapter:
Is U+001A really meant to end the source file?
According to the Unicode specification this is a replacement character, like
the newer
Am 26.09.2013 16:53, schrieb Jacob Carlborg:
On 2013-09-26 13:37, PauloPinto wrote:
Powershell :)
I have never used that for scripting so I have no idea how it is. Also,
it's not installed by default, at least not on all versions of Windows.
It is, since Windows Vista, everything else is
On Sep 25, 2013 8:55 PM, Arjan ar...@ask.me wrote:
On Wed, 25 Sep 2013 17:53:41 +0200, Sean Kelly s...@invisibleduck.org
wrote:
On Sep 24, 2013, at 8:45 PM, deadalnix deadal...@gmail.com wrote:
On Wednesday, 25 September 2013 at 03:12:55 UTC, Walter Bright wrote:
On 9/24/2013 5:39 PM,
On Thursday, 26 September 2013 at 12:14:42 UTC, eles wrote:
On Thursday, 26 September 2013 at 12:12:04 UTC, eles wrote:
On Thursday, 26 September 2013 at 11:39:50 UTC, Dicebot wrote:
On Thursday, 26 September 2013 at 06:57:34 UTC, Jacob
Carlborg wrote:
It is neither a build tool nor package
On Sep 25, 2013 7:35 PM, Jacob Carlborg d...@me.com wrote:
On Wednesday, 25 September 2013 at 14:46:20 UTC, Bruno Medeiros wrote:
Ehhh? What's up with Mac OS X and all those outdated operating system
managed installations? (I'm referring to the similar issues with had with
the JVM)
Apple
Am 26.09.2013 16:24, schrieb Bruno Medeiros:
On 26/09/2013 15:16, Bruno Medeiros wrote:
To automatically fetch the required dependencies, making sure they are
correct for you application.
When I say correct here, I also mean compatible, in case that's not
clear.
Even C++ has them on
On 2013-09-26 16:02, ProgrammingGhost wrote:
I assume D can do incremental builds? How fast is the compile time
compared to C++? Is it slower? C++ only has to read its header files and
D would need to look at the entire project source code (or obj files?).
There are some known problems with
On 2013-09-26 20:17, Iain Buclaw wrote:
I have a sneaky suspicion that it's gcc-4.1 and gdb version that works
with that compiler that is in macports. Though that is just heresay - I
don't /actually/ know.
Macports contains the GCC 4.2 - 4.9 and GDB 7.6 and GDB 6.3.50 with
Apple
On Thursday, 26 September 2013 at 19:31:06 UTC, Jacob Carlborg
wrote:
On 2013-09-26 16:02, ProgrammingGhost wrote:
I assume D can do incremental builds? How fast is the compile
time
compared to C++? Is it slower? C++ only has to read its header
files and
D would need to look at the entire
On 26/09/13 16:09, bearophile wrote:
First it needs the normal review process for Phobos modules :) It should go in
the review queue, if it's good enough for Phobos.
Fair enough, I was wondering if there was any reason David never submitted it.
I suggest to add inside that rational.d module
On 2013-09-26 13:39, Dicebot wrote:
No, you just let maintainers interested in target systems to take care
of it. And package for 2-3 you care about _personally_. It is an
obsolete idea that developer of a library/program should do any
packaging at all. If your program is any good, there will
On 2013-09-26 15:53, Bruno Medeiros wrote:
You have to install the yourself, yes. Not compile it. Dub should take
care of the compiling aspect.
Have you tried it? It does _not_ compile a package when running dub
install.
If you just want to use the tool executable artifact, dub is likely
On 2013-09-26 13:17, Dicebot wrote:
Good look getting all those small trivial libraries into official
repositories. Actually, some distros even prohibit pure source packages
at all.
That's exactly why dub _should_ install packages. If you don't like,
don't use it.
You should install it
On 2013-09-26 16:16, Bruno Medeiros wrote:
Are... you... serious?... O_O
There are incredibly important benefits for development-time usage.
To automatically fetch the required dependencies, making sure they are
correct for you application. Easily upgrade the version of dependencies?
Support
On 2013-09-26 10:39, Manu wrote:
http://code.dlang.org/
Is that not a package list?
I only just skimmed this thread, but it seemed dub installs packages to
me...
What did it install when I told it to install vibe.d and some other
companion pieces then?
If you run dub install it will
On 2013-09-26 21:44, Dicebot wrote:
Some of those has been just recently fixed ;)
Cool, do you have the numbers for the bugzilla issues?
--
/Jacob Carlborg
On 2013-09-25 18:14, Bruno Medeiros wrote:
But this is all for development-time usage. To have the same tool try to
be an executable installation manager is another thing entirely and, in
my opinion quite ill-suited for dub (see related OP). Where did this
idea even come from??
We can take
On Thursday, 26 September 2013 at 14:02:53 UTC, ProgrammingGhost
wrote:
I assume D can do incremental builds? How fast is the compile
time compared to C++? Is it slower? C++ only has to read its
header files and D would need to look at the entire project
source code (or obj files?).
dmd
On Thursday, 26 September 2013 at 20:12:38 UTC, Jacob Carlborg
wrote:
On 2013-09-26 21:44, Dicebot wrote:
Some of those has been just recently fixed ;)
Cool, do you have the numbers for the bugzilla issues?
http://d.puremagic.com/issues/show_bug.cgi?id=9571
On Friday, 13 September 2013 at 16:09:11 UTC, Sönke Ludwig wrote:
Something like:
def somevar=somevalue
libs $somevar
or
template sometemplate {
libs gdi32 user32
}
configuration gui {
mixin sometemplate
}
A little redundancy doesn't hurt so long as the overall package
description
On Thursday, September 26, 2013 23:29:56 John Colvin wrote:
On Thursday, 26 September 2013 at 14:02:53 UTC, ProgrammingGhost
wrote:
I assume D can do incremental builds? How fast is the compile
time compared to C++? Is it slower? C++ only has to read its
header files and D would need to
On 9/26/13 7:00 AM, Joseph Rushton Wakeling wrote:
On 25/09/13 19:21, ponce wrote:
On Wednesday, 25 September 2013 at 17:15:25 UTC, ponce wrote:
On Wednesday, 25 September 2013 at 16:59:15 UTC, H. S. Teoh wrote:
Does anybody happen to have a working rational number library in D?
Also David
On Thu, Sep 26, 2013 at 04:50:47PM -0700, Andrei Alexandrescu wrote:
On 9/26/13 7:00 AM, Joseph Rushton Wakeling wrote:
On 25/09/13 19:21, ponce wrote:
On Wednesday, 25 September 2013 at 17:15:25 UTC, ponce wrote:
On Wednesday, 25 September 2013 at 16:59:15 UTC, H. S. Teoh wrote:
Does anybody
On Thursday, September 26, 2013 22:05:35 Jacob Carlborg wrote:
It's not, that's another big issue with dub. It doesn't lock the
dependency graph. If you have the packages:
This is definitely something that needs to be sorted out.
- Jonathan M Davis
On Thursday, September 26, 2013 15:20:53 Bruno Medeiros wrote:
I just don't think dub should aim for that goal. It should mainly be a
build tool and package manager for development-time usage.
Agreed. I don't think that dub should have anything to with installing
programs or installing
Running dmd with huge page backed malloc resulted in about 10%
faster compilations.
This looks very promising though other tests with some D GC
microbenchmarks did not benefit from huge pages.
You can read more about this here.
On Friday, September 27, 2013 02:31:21 Martin Nowak wrote:
I'm interested in adding a runtime parameter that would advise
the GC to preferably use huge pages as backing memory.
[snip]
Any good ideas for druntime?
IIRC, Leandro made his concurrent GC use environment variables to set stuff
like
On Friday, 27 September 2013 at 00:31:23 UTC, Martin Nowak wrote:
Running dmd with huge page backed malloc resulted in about 10%
faster compilations.
This looks very promising though other tests with some D GC
microbenchmarks did not benefit from huge pages.
You can read more about this here.
On my OS X SDK, locale.h has:
#define LC_ALL 0
#define LC_COLLATE 1
#define LC_CTYPE2
#define LC_MONETARY 3
#define LC_NUMERIC 4
#define LC_TIME 5
#define LC_MESSAGES 6
#define _LC_LAST
On 9/26/2013 7:38 PM, Luís Marques l...@luismarques.eu wrote:
The mismatch of course causes problems.
std.c.locale must match the values in the host system's locale.h. If it
doesn't, it's a bug.
Does anyone know:
If an extern(c) function is defined as returning a bool, does D handle
the conversion automatically into true and false? Should it be defined
as returning an int? On a 64 bit machine? Does this depend on the
compiler used to compile the library? int32_t? int_64_t?
Is
Charles Hixson:
Does anyone know:
If an extern(c) function is defined as returning a bool, does D
handle the conversion automatically into true and false?
Should it be defined as returning an int? On a 64 bit
machine? Does this depend on the compiler used to compile the
library?
On 2013-09-26 20:56, Charles Hixson wrote:
Does anyone know:
If an extern(c) function is defined as returning a bool, does D handle
the conversion automatically into true and false? Should it be defined
as returning an int? On a 64 bit machine? Does this depend on the
compiler used to
Is there an equivalent?
Hello all,
Suppose I create a new dynamic array:
auto arr = new int[10];
If I recall right, the values inside arr will be auto-initialized to int.init
(which is 0).
Again, if I recall right, there's a simple way to increase performance by not
auto-initializing the values, but I can't
On Thu, Sep 26, 2013 at 11:23:10PM +0200, Joseph Rushton Wakeling wrote:
Hello all,
Suppose I create a new dynamic array:
auto arr = new int[10];
If I recall right, the values inside arr will be auto-initialized to
int.init (which is 0).
Again, if I recall right, there's a simple
On 09/26/2013 12:19 PM, bearophile wrote:
Charles Hixson:
Does anyone know:
If an extern(c) function is defined as returning a bool, does D
handle the conversion automatically into true and false? Should it
be defined as returning an int? On a 64 bit machine? Does this
depend on the
I'm working on a toy IRC bot. Much of the logic involved is
translating the incoming raw IRC string into something that makes
sense (so now I have two problems, etc). But I managed to cook up
a regex that so far seems to work well. Time for callgrind!
Grouped by source file, most time is
Charles Hixson:
So... if C returns an int64_t and I declare it as an int32_t,
will this cause problems? What about if C returns an int32_t
and I declare it as an int64_t? Or *is* there a good way to
handle this? (I think that there's an error code I could
interrogate if I need to just
On 26/09/13 23:23, H. S. Teoh wrote:
You mean:
int[10] arr = void;
It's what I was thinking of, but does that also work with a dynamic array
declaration?
int[] arr = new int[n];
On Thursday, 26 September 2013 at 22:14:27 UTC, Joseph Rushton
Wakeling wrote:
It's what I was thinking of, but does that also work with a
dynamic array declaration?
int[] arr = new int[n];
Check out std.array.uninitializedArray.
Matej
On Thursday, 26 September 2013 at 22:21:58 UTC, Matej Nanut wrote:
On Thursday, 26 September 2013 at 22:14:27 UTC, Joseph Rushton
Wakeling wrote:
It's what I was thinking of, but does that also work with a
dynamic array declaration?
int[] arr = new int[n];
Check out
JR:
Is this working as expected? Or am I doing it wrong?
I am not sure how a IRC bot could consume more than a tiny
fraction of the CPU time of a modern multi-GHz processor.
And I am not sure if regular expressions are a good idea to
implement a IRC interface.
But the author of the
On Wednesday, 25 September 2013 at 15:32:08 UTC, Lemonfiend wrote:
The docs only mention
http://assimp.sourceforge.net/lib_html/config_8h.html#afc0a4c00fb90c345eb38fe3f7d7c8637
which is less than helpful..
I'm not sure what the problem is here. Just as the docs say, you
have to set the
On Thursday, 26 September 2013 at 23:04:22 UTC, bearophile wrote:
I am not sure how a IRC bot could consume more than a tiny
fraction of the CPU time of a modern multi-GHz processor.
Nor does it bite into my 8 gigabytes of ram.
Forgive me, but the main culprit in all of this is still me doing
1 - 100 of 135 matches
Mail list logo
