On 3/8/2013 11:29 PM, Nick Sabalausky wrote:
So if they *can* be so simple, why should everyone have
to continue to stay stuck with a crappy one?
That's a good question. It's surprising how excessively complicated most designs
are.
On Sat, 9 Mar 2013 02:08:07 -0500
Nick Sabalausky wrote:
> On Sat, 09 Mar 2013 01:48:55 +0100
> "DypthroposTheImposter" wrote:
>
> > See the static_if paper here:
> >
> > http://isocpp.org/forums
> >
> > Under the post "constraints and static if" there is a link to a
> > document abou
On Thu, 07 Mar 2013 19:41:10 -0800
Walter Bright wrote:
>
> I don't want to discourage people from trying to come up with a
> replacement linker for win32 written in D. I think that is a great
> project. But while a linker is a conceptually simple program, the
> awful file formats involved make i
On Thursday, 7 March 2013 at 01:25:02 UTC, Walter Bright wrote:
Some months ago, I did make the source to optlink available on
github:
https://github.com/DigitalMars/optlink
Rainer Schuetze has improved it where it can be built with
modern tools (the older tools would not run on Win7). I know
D3 would imply language changes of D1->D2 scale, adding new
paradigm at the very least. Otherwise,
1) it will ne a surprise
2) given amount of breaking changes/fixes, we will be in D42
pretty soon
I don't think D3 can be even considered for that, it is all about
making D2 mature, after all.
On Saturday, 9 March 2013 at 05:05:42 UTC, Jesse Phillips wrote:
When a bug in the language design or compiler/libraries is
fixed; the changes needed to upgrade aren't nearly as draining
because it is the way forward. It is where the language should
be going. But hitting a regression, waiting f
I am in "changes are good" camp, too. The very reason that made
me start this thread is that many good proposals in DIP's where
rejected because they break the code while it breaks in practice
anyway. It is simply not possible to have one product that suits
perfectly two conflicting needs.
On Sat, 09 Mar 2013 01:48:55 +0100
"DypthroposTheImposter" wrote:
> See the static_if paper here:
>
> http://isocpp.org/forums
>
> Under the post "constraints and static if" there is a link to a
> document about
> static_if
>
> https://docs.google.com/viewer?a=v&pid=forums&srcid=MDIyMD
On Saturday, 9 March 2013 at 05:11:40 UTC, Jesse Phillips wrote:
On Saturday, 9 March 2013 at 04:55:06 UTC, deadalnix wrote:
This isn't the type of change you can release without any
damage mitigation plan.
Don't leave us hanging. What is your damage mitigation plan?
My desire is made elsewhe
On Saturday, 9 March 2013 at 02:08:15 UTC, Steven Schveighoffer
wrote:
On Fri, 08 Mar 2013 20:16:07 -0500, H. S. Teoh
wrote:
Is there a way for DDoc to generate documentation for
inherited class
members in the documentation for a class?
class A {
int x;
}
On Friday, 8 March 2013 at 20:33:20 UTC, Marco Leise wrote:
I don't know much about the development process, but as you
said some bugs may be features or vice versa. Sometimes real
bugs are fixed and peoples' code breaks. But keeping the bug
around isn't an option.
The next code breakage comes fr
On Saturday, 9 March 2013 at 06:07:12 UTC, Jesse Phillips wrote:
On Saturday, 9 March 2013 at 05:15:12 UTC, deadalnix wrote:
I feel like a parot having to repeat the same shit again and
again and again. So I wont, I expanded myself on such topic so
many time already.
See how PHP handled the t
On Saturday, 9 March 2013 at 05:15:12 UTC, deadalnix wrote:
I feel like a parot having to repeat the same shit again and
again and again. So I wont, I expanded myself on such topic so
many time already.
See how PHP handled the transition from 4 to 5 for a good
example of how it can be done.
On Thursday, 7 March 2013 at 15:53:09 UTC, Denis Shelomovskij
wrote:
Didn't get. You don't have to use D with druntime. Just don't
link it and everything will be OK - you will just get "better
C" (i.e. with D structs and other good stuff).
Walter wrote all about it:
http://www.drdobbs.com/arc
On Saturday, 9 March 2013 at 05:11:40 UTC, Jesse Phillips wrote:
On Saturday, 9 March 2013 at 04:55:06 UTC, deadalnix wrote:
This isn't the type of change you can release without any
damage mitigation plan.
Don't leave us hanging. What is your damage mitigation plan?
I feel like a parot hav
On Saturday, 9 March 2013 at 03:38:13 UTC, Rikki Cattermole wrote:
How ever this will bring back e.g. the old python 2.x vs 3.x
divide which would be a shame. But at the same time it'll mean
we can do some big stuff that would just not be acceptable in
breaking old projects.
We don't need to
On Saturday, 9 March 2013 at 04:55:06 UTC, deadalnix wrote:
This isn't the type of change you can release without any
damage mitigation plan.
Don't leave us hanging. What is your damage mitigation plan?
My desire is made elsewhere, but I don't think there is anything
to do, code will break, i
On Friday, 8 March 2013 at 20:07:50 UTC, Dicebot wrote:
Now that http://wiki.dlang.org/Release_Process is slowly
adopted I want to rise this discussion again.
Two somewhat contradictory aims meet here, both frequently
raised in IRC and newsgroup:
1) Breaking user code with release is incredi
On Saturday, March 09, 2013 04:26:38 Damian wrote:
> Scheduled for depreciation December 2012? as this been overlooked
> or is it not depreciated anymore?
>
> core.thread
> static void sleep(long period);
Drat. I keep forgetting to look in druntime when moving stuff through the
deprecation proce
On Friday, 8 March 2013 at 17:40:58 UTC, Andrej Mitrovic wrote:
Honestly D has huge potential for tools like
compilers/linkers/etc.
They're the types of programs where you practically know all
your
requirements at compile-time, so e.g. generics come into play
really
nicely.
That is the theo
On Friday, 8 March 2013 at 20:33:20 UTC, Marco Leise wrote:
I don't know much about the development process, but as you
said some bugs may be features or vice versa. Sometimes real
bugs are fixed and peoples' code breaks. But keeping the bug
around isn't an option.
The problem isn't really brea
On Saturday, March 09, 2013 04:38:08 Rikki Cattermole wrote:
> Personally I think we need to consider D3 as breaking. We can
> leave out any major changes till then or at least that would be
> nice. That way we can use D2 for LTS once we begin on D3.
> How ever this will bring back e.g. the old pyt
On Saturday, 9 March 2013 at 00:48:59 UTC, DypthroposTheImposter
wrote:
See the static_if paper here:
http://isocpp.org/forums
Under the post "constraints and static if" there is a link to a
document about
static_if
https://docs.google.com/viewer?a=v&pid=forums&srcid=MDIyMDc3NjUwMTczOTM
On Fri, Mar 08, 2013 at 07:50:26PM -0800, Walter Bright wrote:
> On 3/8/2013 5:19 PM, Brad Anderson wrote:
> >On Saturday, 9 March 2013 at 00:48:59 UTC, DypthroposTheImposter wrote:
> >> Are they full of it? Has it caused the problems they mention
> >>in
> >>D?
> >
> >Well, the two guys with a
On 3/9/13, Damian wrote:
> Scheduled for depreciation December 2012? as this been overlooked
> or is it not depreciated anymore?
>
> core.thread
> static void sleep(long period);
>
It's being removed soon:
https://github.com/D-Programming-Language/phobos/pull/1176
One thing to remember is that streams need to be runtime
swappable. For instance, I should be able to replace stdout
with a stream of my choice.
That does make my solution a little tougher to implement. Hmmm...
It looks like a monolithic type is the easiest solution, but it
definitely shou
On 3/8/2013 5:19 PM, Brad Anderson wrote:
On Saturday, 9 March 2013 at 00:48:59 UTC, DypthroposTheImposter wrote:
Are they full of it? Has it caused the problems they mention
in
D?
Well, the two guys with an alternative proposal (concepts-lite) seem to hate
static if (along with a third
On Friday, 8 March 2013 at 21:07:23 UTC, Jakob Ovrum wrote:
On Friday, 8 March 2013 at 20:07:50 UTC, Dicebot wrote:
Opinions/proposals?
I completely agree that the needs of users who want stability
over everything are not being met. There's no way to choose to
get just the updates that don't
On Sat, Mar 09, 2013 at 04:26:38AM +0100, Damian wrote:
> Scheduled for depreciation December 2012? as this been overlooked or
> is it not depreciated anymore?
>
> core.thread
> static void sleep(long period);
Probably nobody has updated the code yet, but it *is* still deprecated,
and will be rem
Scheduled for depreciation December 2012? as this been overlooked
or is it not depreciated anymore?
core.thread
static void sleep(long period);
"bearophile" wrote in message
news:hohjkspdzavtiqxqi...@forum.dlang.org...
>
> string[4] colors = ["red",
> "blue"
> "green",
> "yellow"];
> void main() {}
>
I hate this, a lot.
> I have a bit of statistical proof that code like this i
On Fri, Mar 08, 2013 at 09:30:30PM -0500, Jonathan M Davis wrote:
> On Saturday, March 09, 2013 01:59:33 Stewart Gordon wrote:
> > On 07/03/2013 12:07, Steven Schveighoffer wrote:
> >
> >
> > > I don't really understand the need to make ranges into streams.
> >
> >
> >
> > Ask Walter - from wh
On Saturday, March 09, 2013 01:59:33 Stewart Gordon wrote:
> On 07/03/2013 12:07, Steven Schveighoffer wrote:
>
>
> > I don't really understand the need to make ranges into streams.
>
>
>
> Ask Walter - from what I recall it was his idea to have range-based file
> I/O to replace std.stream.
>
On Fri, 08 Mar 2013 20:59:33 -0500, Stewart Gordon
wrote:
On 07/03/2013 12:07, Steven Schveighoffer wrote:
I don't really understand the need to make ranges into streams.
Ask Walter - from what I recall it was his idea to have range-based file
I/O to replace std.stream.
I hope to con
On Fri, 08 Mar 2013 20:16:07 -0500, H. S. Teoh
wrote:
Is there a way for DDoc to generate documentation for inherited class
members in the documentation for a class?
class A {
int x;
}
/// Derived class
class B : A {
/// Another
On Saturday, 9 March 2013 at 00:48:59 UTC, DypthroposTheImposter
wrote:
See the static_if paper here:
http://isocpp.org/forums
Under the post "constraints and static if" there is a link to a
document about
static_if
https://docs.google.com/viewer?a=v&pid=forums&srcid=MDIyMDc3NjUwMTczOTM
See the static_if paper here:
http://isocpp.org/forums
Under the post "constraints and static if" there is a link to a
document about
static_if
https://docs.google.com/viewer?a=v&pid=forums&srcid=MDIyMDc3NjUwMTczOTM0Mjk3NjABMDI2MzM3MjkxNDM4NDQ5MzE4NDcBLWVsS1Y4dFhtdDhKATUBaXNvY3BwLm9yZwF2
On Saturday, 9 March 2013 at 01:18:29 UTC, H. S. Teoh wrote:
Is there a way for DDoc to generate documentation for inherited
class
members in the documentation for a class?
class A {
int x;
}
/// Derived class
class B : A {
/// Ano
On 07/03/2013 12:07, Steven Schveighoffer wrote:
I don't really understand the need to make ranges into streams.
Ask Walter - from what I recall it was his idea to have range-based file
I/O to replace std.stream.
Thikning about it now, a range-based interface might be good for reading
fil
On 3/9/13, H. S. Teoh wrote:
> Is there a way for DDoc to generate documentation for inherited class
> members in the documentation for a class?
Possible dupe post of mine but I don't see it listed:
There's an enhancement opened about it[1] and I began
implementing it a few weeks ago, but I have
Is there a way for DDoc to generate documentation for inherited class
members in the documentation for a class?
class A {
int x;
}
/// Derived class
class B : A {
/// Another value
int y;
// ?? how to
On Friday, 8 March 2013 at 13:02:06 UTC, Jakob Ovrum wrote:
On Friday, 8 March 2013 at 05:29:14 UTC, Rikki Cattermole wrote:
I've actually modified dmd's frontend to support using the VS
tool chain for linking 32 bit executables. But I didn't
understand the backend to seperate the 32bit binary
On Friday, March 08, 2013 21:15:42 Michael wrote:
> And std.utf is broken on Win 64?
I don't know how stable dmd is for Win64 or how well it really works, but it's
brand new, so bugs are likely. Certainly, if something works on Win32 but not
Win64, then it's a bug. Please report any bugs you fin
On 7 March 2013 07:55, Iain Buclaw wrote:
>
> On Mar 7, 2013 12:56 AM, "Joshua Niehus" wrote:
> >
> > On Wednesday, 6 March 2013 at 20:58:35 UTC, Andrei Alexandrescu wrote:
> >>
> >> Hi everyone,
> >>
> >>
> >> Time to design the DConf 2013 T-shirts! Please reply to this with any
> ideas you may
Marco Leise:
I don't know much about the development process, but as you
said some bugs may be features or vice versa. Sometimes real
bugs are fixed and peoples' code breaks. But keeping the bug
around isn't an option.
Fixing issues like this is right, despite they will cause some
breakage in
On Friday, 8 March 2013 at 20:07:50 UTC, Dicebot wrote:
Opinions/proposals?
I completely agree that the needs of users who want stability
over everything are not being met. There's no way to choose to
get just the updates that don't break code (such as non-breaking
bug fixes), and I think yo
P.S. Short discussion in IRC have shown that intent of the post
is not clear enough: I am not here to rant about stability or how
bad breaking changes are. Only thing I do want is to define some
means to differentiate needs of those who want changes to improve
language and those that require ab
I don't know much about the development process, but as you
said some bugs may be features or vice versa. Sometimes real
bugs are fixed and peoples' code breaks. But keeping the bug
around isn't an option.
The next code breakage comes from making array slices
consistently rvalues (the slice structu
And std.utf is broken on Win 64?
Dmd 2.062, Win 8 x64
Example from
http://forum.dlang.org/thread/pnuxfheeaqwyfjdqw...@forum.dlang.org
crashes here
dfiles = dirEntries(compiler.srcDestination, "*.d",
SpanMode.depth);
files = dfiles.array;
And "absolutePath" also is broken (as it is use a getcwd as
default param)
As I as
Now that http://wiki.dlang.org/Release_Process is slowly adopted
I want to rise this discussion again.
Two somewhat contradictory aims meet here, both frequently raised
in IRC and newsgroup:
1) Breaking user code with release is incredibly painful and
brings lot of dissatisfaction.
2) Langua
On Friday, March 08, 2013 18:29:39 John Colvin wrote:
> I tried compiling phobos with -inline and ran in to this compiler
> error:
>
> std/file.d(2620): Error: function std.file.dirEntries compiler
> error, parameter 'pattern', bugzilla 2962?
> Assertion failed: (0), function toObjFile, file glue.
So, there is problem in toUTF8 in std.utf "toUTF8(in wchar[] s)".
string cwd()// copied from phobos
{
writeln("start");
import core.sys.windows.windows;
writeln("buff");
wchar[] ret = new wchar[10240];
writeln("call");
auto n = GetCurrentDirectoryW(to!DWORD(ret.length), re
On 03/08/2013 01:17 AM, Walter Bright wrote:
On 1/2/2012 11:20 AM, Martin Nowak wrote:
- Libraries might not be unloaded as long as GC collected class
instances
still exist because
finalization fails otherwise.
D doesn't guarantee that finalizers will run on GC allocated objects.
Therefo
On 03/08/2013 04:22 AM, Walter Bright wrote:
These are problems with *any* dynamic dll code. The answer is to tell
the user "don't do that". The user should NEVER continue to use objects
created by that dll or delegates/functionpointers/datapointers that
refer to it.
The gc problem, however, is
On 3/8/13, Walter Bright wrote:
> On 3/7/2013 8:16 PM, Brad Roberts wrote:
>> Personally, even though I don't use win32, I believe that moving it over
>> to use the VS toolchain and runtime is the
>> right path forward.
>
> I like being able to provide a completely free D toolchain for win32.
s/f
I tried compiling phobos with -inline and ran in to this compiler
error:
std/file.d(2620): Error: function std.file.dirEntries compiler
error, parameter 'pattern', bugzilla 2962?
Assertion failed: (0), function toObjFile, file glue.c, line 815.
Is this known about or is it something new? The
On Friday, 8 March 2013 at 13:25:42 UTC, Michael wrote:
Code works good on Win 32, but at start on Win 64 I got:
Exception code: 0xc005
Fault offset: 0x000132c5
If "auto currDir = getcwd();" commented, error is not appear.
getcwd broken on win 8 x64?
On Thursday, 7 March 2013 at 04:21:01 UTC, deadalnix wrote:
On Monday, 4 March 2013 at 14:21:11 UTC, deadalnix wrote:
On Monday, 4 March 2013 at 10:55:58 UTC, Don wrote:
On Sunday, 3 March 2013 at 16:48:32 UTC, deadalnix wrote:
...
Obviously, the program segfault soon after that.
It sounds li
On Thu, 07 Mar 2013 20:52:49 -0500, BLM768 wrote:
Ultimately, I think that the differences between our designs boil down
to having a more monolithic stream interface with an internal stream
source or having a lighter-weight but more ad-hoc stream interface with
an external and more expose
Code works good on Win 32, but at start on Win 64 I got:
Exception code: 0xc005
Fault offset: 0x000132c5
void main(string[] args)
{
auto workDir = "build_tmp";
auto currDir = getcwd();
string[] src;
string[] obj;
string cfg = "build.json";
Compiler compiler;
On Friday, 8 March 2013 at 05:29:14 UTC, Rikki Cattermole wrote:
I've actually modified dmd's frontend to support using the VS
tool chain for linking 32 bit executables. But I didn't
understand the backend to seperate the 32bit binary generation
vs 64bit. I believe it shouldn't be too much. But
On 2013-03-08 10:34, Jonathan M Davis wrote:
That's basically what static constructors and destructors do, and it'll be a
problem if they aren't run when the library is loaded and unloaded.
Right, forgot about those.
--
/Jacob Carlborg
On Thursday, 7 March 2013 at 18:31:35 UTC, Jacob Carlborg wrote:
On 2013-03-07 15:55, Kagamin wrote:
I heard, llvm was written for C and x86. C++, exceptions and
ARM pushed
it beyond its limits and created a lot of kludge and redesigns.
Apple is betting everything on Clang/LLVM and they real
> This only works if you explicitly provide the module to DMD. If you
> only pass the -I import switch to find the module it will not compile.
>
> I wouldn't call this a feature, but rather a bug. It's probably a case
> of a string compare returning true instead of actually verifying where
> the m
On 08.03.2013 08:25, Rikki Cattermole wrote:
On Friday, 8 March 2013 at 07:17:24 UTC, Walter Bright wrote:
On 3/7/2013 8:16 PM, Brad Roberts wrote:
Personally, even though I don't use win32, I believe that moving it
over to use the VS toolchain and runtime is the
right path forward.
I like
On Friday, 8 March 2013 at 03:22:46 UTC, Walter Bright wrote:
On 3/7/2013 6:18 PM, Daniel Murphy wrote:
"Walter Bright" wrote in message
news:khban1$1lm2$1...@digitalmars.com...
On 1/2/2012 11:20 AM, Martin Nowak wrote:
- Libraries might not be unloaded as long as GC collected
class
instan
On Friday, March 08, 2013 10:09:33 Jacob Carlborg wrote:
> On 2013-03-08 01:17, Walter Bright wrote:
> > D doesn't guarantee that finalizers will run on GC allocated objects.
> > Therefore, when unloading a dll:
> >
> > 1. run a gc collection
> > 2. for all objects remaining on the heap
> >
> >
On 2013-03-08 09:58, Walter Bright wrote:
Sure, but who is going to do the work?
Anyone that's interested in doing the work. But we don't have to invest
all our time doing it. Daniel Murphy seems to be working on a linker, so
apparently there is at least some interest.
BTW, we did come up
On 2013-03-08 01:17, Walter Bright wrote:
D doesn't guarantee that finalizers will run on GC allocated objects.
Therefore, when unloading a dll:
1. run a gc collection
2. for all objects remaining on the heap
if they have a finalizer and that finalizer points into the dll
code
On 3/8/2013 12:50 AM, Jacob Carlborg wrote:
If we have our own linker for every supported platform and format I pretty sure
that we can take advantage of that and come up with features not possible using
other linkers.
For example, storing .di files directly in the object file. This has also bee
08-Mar-2013 12:50, Jacob Carlborg пишет:
On 2013-03-08 04:41, Walter Bright wrote:
The other thing is, we just don't have a need for our own linker for any
platform other than win32. So what's the cost benefit moving forward? I
think it's easier to just fix optlink's bugs.
If we have our own
On 2013-03-08 04:41, Walter Bright wrote:
The other thing is, we just don't have a need for our own linker for any
platform other than win32. So what's the cost benefit moving forward? I
think it's easier to just fix optlink's bugs.
If we have our own linker for every supported platform and fo
08-Mar-2013 00:15, Andrej Mitrovic пишет:
On Thursday, 7 March 2013 at 20:01:58 UTC, Walter Bright wrote:
What we *can* do with Optlink is fix the occasional bug that crops up
in it.
I hope so. :)
On Thursday, 7 March 2013 at 20:01:58 UTC, Walter Bright wrote:
I also believe that even if Opt
On 3/7/2013 11:37 PM, Jacob Carlborg wrote:
If this restriction is needed I think it's very unfortunate. I had really hoped
to be able to have an OO interface.
Objective-C can load plugins with an OO interface an Objective-C can be used
with a GC.
Read my other posts in this thread!
75 matches
Mail list logo
