Thank you, but I figured out a way to significantly reduce the number of AAs
that were in use in my program and that seems to have helped it and sped it up a
bit.
The next problem that I just ran into really doesn't make sense and I'm hoping
that you can help me. I'm getting segfaults in the f
On 5/11/11 11:14 PM, dsimcha wrote:
I'm thinking about ways to remove the global lock from the garbage
collector for most small allocations. I'm basically thinking of making
the free lists thread local. Every scheme I can come up with that
doesn't require a radical overhaul of the current impleme
On 2011-05-11 21:33, Jonathan M Davis wrote:
> On 2011-05-11 21:14, dsimcha wrote:
> > I'm thinking about ways to remove the global lock from the garbage
> > collector for most small allocations. I'm basically thinking of making
> > the free lists thread local. Every scheme I can come up with tha
Am 12.05.2011 06:47, schrieb Daniel Gibson:
> Am 12.05.2011 06:33, schrieb Jonathan M Davis:
>> On 2011-05-11 21:14, dsimcha wrote:
>>> I'm thinking about ways to remove the global lock from the garbage
>>> collector for most small allocations. I'm basically thinking of making
>>> the free lists t
On 5/11/2011 9:14 PM, dsimcha wrote:
I'm thinking about ways to remove the global lock from the garbage collector for
most small allocations. I'm basically thinking of making the free lists thread
local. Every scheme I can come up with that doesn't require a radical overhaul
of the current implem
Am 12.05.2011 06:33, schrieb Jonathan M Davis:
> On 2011-05-11 21:14, dsimcha wrote:
>> I'm thinking about ways to remove the global lock from the garbage
>> collector for most small allocations. I'm basically thinking of making
>> the free lists thread local. Every scheme I can come up with that
On 2011-05-11 21:14, dsimcha wrote:
> I'm thinking about ways to remove the global lock from the garbage
> collector for most small allocations. I'm basically thinking of making
> the free lists thread local. Every scheme I can come up with that
> doesn't require a radical overhaul of the current
I'm thinking about ways to remove the global lock from the garbage
collector for most small allocations. I'm basically thinking of making
the free lists thread local. Every scheme I can come up with that
doesn't require a radical overhaul of the current implementation
requires every thread ha
On 5/11/11 5:09 PM, Piotr Szturmaj wrote:
%u wrote:
On 05/10/2011 07:06 PM, Piotr Szturmaj wrote:
I forgot to ask. Any comments or suggestions?
This is **beast**.
Just one thing: Would it work correctly if I was using fibers in my
own code?
I don't know. If fibers may call other fibers the
On 5/11/11 5:09 PM, Sean Kelly wrote:
On May 11, 2011, at 11:38 AM, Jacob Carlborg wrote:
On 2011-05-10 16:41, Andrei Alexandrescu wrote:
On 5/10/11 3:22 AM, Jacob Carlborg wrote:
Are you referring to core.runtime.Runtime.args? That is not completely
reliable because:
* You can start a new p
BTW, I've updated RandAA for 64-bits if you want to try it out. The
updates were rather trivial and I meant to do them a long time ago.
On 5/11/2011 1:49 PM, Jonathan Crapuchettes wrote:
Wow! When is the next release planned? Is it worth my trying the beta?
dsimcha wrote:
== Quote from Jonat
On 2011-05-11 17:48, Walter Bright wrote:
> On 5/11/2011 5:16 PM, Jonathan M Davis wrote:
> > Out of curiosity, do you have any idea what kind of impact it has on
> > compilation performance to import unused modules?
>
> That of course is highly dependent on the contents of those modules, and
> wh
On 5/11/2011 5:16 PM, Jonathan M Davis wrote:
Out of curiosity, do you have any idea what kind of impact it has on
compilation performance to import unused modules?
That of course is highly dependent on the contents of those modules, and what
they correspondingly import.
On 2011-05-11 16:32, Walter Bright wrote:
> On 5/11/2011 3:52 PM, Timon Gehr wrote:
> > I'd like to hear some of Walter's arguments on the matter.
>
> Because such an error would be highly annoying when:
>
> 1. you're using version/debug/staticif conditional compilation
>
> 2. you're commenting
On 5/11/2011 3:52 PM, Timon Gehr wrote:
I'd like to hear some of Walter's arguments on the matter.
Because such an error would be highly annoying when:
1. you're using version/debug/staticif conditional compilation
2. you're commenting out code when trying different things or searching for a
On May 12, 11 06:06, Piotr Szturmaj wrote:
I have seen this many times in the library, example from std.traits:
template ReturnType(/+@@@BUG4217@@@+/func...)
if (/+@@@BUG4333@@@+/staticLength!(func) == 1)
And I realized that as a good idea, because bug 4333 is not closed yet.
I don't thi
On 2011-05-11 03:59, Don wrote:
> Jens Mueller wrote:
> > Jonathan M Davis wrote:
> >> On 2011-05-10 18:06, Jose Armando Garcia wrote:
> >>> Thanks. I should have read
> >>> http://www.digitalmars.com/d/2.0/template.html more carefully.
> >>>
> >>> "Multiple instantiations of a TemplateDeclaration
> Timon Gehr:
>
> > I do not think this should be a compiler feature. It sounds like a task more
> > suitable for a source code analyzer.
>
> The compiler already has the information.
The compiler has the symbol tables. Everything beyond that is additional
computation. (arguably not too complex)
A
KennyTM~ wrote:
On May 11, 11 08:06, Piotr Szturmaj wrote:
I forgot to ask. Any comments or suggestions?
The argument match assertion is too strict. The following does not compile:
---
void main() {
auto a = generator( (out int result, double e) {
yield!result(1);
}, 4);
writeln(a
%u wrote:
On 05/10/2011 07:06 PM, Piotr Szturmaj wrote:
I forgot to ask. Any comments or suggestions?
This is **beast**.
Just one thing: Would it work correctly if I was using fibers in my
own code?
I don't know. If fibers may call other fibers then it should work.
Andrei Alexandrescu wrote:
On 05/10/2011 07:06 PM, Piotr Szturmaj wrote:
I forgot to ask. Any comments or suggestions?
This is solid work, and very interesting. I wonder how we can integrate
it best with Phobos (e.g. put in its own module vs. integrating into
std.range).
This code is very sh
On May 11, 2011, at 11:38 AM, Jacob Carlborg wrote:
> On 2011-05-10 16:41, Andrei Alexandrescu wrote:
>> On 5/10/11 3:22 AM, Jacob Carlborg wrote:
>>> Are you referring to core.runtime.Runtime.args? That is not completely
>>> reliable because:
>>>
>>> * You can start a new process, with exec, and
Timon Gehr:
> I do not think this should be a compiler feature. It sounds like a task more
> suitable for a source code analyzer.
The compiler already has the information.
> Apart from that, if you need that functionality, you can easily write a small
> script that comments out all imports in t
Your points have been covered by others, but in general they are a little
confusing. You're making statements about things that just aren't true or
shouldn't be true for D. I'm going to request you try and elaborate what you
mean. And recap some information.
Matthew Ong Wrote:
...
> I also dow
> Walter:
>
> > > May I also ask, does the compiler and linker highlight the unused
> > > import to the user so that they can be removed from source code.
> >
> > This was discussed and we decided it was not a good idea for various
> > reasons.
>
> Maybe we'll discuss about that again, because giv
Walter:
> > May I also ask, does the compiler and linker highlight the unused
> > import to the user so that they can be removed from source code.
>
> This was discussed and we decided it was not a good idea for various reasons.
Maybe we'll discuss about that again, because giving a help to remo
Matthew Ong:
> 4) Is there also a Code formatting tool like:
>gofmt Gofmt formats Go programs. // That save me a lot to time.
>The Netbeans and eclipse has this build in feature.
I think no one has written this little tool for Phobos. On the other hand, so
far D community seems to value
== Quote from Jonathan Crapuchettes (jcrapuchet...@gmail.com)'s article
> Wow! When is the next release planned? Is it worth my trying the beta?
You probably shouldn't try the betas. DMD betas are very short (usually on the
order of a week or less) and are designed so that library writers and oth
On May 11, 11 08:06, Piotr Szturmaj wrote:
I forgot to ask. Any comments or suggestions?
The argument match assertion is too strict. The following does not compile:
---
void main() {
auto a = generator( (out int result, double e) {
yield!result(1);
}, 4);
writel
On 11.05.2011 20:07, Andrei Alexandrescu wrote:
> The macro name itself is polluting the global namespace.
OK, this I understand. But I cannot have something like:
{
static int i = 0;
}
{
static int i = 1;
}
This produces linker warning:
io.o:(.tdata.+0x0): multiple def
On Wed, 2011-05-11 at 11:27 -0700, Walter Bright wrote:
> On 5/11/2011 7:48 AM, Matthew Ong wrote:
> > Btw, any benchmark done officially comparing google go/java/D?
>
> We don't do official benchmarks because of the bad feeling and accusations of
> of
> manipulation they inevitably engender.
I
On 2011-05-10 16:41, Andrei Alexandrescu wrote:
On 5/10/11 3:22 AM, Jacob Carlborg wrote:
Are you referring to core.runtime.Runtime.args? That is not completely
reliable because:
* You can start a new process, with exec, and then pass in whatever you
want as the first argument to the process.
On 5/11/2011 7:48 AM, Matthew Ong wrote:
Btw, any benchmark done officially comparing google go/java/D?
We don't do official benchmarks because of the bad feeling and accusations of of
manipulation they inevitably engender.
On 5/11/2011 6:41 AM, Matthew Ong wrote:
5) import std.stdio; // The imports seems to be more complex to use
than java's import. There should be a tool to help resolved this and
also makes the order of importing of not important like in java.
Not sure what you mean by more complex than Java. Th
On 05/10/2011 07:06 PM, Piotr Szturmaj wrote:
> I forgot to ask. Any comments or suggestions?
This is **beast**.
Just one thing: Would it work correctly if I was using fibers in my
own code?
On 05/11/2011 12:07 PM, Alexander wrote:
On 11.05.2011 02:52, Andrei Alexandrescu wrote:
Note that the macro version has other, arguably larger, drawbacks - e.g. it
can't be used as an expression, evaluates the limit multiple times. pollutes
the global namespace etc.
BTW, I don't get it
I'll reply to points not addressed by others.
On Wed, 11 May 2011 16:41:25 +0300, Matthew Ong wrote:
1) D is a feature rich and seems to generate a really small file size
foot print for both *.dll and *.exe (Nice!!) compare to Google Go.
Funny, many people (myself included) think the executa
Wow! When is the next release planned? Is it worth my trying the beta?
dsimcha wrote:
== Quote from Jonathan Crapuchettes (jcrapuchet...@gmail.com)'s article
1. I will give you implementation a try.
2. I have been compiling with 64-bit as I expect most of the programs I write
require more than
On 11.05.2011 02:52, Andrei Alexandrescu wrote:
> Note that the macro version has other, arguably larger, drawbacks - e.g. it
> can't be used as an expression, evaluates the limit multiple times. pollutes
> the global namespace etc.
BTW, I don't get it - why *scoped* variable is going to *glo
On 2011-05-11 09:26, Mafi wrote:
> Am 11.05.2011 18:17, schrieb Jonathan M Davis:
> > On 2011-05-11 07:22, Mafi wrote:
> >> The module system has been given much attention so that the import order
> >> doesn't matter and you cannot use an ambigous symbol without error.
> >> Because there's no VM, y
Am 11.05.2011 16:48, schrieb Matthew Ong:
Hi Mafi,
Thanks very much for the prompt reply. Thanks for the various links.
BTW, are you an employee within digitalmars?
class C {}
interface I { void print(); }
abstract class D: C,I {}
void main() {}
I need class D to be solid class doing bot
Am 11.05.2011 18:17, schrieb Jonathan M Davis:
On 2011-05-11 07:22, Mafi wrote:
The module system has been given much attention so that the import order
doesn't matter and you cannot use an ambigous symbol without error.
Because there's no VM, you have to import everything you want to use.
If yo
On 11/05/2011 03:17, Brad Roberts wrote:
Sorry you feel that subscribing is too high a bar.
I like having threaded messages actually be threaded so I know what's
going on - which is why I like using a newsgroup, even for the mailing
lists. What it does mean though is that I have to have my em
== Quote from Jonathan Crapuchettes (jcrapuchet...@gmail.com)'s article
> 1. I will give you implementation a try.
> 2. I have been compiling with 64-bit as I expect most of the programs I write
> require more than 4GB of memory.
> Thanks!
Unfortunately RandAA doesn't work on 64-bit yet, though th
On 2011-05-11 07:22, Mafi wrote:
> The module system has been given much attention so that the import order
> doesn't matter and you cannot use an ambigous symbol without error.
> Because there's no VM, you have to import everything you want to use.
> If you know C++, think of it like #include and
1. I will give you implementation a try.
2. I have been compiling with 64-bit as I expect most of the programs I write
require more than 4GB of memory.
Thanks!
dsimcha wrote:
On 5/10/2011 9:54 PM, Jonathan Crapuchettes wrote:
Hey all,
I have been working with a lot of associative arrays of
On 05/10/2011 07:06 PM, Piotr Szturmaj wrote:
I forgot to ask. Any comments or suggestions?
This is solid work, and very interesting. I wonder how we can integrate
it best with Phobos (e.g. put in its own module vs. integrating into
std.range).
I suggest you write an article about this arti
Hi,
http://shootout.alioth.debian.org/
Did anyone do any one of the posted benchmarking on D Programming
here or planning to do something like this over at that site?
On 05/11/2011 09:15 AM, Andrei Alexandrescu wrote:
On 05/11/2011 08:46 AM, dsimcha wrote:
On 5/9/2011 2:52 AM, Andrei Alexandrescu wrote:
As I mentioned I'd already decided I'll take a stab at implementing a
logging module inspired in design from glog. I was tired of the endless
discussions on
Hi Mafi,
Thanks very much for the prompt reply. Thanks for the various links.
BTW, are you an employee within digitalmars?
>class C {}
>interface I { void print(); }
>abstract class D: C,I {}
>void main() {}
I need class D to be solid class doing both inherits from C but
allow me to provide co
Am 11.05.2011 15:41, schrieb Matthew Ong:
Hi All,
Hi
Recently I have been looking into another alternative programming
language to Java 1.6 and C++:
I narrowed downed to 2: Google Go and D Programming.
Preference has been given to D compare to Go for a few reasons like
more keywords than java
On 05/11/2011 08:46 AM, dsimcha wrote:
On 5/9/2011 2:52 AM, Andrei Alexandrescu wrote:
As I mentioned I'd already decided I'll take a stab at implementing a
logging module inspired in design from glog. I was tired of the endless
discussions on what a logging API should look like. This ironically
Am 11.05.2011 09:31, schrieb Jacob Carlborg:
On 2011-05-11 04:12, Jonathan M Davis wrote:
On 2011-05-10 19:01, Vladimir Panteleev wrote:
On Wed, 11 May 2011 04:39:44 +0300, Brad Roberts
wrote:
I run a _mail_ gateway, not a news gateway. So, no, posting via nntp
isn't going to work. As to why
On 5/9/2011 2:52 AM, Andrei Alexandrescu wrote:
As I mentioned I'd already decided I'll take a stab at implementing a
logging module inspired in design from glog. I was tired of the endless
discussions on what a logging API should look like. This ironically is
leading now to an embarrassment of r
Hi All,
Recently I have been looking into another alternative programming
language to Java 1.6 and C++:
I narrowed downed to 2: Google Go and D Programming.
Preference has been given to D compare to Go for a few reasons like
more keywords than java(superset) and supports build in
I also download
On 5/10/2011 9:54 PM, Jonathan Crapuchettes wrote:
Hey all,
I have been working with a lot of associative arrays of late and been
running into some problems with the built-in implementation. It appears
that very heavy use in an application can cause the garbage collector to
have issues. Most of
Just use a static variable inside a function parameterized by __FILE__
and __LINE__. Indeed the drawback is that two every() calls in one line
will share that static. I consider it a small matter. If it becomes a
bear we may as well add __COLUMN__ or something similar.
__COLUMN__ would be a
Jens Mueller wrote:
Jonathan M Davis wrote:
On 2011-05-10 18:06, Jose Armando Garcia wrote:
Thanks. I should have read
http://www.digitalmars.com/d/2.0/template.html more carefully.
"Multiple instantiations of a TemplateDeclaration with the same
TemplateArgumentList, before implicit conversion
Jonathan M Davis wrote:
> On 2011-05-10 18:06, Jose Armando Garcia wrote:
> > Thanks. I should have read
> > http://www.digitalmars.com/d/2.0/template.html more carefully.
> >
> > "Multiple instantiations of a TemplateDeclaration with the same
> > TemplateArgumentList, before implicit conversions,
On May 11, 11 15:14, Jonathan M Davis wrote:
On 2011-05-10 23:26, KennyTM~ wrote:
On May 11, 11 09:39, Brad Roberts wrote:
I run a_mail_ gateway, not a news gateway. So, no, posting via nntp
isn't going to work. As to why I require registration, it's spam
prevention. I'm not willing to open
On 2011-05-11 04:12, Jonathan M Davis wrote:
On 2011-05-10 19:01, Vladimir Panteleev wrote:
On Wed, 11 May 2011 04:39:44 +0300, Brad Roberts
wrote:
I run a _mail_ gateway, not a news gateway. So, no, posting via nntp
isn't going to work. As to why I require registration, it's spam
preventi
Andrei Alexandrescu wrote:
> On 5/9/11 3:12 PM, Jens Mueller wrote:
> >I think every() behaves strangely. Because the counter is per function.
> >But it should be per logging statement. std.log differs here from glog
> >and this seems incorrect to me. everyMs() has a similar problem.
>
> Actually,
On 2011-05-10 23:26, KennyTM~ wrote:
> On May 11, 11 09:39, Brad Roberts wrote:
> > I run a_mail_ gateway, not a news gateway. So, no, posting via nntp
> > isn't going to work. As to why I require registration, it's spam
> > prevention. I'm not willing to open up posts to non-registered users a
63 matches
Mail list logo
