Hello fair D hackers!
I’d like to announce the availability of 3T Software Labs MongoDB
tools to the readers of this list.
To forward-thinking D adopters and MongoDB users alike, I’d like
to extend a special 60-day trial of all the apps in our suite at
On Wed, 16 Apr 2014 20:15:21 -0700, Kapps opantm2+s...@gmail.com wrote:
On Wednesday, 16 April 2014 at 22:45:45 UTC, Adam Wilson wrote:
On Fri, 04 Apr 2014 07:35:18 -0700, Alexander Bothe
i...@alexanderbothe.com wrote:
On Monday, 31 March 2014 at 21:41:26 UTC, Théo Bueno wrote:
Mono-D
On Thursday, 17 April 2014 at 15:50:04 UTC, Graham Fawcett wrote:
To clarify: you've built these tools in D? Or do the tools
provide some kind of D API to MongoDB?
Best,
Graham Fawcett (not the 3T software Graham; last names are
helpful!)
They've posted this same thing to a number of
On Friday, 18 April 2014 at 03:54:46 UTC, Rikki Cattermole wrote:
On Thursday, 17 April 2014 at 15:50:04 UTC, Graham Fawcett
wrote:
To clarify: you've built these tools in D? Or do the tools
provide some kind of D API to MongoDB?
Best,
Graham Fawcett (not the 3T software Graham; last names
On Thu, 17 Apr 2014 09:56:32 -0700, Adam Wilson flybo...@gmail.com wrote:
On Wed, 16 Apr 2014 20:15:21 -0700, Kapps opantm2+s...@gmail.com wrote:
On Wednesday, 16 April 2014 at 22:45:45 UTC, Adam Wilson wrote:
On Fri, 04 Apr 2014 07:35:18 -0700, Alexander Bothe
i...@alexanderbothe.com
On Wednesday, 16 April 2014 at 23:14:27 UTC, Walter Bright wrote:
On 4/16/2014 3:45 PM, Ola Fosheim Grøstad I've written
several myself that do not use malloc.
If it is shared or can call brk() it should be annotated.
Even the Linux kernel does not use malloc. Windows offers many
ways to
On Thursday, 17 April 2014 at 03:14:21 UTC, Manu via
Digitalmars-d wrote:
Obviously, a critical part of ARC is the compilers ability to
reduce
redundant inc/dec sequences.
You need whole program opimization to do this well. Which I am
strongly in favour of, btw.
I've never heard of Obj-C
It occurs to me that a central issue regarding the memory management
debate, and a major limiting factor with respect to options, is the fact
that, currently, it's impossible to tell a raw pointer apart from a gc
pointer.
Is this is a problem worth solving? And would it be as big an enabler to
On Thursday, 17 April 2014 at 04:19:00 UTC, Manu via
Digitalmars-d wrote:
On 17 April 2014 09:20, Walter Bright via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 4/16/2014 3:42 PM, Adam Wilson wrote:
ARC may in fact be the most advantageous for a specific use
case, but
that in no
way
On Thursday, 17 April 2014 at 06:56:11 UTC, Paulo Pinto wrote:
There is a reason why Dalvik is being replaced by ART.
AoT compilation?
Btw, AFAIK the GC is deprecated for Objective-C from OS-X 10.8.
Appstore requires apps to be GC free... Presumably for good
reasons.
On Thursday, 17 April 2014 at 08:05:42 UTC, Ola Fosheim Grøstad
wrote:
On Thursday, 17 April 2014 at 06:56:11 UTC, Paulo Pinto wrote:
There is a reason why Dalvik is being replaced by ART.
AoT compilation?
Not only. Dalvk was left to bit rotten and has hardly seen any
updates since 2.3.
You can do anything, what fits your task, see RefCounted and
Unique for an example on how to write smart pointers.
On Thursday, 17 April 2014 at 08:22:32 UTC, Paulo Pinto wrote:
Of course it was sold at WWDC as ARC is better than GC and
not as ARC is better than the crappy GC implementation we have
done.
I have never seen a single instance of a GC based system doing
anything smooth in the realm of
On Tuesday, 15 April 2014 at 17:01:38 UTC, Walter Bright wrote:
http://wiki.dlang.org/DIP60
Start on implementation:
https://github.com/D-Programming-Language/dmd/pull/3455
This is a good start, but I am sure I am not the only person who
thought maybe we should have this on a module level.
On Thursday, 17 April 2014 at 08:52:28 UTC, Ola Fosheim Grøstad
wrote:
On Thursday, 17 April 2014 at 08:22:32 UTC, Paulo Pinto wrote:
Of course it was sold at WWDC as ARC is better than GC and
not as ARC is better than the crappy GC implementation we
have done.
I have never seen a single
On Thursday, 17 April 2014 at 09:22:55 UTC, Dejan Lekic wrote:
On Tuesday, 15 April 2014 at 17:01:38 UTC, Walter Bright wrote:
http://wiki.dlang.org/DIP60
Start on implementation:
https://github.com/D-Programming-Language/dmd/pull/3455
This is a good start, but I am sure I am not the only
Walter Bright:
http://wiki.dlang.org/DIP60
Start on implementation:
https://github.com/D-Programming-Language/dmd/pull/3455
If I have this program:
__gshared int x = 5;
int main() {
int[] a = [x, x + 10, x * x];
return a[0] + a[1] + a[2];
}
If I compile with all optimizations DMD
Adam D. Ruppe:
What I want is a __trait that scans for all call expressions in
a particular function and returns all those functions.
Then, we can check them for UDAs using the regular way and
start to implement library defined things like @safe, @nogc,
etc.
This is the start of a nice
On Thursday, 17 April 2014 at 09:32:52 UTC, Paulo Pinto wrote:
Any iOS device runs circles around those systems, hence why I
always like to make clear it was Apple's failure to make a
workable GC in a C based language and not the virtues of pure
ARC over pure GC.
I am not making an argument
Is it possible to compile this main with a future version of
ldc2 if I compile the code with full optimizations?
Sorry, I meant to ask if it's possible to compile this main with
a @nogc applied to it if I compile it with ldc2 with full
optimizations.
Bye,
bearophile
I have noticed that Walter has re-open this enhancement (re
Resourcement Management) quite recently (Feb 2014). I originally
filed it in 2009. Is anyone able to say why ?
Nick
According to the modification history for that bug, you reopened it back on May 4, 2009. Walter
merely changed the version id recently from 1.041 to D1.
https://issues.dlang.org/show_activity.cgi?id=2757
On 4/17/14, 2:55 AM, Nick B via Digitalmars-d wrote:
I have noticed that Walter has
On 04/17/14 11:33, Rikki Cattermole via Digitalmars-d wrote:
On Thursday, 17 April 2014 at 09:22:55 UTC, Dejan Lekic wrote:
On Tuesday, 15 April 2014 at 17:01:38 UTC, Walter Bright wrote:
http://wiki.dlang.org/DIP60
Start on implementation:
On Thursday, 17 April 2014 at 09:55:38 UTC, Ola Fosheim Grøstad
wrote:
On Thursday, 17 April 2014 at 09:32:52 UTC, Paulo Pinto wrote:
Any iOS device runs circles around those systems, hence why I
always like to make clear it was Apple's failure to make a
workable GC in a C based language and
On Thursday, 17 April 2014 at 10:38:54 UTC, Artur Skawina via
Digitalmars-d wrote:
Yes, the current attribute situation in D is a mess.
A more coherent D syntax would make the language more
approachable. I find the current syntax to be somewhat annoying.
I'd also like to see coherent naming
On Thursday, 17 April 2014 at 10:38:54 UTC, Artur Skawina via
Digitalmars-d wrote:
On 04/17/14 11:33, Rikki Cattermole via Digitalmars-d wrote:
On Thursday, 17 April 2014 at 09:22:55 UTC, Dejan Lekic wrote:
On Tuesday, 15 April 2014 at 17:01:38 UTC, Walter Bright
wrote:
On 17 April 2014 18:22, Paulo Pinto via Digitalmars-d
digitalmars-d@puremagic.com wrote:
Of course it was sold at WWDC as ARC is better than GC and not as ARC
is better than the crappy GC implementation we have done.
The argument is, GC is not appropriate for various classes of software. It
I'm not convinced that any automatic memory management scheme
will buy much with real time applications. Generally with
real-time processes, you need to pre-allocate. I think GC could
be feasible for a real-time application if the GC is precise and
collections are scheduled, instead of run
On Thursday, 17 April 2014 at 11:31:52 UTC, Manu via
Digitalmars-d wrote:
ARC offers a solution that is usable by all parties.
Is this a proven statement?
If that paper is right then ARC with cycle management is in fact
equivalent to Garbage Collection.
Do we have evidence to the contrary?
On Wed, 16 Apr 2014 13:39:36 -0400, Walter Bright
newshou...@digitalmars.com wrote:
On 4/16/2014 1:49 AM, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
Btw, I think you should add @noalloc also which prevents both new and
malloc. It
would be useful for real time
On 17 April 2014 18:52, via Digitalmars-d digitalmars-d@puremagic.comwrote:
On Thursday, 17 April 2014 at 08:22:32 UTC, Paulo Pinto wrote:
Of course it was sold at WWDC as ARC is better than GC and not as ARC
is better than the crappy GC implementation we have done.
I have never seen a
On Wed, 16 Apr 2014 12:09:49 -0400, sclytrack sclytr...@fake.com wrote:
On Saturday, 14 December 2013 at 15:16:50 UTC, Jacob Carlborg wrote:
On 2013-12-14 15:53, Steven Schveighoffer wrote:
I realize this is really old, and I sort of dropped off the D cliff
because all of a sudden I had 0
On 2014-04-17 03:13:48 +, Manu via Digitalmars-d
digitalmars-d@puremagic.com said:
Obviously, a critical part of ARC is the compilers ability to reduce
redundant inc/dec sequences. At which point your 'every time' assertion is
false. C++ can't do ARC, so it's not comparable.
With proper
On 17 April 2014 21:57, John Colvin via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Thursday, 17 April 2014 at 11:31:52 UTC, Manu via Digitalmars-d wrote:
ARC offers a solution that is usable by all parties.
Is this a proven statement?
If that paper is right then ARC with cycle
On Wed, 16 Apr 2014 02:59:29 -0400, Steve Teale
steve.te...@britseyeview.com wrote:
On Tuesday, 15 April 2014 at 16:02:33 UTC, Steven Schveighoffer wrote:
Sorry, I had this wrong. The [] on the left hand side is actually part
of the []= operator. But on the right hand side, it simply is a
On 17 April 2014 18:20, Kagamin via Digitalmars-d
digitalmars-d@puremagic.com wrote:
You can do anything, what fits your task, see RefCounted and Unique for an
example on how to write smart pointers.
... what?
I don't think you understood my post.
void f(void* ptr)
{
// was ptr allocated
On Wed, 16 Apr 2014 04:05:57 -0400, Kagamin s...@here.lot wrote:
On Tuesday, 15 April 2014 at 15:59:31 UTC, Steven Schveighoffer wrote:
Requiring it simply adds unneeded hoops through which you must jump,
the left hand side denotes the operation, the right hand side does not
Unfortunately,
This is very very annoying. Every time I open one of these messages I get
a huge pregnant 5-second pause, along with the Mac Beach Ball (hourglass)
while this message is opened in my news reader.
Whatever this is, can we get rid of it?
-Steve
I'm just going to put my 2-cents into this discussion, it's my
personal opinion that while _allocations_ should be removed from
phobos wherever possible, replacing GC usage with manual calls to
malloc/free has no place in the standard library, as it's quite simply
a mess that is really not needed,
On 17 April 2014 22:28, Michel Fortin via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 2014-04-17 03:13:48 +, Manu via Digitalmars-d
digitalmars-d@puremagic.com said:
Obviously, a critical part of ARC is the compilers ability to reduce
redundant inc/dec sequences. At which
I think the biggest advantage to this distinction would really be the
cross-language API's, the GC can determine which pointers it owns,
although I don't believe it currently exposes this capability.
On 4/17/14, Manu via Digitalmars-d digitalmars-d@puremagic.com wrote:
On 17 April 2014 18:20,
On Thursday, 17 April 2014 at 12:20:06 UTC, Manu via
Digitalmars-d wrote:
See, I just don't find managed memory incompatible with 'low
level' realtime or embedded code, even on tiny microcontrollers
in principle.
RC isn't incompatible with realtime, since the overhead is O(1).
But it is
On Thu, 17 Apr 2014 14:08:29 +0100, Orvid King via Digitalmars-d
digitalmars-d@puremagic.com wrote:
I'm just going to put my 2-cents into this discussion, it's my
personal opinion that while _allocations_ should be removed from
phobos wherever possible, replacing GC usage with manual calls to
On Wed, 16 Apr 2014 18:38:23 +0100, Walter Bright
newshou...@digitalmars.com wrote:
On 4/16/2014 8:01 AM, qznc wrote:
However, what is still an open issue is that @nogc can be stopped by
allocations
in another thread. We need threads which are not affected by
stop-the-world. As
far as I
On 17 April 2014 23:17, via Digitalmars-d digitalmars-d@puremagic.comwrote:
On Thursday, 17 April 2014 at 12:20:06 UTC, Manu via Digitalmars-d wrote:
See, I just don't find managed memory incompatible with 'low level'
realtime or embedded code, even on tiny microcontrollers in principle.
On 17 April 2014 23:14, Orvid King via Digitalmars-d
digitalmars-d@puremagic.com wrote:
I think the biggest advantage to this distinction would really be the
cross-language API's, the GC can determine which pointers it owns,
although I don't believe it currently exposes this capability.
But
I should probably have said heap allocation rather than just
allocation, because the alloca calls are the ones that would have the
real benefit, those realtime applications are the reason I hope to be
able to implement an async collection mode. If I were able to
implement even a moderately
On 4/17/14, Brad Roberts via Digitalmars-d digitalmars-d@puremagic.com wrote:
According to the modification history for that bug
Btw, that's the first time I saw that page, and I always wanted this
feature. But, where is it linked from? (how did you find it?)
On 04/17/2014 02:34 PM, Manu via Digitalmars-d wrote:
On 17 April 2014 21:57, John Colvin via Digitalmars-d
digitalmars-d@puremagic.com mailto:digitalmars-d@puremagic.com wrote:
On Thursday, 17 April 2014 at 11:31:52 UTC, Manu via Digitalmars-d
wrote:
ARC offers a solution that
On Thursday, 17 April 2014 at 13:43:17 UTC, Manu via
Digitalmars-d wrote:
You would never allocate in a ray tracing loop. If you need a
temp, you
would use some pre-allocation strategy.
Path-tracing is predictable, but regular ray tracing may spawn
many rays per hit. So you pre-allocate a
On Thu, 17 Apr 2014 10:12:20 -0400, Andrej Mitrovic via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 4/17/14, Brad Roberts via Digitalmars-d digitalmars-d@puremagic.com
wrote:
According to the modification history for that bug
Btw, that's the first time I saw that page, and I
On 04/17/2014 08:55 AM, Manu via Digitalmars-d wrote:
It occurs to me that a central issue regarding the memory management
debate, and a major limiting factor with respect to options, is the fact
that, currently, it's impossible to tell a raw pointer apart from a gc
pointer.
Is this is a
On Thu, 17 Apr 2014 10:52:19 -0400, Timon Gehr timon.g...@gmx.ch wrote:
On 04/17/2014 08:55 AM, Manu via Digitalmars-d wrote:
If an API
could be provided in druntime, it may be used by GC's, ARC, allocators,
or systems that operate at the barrier between languages.
There already is.
bool
On Tuesday, 15 April 2014 at 17:01:38 UTC, Walter Bright wrote:
http://wiki.dlang.org/DIP60
Start on implementation:
https://github.com/D-Programming-Language/dmd/pull/3455
OK, a bit late to the thread, seeing how it has already went to
ARC off-topic domain :( An attempt to get back to the
On Monday, 17 March 2014 at 21:25:34 UTC, bearophile wrote:
Jared Miller:
And yes, I think that a matrix / linear algebra library, as
well as NumPy-style ND-Arrays are great candidates for future
Phobos modules.
I suggest to not put such library in Phobos before few years of
usage in the
On Thursday, 17 April 2014 at 15:02:27 UTC, Dicebot wrote:
void foo(OutputRange buffer)
{
buffer.put(42);
}
`foo` can't be @nogc here if OutputRange uses GC as backing
allocator. However I'd really like to use it to verify that no
Can't you write foo as a template? Then if buffer is a
On 4/17/14, Steven Schveighoffer via Digitalmars-d
digitalmars-d@puremagic.com wrote:
It's on the bug page. Look after the Modified field at the top.
Ah the History link. Thanks.
Ola Fosheim Grøstad:
Where this falls apart is when you introduce a compacting GC
and the @nogc code is run in a real time priority thread. Then
you need both @nogc_function_calls and @nogc_memory .
Perhaps the @nogc proposal is not flexible enough. So probably
the problem needs to be
On Thursday, 17 April 2014 at 15:39:38 UTC, Ola Fosheim Grøstad
wrote:
On Thursday, 17 April 2014 at 15:02:27 UTC, Dicebot wrote:
void foo(OutputRange buffer)
{
buffer.put(42);
}
`foo` can't be @nogc here if OutputRange uses GC as backing
allocator. However I'd really like to use it to
On Thursday, 17 April 2014 at 15:48:29 UTC, bearophile wrote:
Ola Fosheim Grøstad:
Where this falls apart is when you introduce a compacting GC
and the @nogc code is run in a real time priority thread. Then
you need both @nogc_function_calls and @nogc_memory .
Perhaps the @nogc proposal is
Just fixing an obvious typo in my code (that is still incomplete).
struct someRange
{
ulong seq;
bool fresh = true;
long line;
dchar front;
// and lets just pretend that there is
// somewhere for more characters to come from!
void popFront()
{
//
On Wednesday, 16 April 2014 at 13:59:15 UTC, Bienlein wrote:
Being able to spawn as many thousand threads as needed without
caring about it seems to be an important aspect for being an
interesting offering for developing server-side software. It
would be nice if D could also play in that
I added a lookup scheme of my own, its not as fast as Walters (in fact
its the slowest without -inline - release -O) but it uses 1 bit per
entry in the table instead of a whole byte so you can have lots and lots
of different tables. I'm even reasonably sure that it works correctly!
Size_t on x86 is uint,on x64 is ulong,it's a good thing?
I don't think is ok.
it creates many convert thing,such as length is ulong ,must
cast to int or cast to uint. It will be waste of time ,I think.
@nogc
module mymodule;
This is precisely what I had in mind.
On Thursday, 17 April 2014 at 15:02:27 UTC, Dicebot wrote:
=== Problem #1 ===
First problem is that, by an analogy with `pure`, there is no
such thing as weakly @nogc@. A common pattern for performance
intensive code is to use output buffers of some sort:
void foo(OutputRange buffer)
{
On Thursday, 17 April 2014 at 16:36:29 UTC, FrankLike wrote:
Size_t on x86 is uint,on x64 is ulong,it's a good thing?
I don't think is ok.
it creates many convert thing,such as length is ulong ,must
cast to int or cast to uint. It will be waste of time ,I think.
It's the same in C
On 4/16/2014 8:13 PM, Manu via Digitalmars-d wrote:
On 17 April 2014 03:37, Walter Bright via Digitalmars-d
digitalmars-d@puremagic.com mailto:digitalmars-d@puremagic.com wrote:
ARC has very serious problems with bloat and performance.
This is the first I've heard of it, and I've been going
On 4/17/2014 9:42 AM, monarch_dodra wrote:
That said, your proposal could be applied for all attributes in general. Not
just @nogc in particular. In practice though, a simple unittest should cover all
your needs. simply create a @nogc (pure, nothrow, safe, ctfe-able) unitest, and
call it with a
On 4/17/2014 8:02 AM, Dicebot wrote:
=== Problem #1 ===
First problem is that, by an analogy with `pure`, there is no such thing as
weakly @nogc@. A common pattern for performance intensive code is to use
output buffers of some sort:
void foo(OutputRange buffer)
{
buffer.put(42);
}
`foo`
On Thu, 17 Apr 2014 04:35:34 -0400, Walter Bright
newshou...@digitalmars.com wrote:
On 4/16/2014 8:13 PM, Manu via Digitalmars-d wrote:
I've never heard of Obj-C users complaining about the inc/dec costs.
Obj-C only uses ARC for a minority of the objects.
Really? Every Obj-C API I've
On 4/17/2014 2:32 AM, Paulo Pinto wrote:
Similar approach was taken by Microsoft with their C++/CX and COM integration.
So any pure GC basher now uses Apple's example, with a high probability of not
knowing the technical issues why it came to be like that.
I also wish to reiterate that GC's
On 4/17/2014 5:34 AM, Manu via Digitalmars-d wrote:
People who care would go to the effort of manually marking weak references.
And that's not compatible with having a guarantee of memory safety.
Walter Bright:
I know that you bring up the array literal issue and gc a lot,
but this is simply not a major issue with @nogc. The @nogc will
tell you if it will allocate on the gc or not, on a case by
case basis, and you can use easy workarounds as necessary.
Assuming you have seen my
On Thursday, 17 April 2014 at 16:57:32 UTC, Walter Bright wrote:
With current limitations @nogc is only useful to verify that
embedded code which
does not have GC at all does not use any GC-triggering
language features before
it comes to weird linker errors / rt-asserts. But that does
not work
On Thursday, 17 April 2014 at 15:49:44 UTC, Dicebot wrote:
put() may call GC to grow the buffer, this is the very point.
What is desired is to check if anything _else_ does call GC,
thus the weak @nogc parallel.
What do you need that for?
Of course, resorting to templates requires some
On Thursday, 17 April 2014 at 12:38:24 UTC, Steven Schveighoffer
wrote:
I actually am ignorant of how this works under the hood for
slices, what triggers element-wise copy vs. assign.
The compiler compiles whatever compiles. Currently only one
mistake (type) is required to compile the wrong
On Thursday, 17 April 2014 at 17:48:39 UTC, Ola Fosheim Grøstad
wrote:
On Thursday, 17 April 2014 at 15:49:44 UTC, Dicebot wrote:
put() may call GC to grow the buffer, this is the very point.
What is desired is to check if anything _else_ does call GC,
thus the weak @nogc parallel.
What do
On Thursday, 17 April 2014 at 16:27:26 UTC, Alix Pexton wrote:
I added a lookup scheme of my own, its not as fast as Walters
(in fact its the slowest without -inline - release -O) but it
uses 1 bit per entry in the table instead of a whole byte so
you can have lots and lots of different
On Thu, Apr 17, 2014 at 03:16:20PM +, CJS via Digitalmars-d wrote:
On Monday, 17 March 2014 at 21:25:34 UTC, bearophile wrote:
Jared Miller:
And yes, I think that a matrix / linear algebra library, as well as
NumPy-style ND-Arrays are great candidates for future Phobos
modules.
I
On Thursday, 17 April 2014 at 14:59:14 UTC, Steven Schveighoffer
wrote:
I don't think this is a viable mechanism to check pointers.
It's too slow.
I suggested to write a smart pointer. It could provide
compile-time checks and whatever developer feels like.
On Thursday, 17 April 2014 at 12:39:59 UTC, Manu via
Digitalmars-d wrote:
void f(void* ptr)
{
// was ptr allocated with malloc, or new?
Then what?
On Thursday, 17 April 2014 at 18:00:25 UTC, Dicebot wrote:
Such weak @nogc could help to avoid triggering allocations by
an accident and encourage usage of output ranges / buffers.
Ok, more like a lintish feature of the remind me if I use too
much of feature X in these sections variety.
I
On Thursday, 17 April 2014 at 18:18:49 UTC, Ola Fosheim Grøstad
wrote:
On Thursday, 17 April 2014 at 18:00:25 UTC, Dicebot wrote:
Such weak @nogc could help to avoid triggering allocations by
an accident and encourage usage of output ranges / buffers.
Ok, more like a lintish feature of the
On Thursday, 17 April 2014 at 18:26:25 UTC, Dicebot wrote:
I think for your scenario having dedicated @nogc threads makes
more sense, this can be built on top of plain function
attribute @nogc.
Yes, that could be a life saver. Nothing is more annoying than
random crashes due to concurrency
On 4/17/2014 10:05 AM, Steven Schveighoffer wrote:
Obj-C only uses ARC for a minority of the objects.
Really? Every Obj-C API I've seen uses Objective-C objects, which all use RC.
And what about all allocated items?
A UI is a good use case for ARC. A UI doesn't require high performance.
On Tuesday, 15 April 2014 at 19:57:59 UTC, monarch_dodra wrote:
I have an issue related to adding an extra attribute:
Attributes of non-template functions. Currently, you have to
mark most functions as already pure, nothrow and @safe. If we
are adding another attribute. Code will start looking
You are doing it all wrong. The easiest way to compute
the col position is the following :
col_pos = 0;
if (non_tab_character_encounter)
col_pos++;
else
col_pos += tab_length - col_pos % tab_length;
That's it.
On Thu, 17 Apr 2014 14:47:00 -0400, Walter Bright
newshou...@digitalmars.com wrote:
On 4/17/2014 10:05 AM, Steven Schveighoffer wrote:
Obj-C only uses ARC for a minority of the objects.
Really? Every Obj-C API I've seen uses Objective-C objects, which all
use RC.
And what about all
On Thursday, 17 April 2014 at 18:07:24 UTC, ixid wrote:
I feel like there must be a way of making a fast bit look up
but my version is only moderate in speed. You can get all the
bits you need on two 64 bit registers or one SSE register. I
haven't tried bt, does that work with a 64 bit
On 4/17/2014 12:41 PM, Steven Schveighoffer wrote:
On Thu, 17 Apr 2014 14:47:00 -0400, Walter Bright newshou...@digitalmars.com
wrote:
On 4/17/2014 10:05 AM, Steven Schveighoffer wrote:
Obj-C only uses ARC for a minority of the objects.
Really? Every Obj-C API I've seen uses Objective-C
On 4/17/2014 10:41 AM, Dicebot wrote:
On Thursday, 17 April 2014 at 16:57:32 UTC, Walter Bright wrote:
With current limitations @nogc is only useful to verify that embedded code which
does not have GC at all does not use any GC-triggering language features before
it comes to weird linker errors
1986 - Brad Cox and Tom Love create Objective-C, announcing this
language has all the memory safety of C combined with all the
blazing speed of Smalltalk. Modern historians suspect the two
were dyslexic.
(
http://james-iry.blogspot.no/2009/05/brief-incomplete-and-mostly-wrong.html
)
On Thursday, 17 April 2014 at 19:51:38 UTC, Walter Bright wrote:
On 4/17/2014 10:41 AM, Dicebot wrote:
On Thursday, 17 April 2014 at 16:57:32 UTC, Walter Bright
wrote:
With current limitations @nogc is only useful to verify that
embedded code which
does not have GC at all does not use any
On Thu, 17 Apr 2014 15:55:10 -0400, Walter Bright
newshou...@digitalmars.com wrote:
On 4/17/2014 12:41 PM, Steven Schveighoffer wrote:
On Thu, 17 Apr 2014 14:47:00 -0400, Walter Bright
newshou...@digitalmars.com
wrote:
On 4/17/2014 10:05 AM, Steven Schveighoffer wrote:
Obj-C only uses
On 4/17/2014 1:30 PM, Steven Schveighoffer wrote:
I'm not saying it's costless. I'm saying the cost is something I didn't notice
performance-wise.
You won't with FILE*, as it is overwhelmed by file I/O times. Same with UI
objects.
On Thursday, 17 April 2014 at 19:55:08 UTC, Walter Bright wrote:
I know that with ARC the compiler inserts the code for you.
That doesn't make it costless.
No, but Objective-C has some overhead to begin with, so it
matters less. Cocoa is a very powerful framework that will do
most of the
On Thu, 17 Apr 2014 16:47:04 -0400, Walter Bright
newshou...@digitalmars.com wrote:
On 4/17/2014 1:30 PM, Steven Schveighoffer wrote:
I'm not saying it's costless. I'm saying the cost is something I didn't
notice
performance-wise.
You won't with FILE*, as it is overwhelmed by file I/O
On Thursday, 17 April 2014 at 20:46:57 UTC, Ola Fosheim Grøstad
wrote:
But compiled Objective-C code looks horrible to begin with…
so I am not sure how well that translates to D.
Just to make it clear: ARC can make more assumptions than manual
Objective-C calls to retain/release. So ARC being
On 4/17/2014 12:36 PM, FrankLike wrote:
Size_t on x86 is uint,on x64 is ulong,it's a good thing?
I don't think is ok.
it creates many convert thing,such as length is ulong ,must cast to
int or cast to uint. It will be waste of time ,I think.
If you want fixed-length, you use
1 - 100 of 175 matches
Mail list logo
