>
>> So now the PyDict does not use calloc. and is faster than the built-in.
>> I added a few missing properties (length, opIndex)
> "public size_t size()" is the length you were looking for. Also, opIndex
> might crash if the key is not present. I don't write D2 code., but
> shouldn't opIndex re
"Walter Bright" wrote in message
news:hnc9n2$2tk...@digitalmars.com...
> Currently, it is performed as a strictly "depth-first" traversal of the
> graph defined by the import statements. As we've been discussing here,
> this works great until one has circular imports, meaning the depth-first
Jérôme M. Berger wrote:
Same here, I mean who needs two toolbars when there's enough room
to put everything in one? Plus place them far from one another so
that users never know in which one the button they want to push is
and waste time going back and forth...
HAHAHAHAAA, I should post
"Ellery Newcomer" wrote in message
news:hnc4o3$2lm...@digitalmars.com...
>
> I suppose the name isn't so important, but I really hate zip files whose
> contents aren't contained inside a single directory.
This is a bit of a "vim vs emacs" or "static vs dynamic" sort of issue.
Most of the archi
On 03/11/2010 10:15 PM, Walter Bright wrote:
Ellery Newcomer wrote:
On 03/11/2010 08:42 PM, Walter Bright wrote:
2. Trying to analyze the static constructors to see what the
dependencies actually are is fraught with unsolvable problems.
could you elucidate on this point? Is it definitely im
Hello Walter,
2. If a loop is detected, rather than issuing an error message, simply
arbitrarily pick one order and continue constructing.
How about a way to explicitly cut edges in the graph (tagging imports with
"pragma(nodep)" or "@nodep" for instance)? That has the same end effect but
fo
On 03/11/2010 08:42 PM, Walter Bright wrote:
Currently, it is performed as a strictly "depth-first" traversal of the
graph defined by the import statements. As we've been discussing here,
this works great until one has circular imports, meaning the depth-first
graph has a loop in it.
The current
Ellery Newcomer wrote:
On 03/11/2010 08:42 PM, Walter Bright wrote:
2. Trying to analyze the static constructors to see what the
dependencies actually are is fraught with unsolvable problems.
could you elucidate on this point? Is it definitely impossible to get a
hold of a complete dag, eve
On 03/11/2010 05:14 AM, Denis Koroskin wrote:
On Thu, 11 Mar 2010 02:53:33 +0300, Andrei Alexandrescu
wrote:
The kick-off meeting for Thunderbird 3:
"Thunderbird 2 is quite sluggish, has poor asynchronous execution of
tasks, poor focus control, and annoying modal dialogs on error. What
do we
On 03/11/2010 08:42 PM, Walter Bright wrote:
2. Trying to analyze the static constructors to see what the
dependencies actually are is fraught with unsolvable problems.
could you elucidate on this point? Is it definitely impossible to get a
hold of a complete dag, even if at runtime?
Walter Bright:
> 1. Attempt the depth-first traversal of the static constructors.
> 2. If a loop is detected, rather than issuing an error message, simply
> arbitrarily pick one order and continue constructing.
Some alternative possibilities:
- Issue a warning too?
- Or allow that only if the cod
Currently, it is performed as a strictly "depth-first" traversal of the
graph defined by the import statements. As we've been discussing here,
this works great until one has circular imports, meaning the depth-first
graph has a loop in it.
The current behavior on detecting a loop is to quit wi
Michel Fortin wrote:
Ah, you're right indeed. I thought it was std.stdiobase that imported
std.stdio, but its the reverse so it's a little better.
Still, std.stdiobase uses this clever external definition to avoid a
circular import:
extern(C) void std_stdio_static_this();
This hack is b
Ellery Newcomer wrote:
So I'm toying with a prototype, which is proving nice enough, but there
be a few things that I'm not quite sure which way to go with.
How about:
dmdz ...stuff... foo.zip ...morestuff...
being semantically identical to:
dmdz ...stuff... (expanded contents of foo.
Ellery Newcomer wrote:
I've hoped to rewrite std.zip forever, but found no time to do so.
Well, heck. Maybe I'll see what I can do with it. Do you want it to
conform to any interface in particular?
What I'd like to see is the creation of a library file interface, say:
std.archive
and th
Thu, 11 Mar 2010 15:37:59 -0500, Steven Schveighoffer wrote:
> On Wed, 10 Mar 2010 17:16:11 -0500, Pelle Månsson
> wrote:
>
>> On 03/10/2010 10:14 PM, Steven Schveighoffer wrote:
>>> I think this is fine as long as we don't take it to the extreme. That
>>> is, I don't want to see this happening:
On 2010-03-11 13:26:17 -0500, Walter Bright said:
Max Samukha wrote:
Michel Fortin wrote:
I'd like to point out that the trick of creating a separate module to
initialize another one is not much safer than C++ static initialization.
Take for instance std.stdio which it is initialized by
On 03/11/2010 12:29 PM, Andrei Alexandrescu wrote:
For the more specific case
dmdz [global flags] foo.zip [local flags]
it expects all the relevant content in foo.zip to be located inside
directory foo, and doesn't extract anything else unless you explicitly
tell it to.
I don't understand thi
Andrei Alexandrescu wrote:
> On 03/10/2010 09:14 PM, Chad J wrote:
>> ...
>> Indexing seems to be the general case of properties: an indexed
>> expression can be a getter/setter pair identified by both an identifier
>> (the property's name: opIndex in this case) and some runtime variables
>> (the i
On 3/11/10 22:52, Igor Lesik wrote:
I think what we can do to help is to track down exactly what the
problems are and make sure Walter knows about them. If possible we could
also try to fix them.
The problems I have are:
Undefined symbols:
__deh_beg
__deh_end
__Dmain
__minfo_beg
__minfo_end
Und
On 3/11/10 22:34, Jacob Carlborg wrote:
On 3/11/10 14:12, Justin Johansson wrote:
Jacob Carlborg Wrote:
On 3/10/10 22:59, Justin Johansson wrote:
Jacob Carlborg Wrote:
On 3/10/10 16:33, Steve Teale wrote:
The #1 show-stopper for me was lack of shared object (.so)
support under
Linux; virt
>I think what we can do to help is to track down exactly what the
>problems are and make sure Walter knows about them. If possible we could
>also try to fix them.
>The problems I have are:
>Undefined symbols:
>__deh_beg
>__deh_end
>__Dmain
>__minfo_beg
>__minfo_end
Undefined symbols is not the f
On 3/11/10 14:12, Justin Johansson wrote:
Jacob Carlborg Wrote:
On 3/10/10 22:59, Justin Johansson wrote:
Jacob Carlborg Wrote:
On 3/10/10 16:33, Steve Teale wrote:
The #1 show-stopper for me was lack of shared object (.so) support under
Linux; virtually mandated by my audience (Apache/LAM
On Wed, 10 Mar 2010 17:16:11 -0500, Pelle Månsson
wrote:
On 03/10/2010 10:14 PM, Steven Schveighoffer wrote:
I think this is fine as long as we don't take it to the extreme. That
is, I don't want to see this happening:
foo.prop1.prop2++;
is rewritten to
auto p1 = foo.prop1;
auto p2 = p1.p
Justin Johansson Wrote:
> Justin Johansson Wrote:
>
> > The most challenging problem of all in computer science (and most other
> > fields of
> > endeavour) is to "define the problem". From there, we can do about finding
> > the
> > best solution.
>
> Correction: From there, we can *go* abou
grauzone wrote:
> Andrei Alexandrescu wrote:
>> The kick-off meeting for Thunderbird 3:
>>
>> "Thunderbird 2 is quite sluggish, has poor asynchronous execution of
>> tasks, poor focus control, and annoying modal dialogs on error. What
>> do we do for version 3?"
>>
>> ...
>
> The main reason why I
>
> >>> I also had done a fair amount of work, and foundered on the inability to
> >>> dynamically load anything without it being a big deal.
> >>>
> >>> Like you say, it has been brought up many many times. Everyone says yes,
> >>> this is a real show-stopper, then the thread dies down and so
On 03/11/2010 12:11 PM, Ellery Newcomer wrote:
So I'm toying with a prototype, which is proving nice enough, but there
be a few things that I'm not quite sure which way to go with.
I was eagerly waiting for you to get back regarding this project. Thank you!
Currently I have the general patter
Max Samukha wrote:
Michel Fortin wrote:
I'd like to point out that the trick of creating a separate module to
initialize another one is not much safer than C++ static initialization.
Take for instance std.stdio which it is initialized by std.stdiobase's
static constructor. If your module i
So I'm toying with a prototype, which is proving nice enough, but there
be a few things that I'm not quite sure which way to go with.
Currently I have the general pattern
dmdz [global flags] foo1.zip [foo1 local flags] foo2.zip [foo2 local
flags] ...
although when given multiple zips it just
Walter Bright wrote:
The fact is, people *do* have major problems with concurrent
programming. Sharing of mutable state is a large generator of these
problems, and I don't think we can wish it away or blame the programmer.
I didn't advocate sharing of mutable state.
Michel Fortin wrote:
I'd like to point out that the trick of creating a separate module to
initialize another one is not much safer than C++ static initialization.
Take for instance std.stdio which it is initialized by std.stdiobase's
static constructor. If your module import std.stdio and
Justin Johansson Wrote:
> The most challenging problem of all in computer science (and most other
> fields of
> endeavour) is to "define the problem". From there, we can do about finding
> the
> best solution.
Correction: From there, we can *go* about finding the best solution.
(Also hope my
On 2010-03-11 05:22:38 -0500, Eldar Insafutdinov
said:
Walter Bright Wrote:
Eldar Insafutdinov wrote:
The issue is that we need it in a performance critical part of QtD.
The library mixes in static constructors to initialise user-defined
classes. This means that we can't use it when user co
Michal Minich Wrote:
> what mostly functional programmers think about it:
>
> What are the properties of "Functional Programming Languages"?
> http://lambda-the-ultimate.org/node/2539
>
> What are the real benefits of FP?
> http://lambda-the-ultimate.org/node/1578
>
> from the discussion it see
what mostly functional programmers think about it:
What are the properties of "Functional Programming Languages"?
http://lambda-the-ultimate.org/node/2539
What are the real benefits of FP?
http://lambda-the-ultimate.org/node/1578
from the discussion it seems there may be no straight answer.
it
Jacob Carlborg Wrote:
> On 3/10/10 22:59, Justin Johansson wrote:
> > Jacob Carlborg Wrote:
> >
> >> On 3/10/10 16:33, Steve Teale wrote:
>
> The #1 show-stopper for me was lack of shared object (.so) support under
> Linux; virtually mandated by my audience (Apache/LAMP). (A workar
Hi,
the reason for using calloc in PyDict was because GC slows down
allocation way too much.
Maybe it is/was a bug in the GC. I used manual memory management
to cut this problem and I got a huge speed improvement.
On Thu, 11 Mar 2010 01:33:32 +, Michael Rynn wrote:
> Looked at the Associa
On 03/10/2010 09:14 PM, Chad J wrote:
Andrei Alexandrescu wrote:
Well operator overloading handles indexing differently, and arguably
better than in your proposal. Ideally we'd define operators on
properties in a manner similar to the way indexing works in the new
operator overloading scheme. I'
On 3/11/10 11:22, Eldar Insafutdinov wrote:
Walter Bright Wrote:
Eldar Insafutdinov wrote:
The issue is that we need it in a performance critical part of QtD.
The library mixes in static constructors to initialise user-defined
classes. This means that we can't use it when user code is in cycli
On 3/10/10 23:50, Walter Bright wrote:
Jacob Carlborg wrote:
How dangerous would it be with a compiler option that allowed the
above and the programmer have to make sure that they don't depend on
each other?
The idea is to eliminate implementation-defined behavior as much as
practical. I don't
On Wed, 10 Mar 2010 17:16:11 -0500, Pelle Månsson
wrote:
On 03/10/2010 10:14 PM, Steven Schveighoffer wrote:
I think this is fine as long as we don't take it to the extreme. That
is, I don't want to see this happening:
foo.prop1.prop2++;
is rewritten to
auto p1 = foo.prop1;
auto p2 = p1.p
On Thu, 11 Mar 2010 02:53:33 +0300, Andrei Alexandrescu
wrote:
The kick-off meeting for Thunderbird 3:
"Thunderbird 2 is quite sluggish, has poor asynchronous execution of
tasks, poor focus control, and annoying modal dialogs on error. What do
we do for version 3?"
"Let's build on all
On 3/10/10 22:59, Justin Johansson wrote:
Jacob Carlborg Wrote:
On 3/10/10 16:33, Steve Teale wrote:
The #1 show-stopper for me was lack of shared object (.so) support under
Linux; virtually mandated by my audience (Apache/LAMP). (A workaround
like FastCGI is simply not appealing to customer
Walter Bright Wrote:
> Eldar Insafutdinov wrote:
> > The issue is that we need it in a performance critical part of QtD.
> > The library mixes in static constructors to initialise user-defined
> > classes. This means that we can't use it when user code is in cyclic
> > dependency. static construct
45 matches
Mail list logo
