Re: Battle-plan for CTFE
On 06/30/2016 05:17 AM, Stefan Koch wrote: > Both. Actually I could not imagine fixing the memory problem without > doing IR interpretation. > I will tackle compiling more difficult code later today. > As soon as I can run my compiletime brainfuck I will open a PR. > > Until then you can see my progress at > https://github.com/UplinkCoder/dmd/tree/newCTFE > I will try to always keep the branch in a healthy state. Looks good and will definitely lead to a proper CTFE interpreter. You might want to go back and look at https://github.com/MartinNowak/dmd/blob/28ffb0ab4fa6950f60c085f33f8a2ce23df7c0cd/src/interpret.c, it could already do a few more things than your interpreter atm. [¹]: https://github.com/MartinNowak/dmd/commits/ctfe
Re: Battle-plan for CTFE
On Thursday, 30 June 2016 at 01:20:08 UTC, Stefan Koch wrote:
First small code example compiles!
int bug6498(int x) {
int n = 0;
while (n < x) {
n++;
}
return n;
}
evaluation of bug6498(100_000_00) took 226 msecs.
evaluation of bug6498(100_000_000) took 2228 msecs.
The memory allocated by the Evaluator is exactly 12 bytes.
The speedup comes from interpreting the IR or fixing the memory
leaking?
Re: one-file pure D decoders for vorbis, flac and mp3
On Wednesday, 29 June 2016 at 09:07:18 UTC, ketmar wrote: i decided to make some noise about those, as people may thinking about doing the ports themselves, and effectively double (or triple, or...) the work. so, here they are: * Vorbis decoder[1] (stb_vorbis port), PD; * FLAC decoder[2] (drflac port), PD; * MP3 decoder[3] (minimp3 port), GPL. they may or may not work for you, i don't know. [1] http://repo.or.cz/iv.d.git/blob_plain/HEAD:/stb/vorbis.d Nice, just recently use stb_vorbis.c. Any chance you'll turn this into a dub package?
Release D 2.071.1
Glad to announce D 2.071.1. http://dlang.org/download.html This point release fixes a few issues over 2.071.0, see the changelog for more details. http://dlang.org/changelog/2.071.1.html -Martin
Re: Beta D 2.071.1-b2
On 06/16/2016 08:43 PM, Jack Stouffer wrote: > On Sunday, 29 May 2016 at 21:53:23 UTC, Martin Nowak wrote: >> Second beta for the 2.071.1 release. >> >> http://dlang.org/download.html#dmd_beta >> http://dlang.org/changelog/2.071.1.html >> >> Please report any bugs at https://issues.dlang.org >> >> -Martin > > This release would fix some pretty serious bugs. What's the holdup? I couldn't find enough time to fix https://issues.dlang.org/show_bug.cgi?id=16085. Let's do the point release now anyhow and follow-up later on.
Re: Beta D 2.071.1-b2
On 06/16/2016 09:47 PM, deadalnix wrote: > 196418a8b3ec1c5f284da5009b4bb18e3f70d99f still not in after 3 month. > This is typesystem breaking. While I understand it wasn't picked for > 2.071 , I'm not sure why it wasn't for 2.071.1 . Because it didn't target stable.
Re: LDC 1.0.0 has been released!
On Monday, 6 June 2016 at 07:00:56 UTC, Kai Nacke wrote: Hi everyone, It is a great pleasure to announce that version 1.0.0 of LDC, the LLVM-based D compiler, is now available for download! Congratulations! And please update https://ldc-developers.github.io/LATEST.
Beta D 2.071.1-b2
Second beta for the 2.071.1 release. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.071.1.html Please report any bugs at https://issues.dlang.org -Martin
Re: Battle-plan for CTFE
On 05/21/2016 11:18 PM, Martin Nowak wrote: > The debugging metaphor would be comparing a program that only uses > pointer arithmetic against one that is memory safe, the former can > randomly write everywhere from anywhere, the latter could use the wrong > reference. It's also similar to comparing assembly code to C.
Re: Battle-plan for CTFE
On 05/18/2016 04:59 PM, Daniel Murphy wrote: > The bytecode generator and bytecode interpreter can be debugged (and > tested!) independently. So the total amount of code will increase but > the components themselves will be better isolated and easier to work with. It's simpler to debug an AST interpreter working with a stack of high-level values, than it is to debug a bytecode interpreter where lots of context has been converted to jumping goto code. Just to illustrate my point, here are an AST and a BC interpreter for very simplistic functional language I wrote recently. The later one still missing the actual interpretation. https://github.com/MartinNowak/CC1/commit/ed28b8966de86e7449f93ce4e4cf7aed3082180b https://github.com/MartinNowak/CC1/commit/899e67cf7038050b86eed533c9165bd2ba06e609 There is nothing simpler about a BC interpreter. Instead you have to deal with converting control flow and computing addressing. The debugging metaphor would be comparing a program that only uses pointer arithmetic against one that is memory safe, the former can randomly write everywhere from anywhere, the latter could use the wrong reference. > I don't think a possible future need for a JIT is a good reason to avoid > an bytecode interpreter. It's a very good reason, b/c once you work on JIT, there is no benefit for BC left, e.g. all the extra work for nothing. That said, I doubt we'll need a JIT anytime soon. > A large part of the work of adding a new (JIT) backend is pinning down the > semantics, > and adding a bytecode interpreter will certainly help to do that. The semantic problem is already solved, in a file called interpret.d by sth. that's an AST interpreter, that just happens to use the wrong value structures and leaks memory. Converting that to BC will be quite difficult, cleaning it up and changing it to use a better stack and deterministic memory management is rather straightforward. Last but not least, don't forget that we have the same situation since over 3 years already. It has always been similarly easy to write a better interpreter, it just never happened b/c the ambitions never matched the available resources. -Martin
Re: Battle-plan for CTFE
On 05/18/2016 07:50 PM, Stefan Koch wrote: > Indeed. > > I am currently designing an IR to feed into the CTFE Evaluator. > I am aware that this could potentially make it harder to get things > merged since DMD already has the glue-layer. As a compat layer between different interpreters or as a compat layer between all backends? Adding another translation might not be acceptable, at least for real backends. > However I do think that the benefits outweigh the drawbacks by far. > Especially when one looks at the possibility to eventually plug llvm or > the gcc-jit in. Indeed, but it heavily increases the chance that your project lands on the unfinished D project pile. > My CTFE needs are rather heavy weight. So I will go for a solution that > can support this. > I believe the pressure on CTFE performance will increase as soon as the > preformance increases. Since this will enable much more things. > I.E. running a query optimizer at compile-time. That might be true, but scripting languages are still fast enough to be used everywhere. You won't need native CTFE performance for it to be an enabling technique. -Martin
Re: D's Auto Decoding and You
On Tuesday, 17 May 2016 at 14:06:37 UTC, Jack Stouffer wrote: Related discussion https://trello.com/c/4XmFdcp6/163-rediscuss-redundant-utf-8-string-validation.
Re: Battle-plan for CTFE
On 05/17/2016 12:42 PM, Don Clugston wrote: > There's no need for grandiose plans, as if there is some > almost-insurmountable problem to be solved. THIS IS NOT DIFFICULT. With > the interface cleaned up, it is the well-studied problem of creating an > interpreter. Everyone knows how to do this, it's been done thousands of > times. The complete test suite is there for you. Someone just needs to > do it. Yes, exactly my words. > I think I took the approach of using syntax trees about as far as it can > go. It's possible, but it's really vile. Look at the code for doing > assignments. Bleagh. The only thing in its favour is that originally it > was the only implementation that was possible at all. Even the first, > minimal step towards creating a ctfe backend -- introducing a > syntax-tree-validation step -- simplified parts of the code immensely. Yes, this https://github.com/dlang/dmd/blob/7d00095301c4780b41addcfeb50f4743a9a6c5d4/src/dinterpret.d#L3418 is really ugly and complex, but you won't get rid of this inherent complexity. The e2ir code for AssingExp looks almost the same https://github.com/dlang/dmd/blob/7d00095301c4780b41addcfeb50f4743a9a6c5d4/src/e2ir.c#L2466. > You might imagine that it's easier to work with syntax trees than to > start from scratch but I'm certain that's not true. I'm pretty sure that > the simplest approach is to use the simplest possible > machine-independent bytecode that you can come up with. I had got to the > point of starting that, but I just couldn't face doing it in C++. All I'm saying is that interpreting the AST to generate bytecode is going to be as complex as interpreting the AST directly, but then you still a bytecode interpreter and later might still want a JIT. Using dedicated value types during interpretation instead of recycling the AST for that will also make the transitions clearer and get rid of some of the lifetime complexities in the current code. -Martin
Re: The D language online tour - tour.dlang.org
On 05/16/2016 07:32 PM, André wrote: > Hi, > > after another round of polishing, bug fixing, very useful user > contributions and suggestions, I'd like to present the new home of the D > language online tour: > > http://tour.dlang.org/ > > Thank you very much to the D foundation for hosting this service! How is this deployed, don't know the server? Can anyone give me details? > If you would like to report errors or have suggestions, please use GitHub: > > https://github.com/stonemaster/dlang-tour Nice, I always wanted to do such a markdown tutorial on top of my D REPL. Glad you did it first ;). Small PR https://github.com/stonemaster/dlang-tour/pull/62 -Martin
Re: Battle-plan for CTFE
On 05/16/2016 03:03 PM, Martin Nowak wrote:
> ~this()
> {
> if (impl.onHeap && --impl.heap.refCount == 0)
> heapAllocator.free(impl.heap);
> }
Of course missing the increment for copies.
this(this)
{
if (impl.onHeap)
++impl.heap.refCount;
}
Re: Battle-plan for CTFE
On 05/16/2016 01:36 PM, Andrei Alexandrescu wrote: > > A reap would be great there! std.experimental.allocator offers that and > a variety of others. -- Andrei Yes indeed, a malloc backed Region Allocator w/ a FreeList or a BitmappedBlock would be a good starting point. That might finally be a compelling enough case to start using phobos in dmd. Last time people forced me to spend several hours on reimplementing and debugging a BitArray implementation [¹]. [¹]: https://github.com/dlang/dmd/pull/5426#discussion_r52833955
Re: Battle-plan for CTFE
On Monday, 16 May 2016 at 10:01:47 UTC, Kagamin wrote: Wasn't it possible to enable GC for entire compiler? There can be hybrid approach: 1) first allocate from bump heap 2) when it reaches, say, 200MB, switch to GC. Well, I wouldn't use D's GC for that dedicated heap. Allocation of CTFE values are completely independent and call be freed once the evaluation is finished.
Re: Battle-plan for CTFE
On 05/15/2016 04:00 PM, Daniel Murphy wrote: > The problem is, if index refers to a single variable on the stack, then > it's insufficient to refer to a variable inside an aggregate on the > stack. Then you need to start building constructs for member of struct > in array of struct pointers and it gets fairly messy... It's all > solvable, I'm not sure the simplicity would survive. Taking what I said further down below there would be one union Value type (untagged b/c the compiler knows what it is). Then an Array could be implementd as HeapValueRef[], a hash table as HeapValueRef[ValueRef], a struct/class as HeapValueRef[] (with HeapValueRef being a pointer or int to a heap allocated Value and ValueRef being a pointer or int to either a stack value or a heap value). A D Pointer/Ref would just be a ValueRef in the interpreter and the aforementioned int (2B + for stack, 2B - for heap) encoding should still work for that. Depending on how much pointer arithmetic we support, Pointer must contain a ValueRef to the outermost aggregate and needs to store the type of that an additional byte offset. The type and offset could then be used to compute the actual pointee. While that sounds a bit complex, it's merely just https://en.wikipedia.org/wiki/Offsetof. > Flow control is really not where the complexity lies IMO. The weird > ways in which different types of reference types can combine leads to > either very complicated or very low level descriptions of memory. Maybe you're right, but it'll be hard to figure out w/o an actual implementation. And the AST still looks like a lot less to code and execute.
Re: Battle-plan for CTFE
On 05/15/2016 02:54 PM, Daniel Murphy wrote: > > We really should have discussed this last week! I talked about it w/ Stefan, and asked him to volunteer for an implementation, that's why we have this thread ;). In any case I'm convinced that the simple-first strategy has a much higher chance to be implemented this year, whereas the bug report [¹] for slow CTFE is already 5 years old. [¹]: https://issues.dlang.org/show_bug.cgi?id=6498
Re: Battle-plan for CTFE
On 05/15/2016 02:13 PM, Ola Fosheim Grøstad wrote:
>
> Well, you can, but it won't bring improvements to the language down the
> line.
Maybe you don't know the actual problem of the current interpreter?
I leaks memory like hell b/c it allocates new AST nodes for almost every
expression evaluation.
Even an interpreter that is as slow as ruby will fly during compile time
in comparision to the current one.
Let me illustrate the point.
---
import std.algorithm, std.array, std.random, std.range;
enum count = 2 ^^ 10;
enum sorted = {
auto gen = Random(123);
return generate!(() => uniform(byte.min, byte.max,
gen)).take(count).array.sort().release;
}();
pragma(msg, sorted.length);
---
count = 2 ** 10
nums = Enumerator.new do |yielder|
prng = Random.new(123)
loop do
yielder.yield prng.rand(-128 .. 127)
end
end.take(count).sort
print nums.length
---
N | CTFE | Ruby
| Time | Mem | Time | Mem
---|---|--|---|--
2^^10 | 0.16s | 82M | 0.11s | 9.3M
2^^11 | 0.22s | 110M | 0.12s | 9.3M
2^^12 | 0.4s | 190M | 0.12s | 9.4M
2^^13 | 0.7s | 450M | 0.12s | 9.5M
2^^14 | 1.5s | 1.4G | 0.12s | 9.7M
2^^15 | 3.7s | 4.8G | 0.13s | 10.0M
2^^16 | 5:30m | 15G | 0.13s | 10.8M
D's CTFE grows O(N^2) b/c it leaks for almost every operation.
We don't currently need a superfast interpreter, even the simplest
possible interpreter will allow so much more that we're more likely
limited by the lack of I/O before we need a faster interpreter.
Re: Battle-plan for CTFE
On 05/15/2016 02:17 PM, Daniel Murphy wrote:
>
> For simple types that's true. For more complicated reference types...
>
> Variable indexes are not enough, you also need heap memory, but slices
> and pointers (and references) can refer to values either on the heap or
> the stack, and you can have a slice of a member static array of a class
> on the stack, etc. Then there are closures...
So we do need a GC or RC for arrays, structs, classes (anything
heapish). Values for those could be allocated by a simple bump/region
allocator or a dedicated allocator that support individual freeing (via
RC or GC).
In any case struct Pointer { int index; /* 2B positive values for stack,
2B negative for heap*/ } wouldn't be much more complicated than a raw
pointer (and a bit simpler to garbage collect).
> Neither e2ir or s2ir are actually that complex. A lot of the mess there
> comes from the backend IR interface being rather difficult to work with.
Think of a simple switch statement where you even need to introduce
relocations (or keep a list of fixup addresses) b/c you don't know the
jump addresses in advance.
In a visitor you simply test the cases and execute the first case body.
Not to mention that we can reuse existing solutions from the current
interpreter (e.g. for gotos see
https://github.com/dlang/dmd/blob/0757504342e48e272372b7ac52cda5a333b2a2bc/src/dinterpret.d#L1014
and
https://github.com/dlang/dmd/blob/0757504342e48e272372b7ac52cda5a333b2a2bc/src/dinterpret.d#L1094).
Re: Battle-plan for CTFE
On 05/15/2016 02:02 PM, Stefan Koch wrote: > > Correct. A ByteCode Interpreter will add even more implementation > overhead, and the benefit is only realizable if the ByteCode is a > standard format that can be read other backends such as a jit. This indeed would be an interesting proposal, interpretable IR that is portable between the backends. But I guess we won't find such IR or at least need to lower it into RealIR for dmd/gcc/llvm. Sounds like an interesting candidate for the next GSoC.
Re: Battle-plan for CTFE
On 05/15/2016 01:55 PM, Ola Fosheim Grøstad wrote: > If you are going to have fast evaluation of loops/recursion then you > need to use a solver. And well, doing worse than O(log N) at compile > time is a very bad idea. > > Why not start with the most difficult case first? Then the simple cases > will resolve themselves for free, most likely. Why not do something that takes about a month and is much more likely to succeed? If someone has more time and needs an even faster interpreter she can write a new one, or add optimizations or JIT to the simple interpreter.
Re: Battle-plan for CTFE
On 05/15/2016 01:58 PM, Daniel Murphy wrote: > The biggest advantage of bytecode is not the interpreter speed, it's > that by lowering you can substitute VarExps etc with actual references > to memory without modifying the AST. > > By working with something lower level than the AST, you should end up > with something much less complex and with fewer special cases. Which is a bad assessment, you can stick variable indexes into VarDeclaration (we already do that) and thereby access them in O(1). Converting control flow and references into byte code is far from trivial, we're talking about another s2ir and e2ir here. -Martin
Re: Battle-plan for CTFE
On 05/09/2016 06:57 PM, Stefan Koch wrote: > I was shocked to discover that the PowExpression actually depends on > phobos! (depending on the exact codePath it may or may not compile...) > which let to me prematurely stating that it worked at ctfe > [http://forum.dlang.org/thread/ukcoibejffinknrbz...@forum.dlang.org] There is a really old bug report for that [Issue 3749 – cannot evaluate yl2x (log) and exp functions at compile time](https://issues.dlang.org/show_bug.cgi?id=3749). The lack of exp is really limiting for many nice table precomputation use-cases in scientific contexts. -Martin
Re: Battle-plan for CTFE
On 05/13/2016 06:32 PM, Stefan Koch wrote: > I would like to work on a solution that does scale. The Problem is > not making a byteCode-interpreter. That part is relatively easy. > Currently I am trying to get a detailed understanding of dmd and > it's data-structures. (mainly it's AST.) > > Generating the byte-code seems to be non-trivial. > > I wonder in how far the glue layer can be of help... Seems like I've to repeat this once more, b/c everyone including me didn't got it in the first place. We don't need a bytecode interpreter, it mostly adds overhead and a complicated second layer between walking the AST and interpreting it (think of transforming a for loop with goto into linear bytecode, almost as complicated as in the glue layer). What we basically need is a stack of values, a stack of frames (for function calls and variables in scopes), and an AST visitor that does the interpretation. It would be most helpful for the success of this to follow common CS examples like [¹], [²], or [³]. With realistic expectations we might have a working implementation in a month or so. With more requirements like bytecode, using dmd's backend, or JIT we end up with a long newsgroup discussion ;). Tricky things for a CTFE interpreter include: - enumerating VarDeclarations (they already have a ctfeAdrOnStack field) in each scope, and referring to outer variables from nested scopes At best just use a continuous stack and just set the stack pointer to the last frame pointer when leaving a scope. - getting function calls right Push arguments, on return shift top of stack under arguments and pop them (caller cleanup). If possible detect and support tail recursion. - converting AST values to and from Interpreter Values. Literals and constant VarExp from the AST need to be converted to an interpreter Value before being pushed on the stack. The result of interpretation (top of stack) needs to be converted back to an AST literal. Using separate data types (instead of creating AST values in the interpreter) will be a major performance improvement over using AST values (e.g. 16 vs. ~100 bytes). It also creates a clear boundary between Interpreter and AST values. Currently quite some complexity is thrown at cleaning interpreter generated AST values, and distinguishing interpreter owned from normal AST values (which allows some optimizations) [⁴]. We don't need a tagged union b/c the AST already contains the type information, but a tag could be helpful for debugging [⁵]. Values can be deleted when popped from stack (no ref counting needed I think). - Implementing more complex data structures (arrays, strings, hash tables, aggregates) Use Value[], Value[Value], and a dedicated String (char[]/wchar[]/dchar[]). For structs/classes field indexes are known => use fix-sized Value[]. Value.class_ needs to hold a reference to the actual class instance for vtable calls. Last time I was working on this (also on a bytecode interpreter) the entry point was fairly clear [⁶] (thanks to Don). -Martin [¹]: [The Interpreter In An Undergraduate Compilers Course ](http://arxiv.org/pdf/1412.0426.pdf) [²]: [L8: Interpreters & Visitors](http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-005-elements-of-software-construction-fall-2011/lecture-notes/MIT6_005F11_lec08.pdf) [³]: [PA 2: Interpreter](https://sites.google.com/a/bodik.org/cs164/projects/pa2) [⁴]: https://github.com/dlang/dmd/search?q=ownedByCtfe [⁵]: https://github.com/MartinNowak/dmd/blob/28ffb0ab4fa6950f60c085f33f8a2ce23df7c0cd/src/interpret.c#L73 [⁶]: https://github.com/MartinNowak/dmd/blob/28ffb0ab4fa6950f60c085f33f8a2ce23df7c0cd/src/interpret.c#L693
Re: Battle-plan for CTFE
On 05/10/2016 08:45 AM, Jacob Carlborg wrote: > > I was listening to a discussion Don and Daniel had about the current > implementation of CTFE. They talked about using a byte code interpreter. > Even implementing a really crappy byte code interpreter would be a huge > improvement. No need for a byte-code interpreter, it mostly just adds overhead and complexity over an AST interpreter. If you want to go really fast you need some sort of JIT anyhow, but a proper interpreter will be orders of mangnitude faster than the current implementation. I might refer you to http://dconf.org/2013/talks/chevalier_boisvert.pdf page 59 ff.
Beta D 2.071.1-b1
First beta for the 2.071.1 point release. A few issues remain to be fixed before the next beta. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.071.1.html Please report any bugs at https://issues.dlang.org -Martin
Re: Release D 2.071.0
On Wednesday, 6 April 2016 at 14:13:16 UTC, Vladimir Panteleev wrote: I know the all-platform .zip files are wasteful, but any practical reason for removing them? Unless the hosting cost is not negligible, breaking existing tools/scripts may not be worth it. Sorry that you missed that, it's been decided and discussed several times since half a year ago that we want to get rid of the huge useless downloads, even more so since we're releasing much more often. Any user of your tools will be thankful for a much quicker download as well. http://forum.dlang.org/post/mp2ou8$1qrf$1...@digitalmars.com http://forum.dlang.org/post/55d9df2a.8090...@dawg.eu https://github.com/D-Programming-Language/installer/commit/5a2ed94953c007b1bc374f46073a60bda53635d1
Re: Release D 2.071.0
On Thursday, 7 April 2016 at 02:21:30 UTC, Cy Schubert wrote: It builds and packages nicely. ~Cy Thanks, are you the current FreeBSD port maintainer?
Re: Release D 2.071.0
On Wednesday, 6 April 2016 at 13:19:08 UTC, Cy Schubert wrote: Is there a source URL published anywhere? http://ftp.digitalmars.com/dmd.2.071.0.zip doesn't appear to work. ~Cy We've deprecated the combined package b/c of it's sheer size and uselessness. Each platform specific package does contain the source code as well.
Re: Release D 2.071.0
On Wednesday, 6 April 2016 at 13:05:31 UTC, sigod wrote:
module test;
struct S {
package int field;
}
void main() {
S s;
s.field = 1; // Deprecation: test.S.field is not visible from
module test
}
https://github.com/D-Programming-Language/dmd/pull/5642
Would've been great to fix this during the beta ;).
Re: Release D 2.071.0
On Wednesday, 6 April 2016 at 07:56:03 UTC, Jacob Carlborg wrote: If I understand correctly the "this.outer" issue was resolved by slightly modifying the language. If that's correct, does it deserves an entry in the changelog besides the fixed issue? It's just fixing the existing typing. Before you would get the nested functions context pointer typed as outer class, now you correctly get the outer class through the function context.
Release D 2.071.0
Glad to announce D 2.071.0. http://dlang.org/download.html This release fixes many long-standing issues with imports and the module system. See the changelog for more details. http://dlang.org/changelog/2.071.0.html -Martin
Re: Graylog integration for std.experimental.logger
On Friday, 1 April 2016 at 11:14:19 UTC, 9il wrote: Graylog Extended Log Format (GELF) D implementation was released. Great, thanks a lot.
Beta D 2.071.0-b2
Second beta for the 2.071.0 release. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.071.0.html Please report any bugs at https://issues.dlang.org -Martin
Re: Blog article on new import changes
On 03/29/2016 05:25 PM, Steven Schveighoffer wrote: > I wrote a blog post (actually my first ever) on this, let me know what > you think (and please, any clarifications/errors, let me know): > > http://www.schveiguy.com/blog/2016/03/import-changes-in-d-2-071/ Thanks
Re: Beta D 2.071.0-b1
On 03/28/2016 10:54 PM, deadalnix wrote: >> This doesn't look like a bugfix or anything urgent, so it seems like >> it can wait for 2.072. > > This is type system breaking, if that is not important or a bugfix, I'm > not sure what is. The PR didn't address the stable branch, but also missed the merging of master, and thus isn't beta tested. It fixes an issues that is already 16 month old. We're releasing every 2 month. Please take care of landing fixes in time on the right branch (stable), just wait for the next release, or use the nightly. -Martin
Re: Beta D 2.071.0-b1
On 03/27/2016 09:46 PM, deadalnix wrote: > The one I intended to talk about: > https://github.com/D-Programming-Language/phobos/pull/4099 This doesn't look like a bugfix or anything urgent, so it seems like it can wait for 2.072.
Re: Beta D 2.071.0-b1
On Friday, 25 March 2016 at 09:18:31 UTC, ag0aep6g wrote: On 25.03.2016 10:06, Martin Nowak wrote: But it's not in the changelog. Well, the commit message doesn't say that the issue was fixed, hence it's not in the bugfix list, also see the dlang-bot comment https://github.com/D-Programming-Language/dmd/pull/5470#issuecomment-186661863. I'd suggest you manually add a small compiler changes entry here https://github.com/D-Programming-Language/dmd/blob/stable/changelog.dd, make sure to use the stable branch. $(LI Foreach loops..., also see $(Bugzilla 12345).) No need for a more detailed section.
Re: Beta D 2.071.0-b1
On 03/24/2016 06:06 PM, John Colvin wrote: > > As usual, `brew update && brew reinstall dmd --devel` :) Or `curl -fsS https://dlang.org/install.sh | bash -s dmd-beta`.
Re: Beta D 2.071.0-b1
On Thursday, 24 March 2016 at 17:20:58 UTC, Joakim wrote: Looking forward to getting rid of the remaining top-level non-selective imports in phobos. Let's not rush this before the deprecation of the import changes is over (2 or 3 releases from now), people might still use the old behavior w/ -transition=import.
Re: Beta D 2.071.0-b1
On Thursday, 24 March 2016 at 14:36:57 UTC, Guillaume Chatelet wrote: Shouldn't this be part of the release ? https://issues.dlang.org/show_bug.cgi?id=15581 It's in the beta, see the list of branches/tags https://github.com/D-Programming-Language/dmd/commit/3002a9683619957ce0d3f1379f99970f1664d087.
Re: Beta D 2.071.0-b1
On 03/24/2016 03:00 AM, deadalnix wrote: > No bug report for it, but a PR: > https://github.com/deadalnix/pixel-saver/pull/53 That seems unrelated. Bugfixes should simply go into stable for them to be released.
Re: Beta D 2.071.0-b1
On 03/24/2016 06:49 AM, ag0aep6g wrote: > > The changelog page has the wrong version number is the heading and in > the download link. Thanks, fixed.
Beta D 2.071.0-b1
First beta for the 2.071.0 release. This release comes with many import and lookup related changes and fixes. You might see a lot of deprecation warnings b/c of these changes. We've added the -transition=import switch and -transition=checkimports [¹] switches to ease updating existing code. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.071.0.html Please report any bugs at https://issues.dlang.org -Martin [¹]: -transition=checkimports currently has a bug that creates false positive warnings about the $ symbols, this will be fixed in the next beta (Bugzilla 15825)
Release D 2.070.2
Glad to announce D 2.070.2. http://dlang.org/download.html This unplanned point release fixes just a single issue over 2.070.2, see the changelog for more details. http://dlang.org/changelog/2.070.2.html -Martin
Re: nanomsg for Deimos collection
On 02/27/2016 04:48 PM, Ilya Yaroshenko wrote: > Hi all, > > D interface to nanomsg library http://nanomsg.org/ was released. This > bindings follows Deimos style. 90% of tests was ported to D. > > github: https://github.com/9il/nanomsg > dub: http://code.dlang.org/packages/nanomsg > > BTW, what should I do to include it to Deimos collection? > https://github.com/D-Programming-Deimos Send a mail to Walter and ask him to create a repo. You could also transfer your existing repo. This would leave you w/ full commit access, reducing friction when fixing sth. or tagging a new release.
Release D 2.070.1
Glad to announce D 2.070.1. http://dlang.org/download.html This point release fixes a few issues over 2.070.1, see the changelog for more details. http://dlang.org/changelog/2.070.1.html -Martin
Re: Beta D 2.070.1-b1
On Thursday, 25 February 2016 at 08:52:14 UTC, nkgu wrote: That's nothing but the DL link in http://dlang.org/changelog/2.070.1.html is broken. Thanks, fixed.
Beta D 2.070.1-b1
First beta for the 2.070.1 point release. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.070.1.html Please report any bugs at https://issues.dlang.org -Martin
Re: Release D 2.070.0
On 01/27/2016 11:16 PM, Yazan D wrote: > Thanks for all the work. > > Looks like the changelog is missing some stuff. For example: https:// > issues.dlang.org/show_bug.cgi?id=15434 and https://issues.dlang.org/ > show_bug.cgi?id=15433. The commit messages are parsed by quite a few tools to find bug fixes. In order to automatically close bugzilla tickets, get a link from dlang-bot, and appear on the changelog you should mention `fix Issues 15433` in the relevant commit. The regex goes like this: ((close|fix|address)e?(s|d)? )?(ticket|bug|tracker item|issue)s?:? *([\d
Re: Release D 2.070.0
On 01/27/2016 10:37 PM, jmh530 wrote: > > I don't see a mention of the native exception handling on 64-bit linux > in the changelog. Yes, sorry for that nobody wrote the changelog entry. We now have changelog.dd files in each repo, and PRs should only be merged w/ the corresponding changelog entry. Unfortunately this isn't always followed.
Re: Vision for the first semester of 2016
On Tuesday, 26 January 2016 at 12:38:09 UTC, Andrei Alexandrescu wrote: including things that some people argue shouldn't be part of a standard library: archives and compression, cryptography, databases, character encodings (including json and xml!), html templating, image processing, suffix arrays (sic), logging, networking, regexp, testing, tokenization. See my answer below, most of these are standard solutions that you need on a daily basis (except for the suffix array). I do agree with Dub's importance. What's unclear to me is what are reasonable criteria for including some given functionality within the stdlib vs. an external one. A good criteria is whether some area has an established and hard to debate solution, then it can go into the standard library. But if there are many different ways around the same topic you should leave the decision to the users. So for example there are 3 established ways to parse something, dom, stax and event based parsers. So you can add those parsers as sth. like std.xml or std.json. There are about 500 different configuration file formats, so anything that isn't as established as xml or json should be left for libraries. Likewise there are plenty of different GUI toolkits (taking imperative or declarative approaches). Leave it to people to pick one that suites their need. You could discuss endlessly about the syntax of html templating, but how such a library should work is clear. This is at the edge of standardizable, b/c by putting it into std, you're making a decision for all language users. It's albeit possible, just like declaring a particular code style as standard. Anything that is highly innovative or experimental should never go into standard libraries.
Release D 2.070.0
Glad to announce D 2.070.0 http://dlang.org/download.html This release comes with the new std.experimental.ndslice, heavily expanded Windows bindings, and native exception handling on 64-bit linux. See the changelog for more details. http://dlang.org/changelog/2.070.0.html -Martin
Re: Vision for the first semester of 2016
On Monday, 25 January 2016 at 16:26:36 UTC, Russel Winder wrote: PyPI has is an highly opinionated metric that helps you decide what is good and what is dross. Could you help us on designing one for code.dlang.org as well?
Re: Beta D 2.070.0-b2
On Tuesday, 19 January 2016 at 13:07:50 UTC, Nordlöw wrote: I'm still missing entries for - https://github.com/D-Programming-Language/phobos/pulls?utf8=%E2%9C%93=is%3Apr+is%3Aclosed++author%3Anordlow - https://github.com/D-Programming-Language/phobos/pull/3288 Well, please write them (targeting stable). Changelog entries should nowadays be part of pull requests. https://github.com/D-Programming-Language/phobos/blob/ca3b4c839770a02f2414b20aa11c38f79419871b/changelog.dd#L9
Re: Airfares to Berlin for DConf 2016
On 01/20/2016 10:04 AM, Walter Bright wrote: > I saw on the news this evening that air fares for the next 3 weeks will > be at a 3 year low. It's a good time to book the flights to Berlin! Though subway tickets were increased in 2015 and reached an all-time high of 2,70€ ;). It's great to have the conference in Berlin, looking forward to see all of you.
Re: Beta D 2.070.0-b2
On Monday, 18 January 2016 at 00:33:11 UTC, Andrei Amatuni wrote: Changelog doesn't include ndslice. Wasn't it merged for the 2.070 release? Fixed, I simply forgot to update the changelog from phobos. https://github.com/D-Programming-Language/dlang.org/commit/128de6cce74b6fe8f98c35d2e3b44c44517152c8 http://dlang.org/changelog/2.070.0.html
Re: Beta D 2.070.0-b2
On Monday, 18 January 2016 at 10:58:46 UTC, Rory McGuire wrote: The TypeTuple disappearance issue is still there. Should at least be marked deprecated first. Right? It didn't disappear, std.typetuple is still there and deprecated. What I found during testing was an incorrect `import std.range : TypeTuple` that no longer works. It's unfortunate that the import system doesn't prevent such mistakes.
Re: Beta D 2.070.0-b2
On Monday, 18 January 2016 at 15:08:51 UTC, Rory McGuire wrote: What I meant was it used to be available by importing std.typecons and now it isn't. There is a library on code.dlang.org that uses it, painlessjson I think it was. That's what I meant above, thought it was std.range. TypeTuple was never part of std.typecons. The fact that it could be imported from there is a bug in our import system https://issues.dlang.org/show_bug.cgi?id=314.
Re: Beta D 2.070.0-b2
Second and last beta for the 2.070.0 release. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.070.0.html Please report any bugs at https://issues.dlang.org -Martin
Re: Beta D 2.070.0-b1
On 01/14/2016 11:13 AM, Nordlöw wrote:
> I'm missing changelog entry for
>
> - new algorithm `std.algorithm.comparison.either`
> - update for return type of `findSplit*` enabling bool-conversion in for
> instance
>
> if (const hit = haystack.findSplit(needle))
> {
> // use hit
> }
There is a changelog for each project, those entries should be part of PRs.
https://github.com/D-Programming-Language/phobos/blob/7f24ccfeb503445dc56fee0c3e7ee41268ef80a5/changelog.dd
Beta D 2.070.0-b2
Second and last beta for the 2.070.0 release. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.070.0.html Please report any bugs at https://issues.dlang.org -Martin
Re: Beta D 2.070.0-b1
On Monday, 11 January 2016 at 16:24:56 UTC, ponce wrote: it builds with flags -release -inline -O -w BUT NOT -unittest Makes sense https://github.com/D-Programming-Language/dub/issues/747. The compiler does check assertions in unittest blocks even in release builds, right? It's really trivial to add so you might have a try yourself https://github.com/D-Programming-Language/dub/blob/3ab683b023bd58dd101e110cf2f6199911eb7477/source/dub/package_.d#L307. In the meantime it's possible to define a custom build type http://code.dlang.org/package-format?lang=json#build-types.
Re: Beta D 2.070.0-b1
On Monday, 11 January 2016 at 07:56:18 UTC, Jacob Carlborg wrote: On 2016-01-11 00:58, Martin Nowak wrote: Please test the beta. The introduction of "message" in Throwable is a breaking change [1], but I guess it's not worth reporting an issue for. Oh it's well worth to mention any update issues, in particular if we're breaking code to introduce problematic designs. https://github.com/D-Programming-Language/druntime/pull/1445#issuecomment-170530377
Re: Beta D 2.070.0-b1
On 01/11/2016 08:37 AM, Jacob Carlborg wrote: > On 2016-01-11 00:58, Martin Nowak wrote: > >> [¹]: https://github.com/MartinNowak/project_tester > > Can one request for adding projects to this? > If the project is well maintained and relevant, just make a PR. https://github.com/MartinNowak/project_tester/blob/dd2afea122048dbcb90d0d9b637d31134a6a82ce/projects.xml#L94
Re: Testing Nightly Build Service
On Tuesday, 5 January 2016 at 18:34:57 UTC, Johan Engelen wrote: Hi Martin, Any news on this? (and it'd be great if LDC could be added too! ;-) cheers, Johan Yes, test phase successful, waiting for time to do the rest. http://forum.dlang.org/post/56806778.2040...@dawg.eu I'm not in charge of any ldc building, but can offer to collaborate on integrating any ldc nightly build service.
Re: Better docs for D (WIP)
On Wednesday, 6 January 2016 at 15:41:29 UTC, Adam D. Ruppe wrote: I know projects get bugs open when they are used, but ddox is a one-person project and that one person doesn't seem terribly active in it. I'm another user of ddox and fix things when they annoy me. I don't have many problems with it though. It you'd joined we'd already be 3. https://github.com/rejectedsoftware/ddox/graphs/contributors The main reasons why work has stalled is that the future of dpl-docs is unclear. Instead of fixing the remaining issues w/ ddox people have spend a huge amount of time to improve ddoc output, so b/c of this weird course Söhnke stopped working on dpl-docs for now. The other reason is that the existing tool already does most things you want from a documentation system. The styling sucked so I wrote scod, but most of the remaining issues are minor problems that will eventually be addressed. And even if you don't agree w/ some aspect of it, working on a common documentation engine/library makes more sense than having everyone write it's own, in particular if you're arguing about limited time.
Re: Hash Tables in D
On 01/04/2016 09:06 AM, Bastiaan Veelo wrote: > > This would be a bug (segfault on my machine): > >> foreach (key; aa.byKey) >> aa.remove(key); > > Note that, in this example, there is no need to remove every element > separately, you can also just do Sorry my mistake, I never use aa.keys (instead of aa.byKey) b/c it allocates. So it's still sort of a bug to recommend people allocating an array ;).
Re: Beta D 2.070.0-b1
On 01/04/2016 04:29 PM, Joakim Brännström wrote: > Regression? > Found when compiling dub-package scriptlike (struct Path). Thanks for reporting. It's not acceptable to break code like that without a proper deprecation cycle. https://issues.dlang.org/show_bug.cgi?id=15515
Re: Beta D 2.070.0-b1
On 01/03/2016 09:20 PM, tsbockman wrote: > > Any hope for this? > > https://github.com/D-Programming-Language/dmd/pull/3407#issuecomment-136974686 > > It's been bugging a lot of people lately. Well, this still needs a lot of work that nobody was did. Walter spend almost the whole release cycle on EH, I spend a huge amount of time on nightlies/install scripts and was away half of the cycle. So while I still think 313&314 should be one of our main priorities, it seems I couldn't convince anyone.
Beta D 2.070.0-b1
First beta for the 2.070.0 release. Still a few things missing from the changelog, there is a new package std.experimental.ndslice, and native (DWARF based) exception handling on linux. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.070.0.html Please report any bugs at https://issues.dlang.org -Martin
Re: Hash Tables in D
On 01/01/2016 04:27 PM, Minas Mina wrote: > On Friday, 1 January 2016 at 13:59:35 UTC, Walter Bright wrote: >> http://minas-mina.com/2016/01/01/associative-arrays/ >> >> https://www.reddit.com/r/programming/comments/3z03ji/hash_tables_in_the_d_programming_language/ >> > > Thanks for sharing this. I am the author. :) There is a bug. You should never do this b/c of iterator/range invalidation. foreach (key; aa.keys) aa.remove(key);
Re: Testing Nightly Build Service
On Sunday, 13 December 2015 at 10:22:56 UTC, Suliman wrote: https://builds.dawg.eu/dmd-nightly/ Why not https://builds.dlang.org ? Because we're testing the service, once it's reliable, we'll move this to a dlang subdomain or integrate it with downloads.dlang.org.
Testing Nightly Build Service
As you might already know from the last sprint review (http://forum.dlang.org/post/56592679.3010604@dawg.), we've setup a server to build nightlies. The service is still in a test phase but seems to work steadily. You can try it using the install script curl -fsSL https://builds.dawg.eu/install.sh | bash -s dmd-nightly or by simply downloading the latest archive for your platform. https://builds.dawg.eu/dmd-nightly/
Release D 2.069.2
Glad to announce D 2.069.2. http://dlang.org/download.html This point release fixes a few issues over 2.069.1, see the changelog for more details. http://dlang.org/changelog/2.069.2.html -Martin
Re: Beta D 2.069.2-b2
On Monday, 30 November 2015 at 11:22:08 UTC, John Colvin wrote: Safe to ignore for non-windows, yes? Yes
Beta D 2.069.2-b2
Second beta for the 2.069.2 point release. New fixes: Bugzilla 15281: std\experimental\allocator\package.d not included in build script http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.069.2.html Please report any bugs at https://issues.dlang.org -Martin
Beta D 2.069.2-b1
First beta for the 2.069.2 point release. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.069.2.html Please report any bugs at https://issues.dlang.org -Martin
Re: Beta D 2.069.2-b1
On Saturday, 28 November 2015 at 21:37:35 UTC IMO, this should not be released until https://issues.dlang.org/show_bug.cgi?id=15281 is fixed. It's a very obvious and embarrassing bug. Yes, but someone has to do it. It's really trivial to extend the Windows makefiles accordingly, but I never use Windows myself, so someone else (a Windows stakeholder) should simply fix this.
Re: The D Language Foundation has $5000 to its name
On Monday, 23 November 2015 at 12:35:35 UTC, Dicebot wrote: Whoa, this must be pretty new. Though subkey used seems to be almost 1 year old now. sub rsa4096/12BB1939 2015-02-27 Why should I renew the subkey w/o cause? Then everybody would need to redownload my public keys. In any case I'd be in favor if more people sign my key, though we could do that next time we meet in person ;).
Re: https everywhere!
On Tuesday, 24 November 2015 at 08:48:58 UTC, Vladimir Panteleev wrote: Sorry, I'm not going to pay for my own SSL certificate :) You'll either have to share, or wait until Let's Encrypt goes live and I get around to setting it up. You could either get a free startssl certificate https://gist.github.com/mgedmin/7124635 or we try to reverse proxy through dlang.org/forum or so.
Re: https everywhere!
On Monday, 23 November 2015 at 20:55:32 UTC, Walter Bright wrote: I'm pleased to announce that Jan Knepper has gotten us some proper certificates now, and dlang.org and digitalmars.com are now fully https! Glad to hear that as it's a requirement to host installer scipts and our gpg keyring with some trust. https://github.com/D-Programming-Language/installer/pull/162 Guess we'll quickly fix the few non-shema relative urls.
Re: Release D 2.069.1
On Saturday, 21 November 2015 at 08:57:45 UTC, Thomas Mader wrote: [1] http://www.jrsoftware.org/isinfo.php Thanks this looks indeed like a good choice.
Re: Release D 2.069.1
On Wednesday, 11 November 2015 at 12:18:55 UTC, Rikki Cattermole wrote: This has already been talked about on D.learn. It's a very bad look especially since this is a major addition for this release. Hence why I have even mentioned this to Andrei. Bad bad bad bad situation for us. Did anyone bother to fix this? The next point release is due soon.
Release D 2.069.1
This is an unplanned point release whose sole purpose is to fix a severe Windows installer bug. http://dlang.org/download.html http://downloads.dlang.org/releases/2.x/2.069.1/ http://dlang.org/changelog/2.069.1.html -Martin
Re: 2.069.0 Installation problem with .exe for Windows
On 11/11/2015 11:22 AM, wobbles wrote: > I also tried on Windows 8.1 64-bit. To test, I installed it over DMD > 2.067 and 2.068, both were successful. Now released, http://forum.dlang.org/post/n1vatr$1106$1...@digitalmars.com.
Re: Release D 2.069.1
On 11/11/2015 01:18 PM, Rikki Cattermole wrote: > > This has already been talked about on D.learn. It's a very bad look > especially since this is a major addition for this release. > Hence why I have even mentioned this to Andrei. Well, test the beta. Both, the installer bug and the lack of allocator in win*.mak could have easily been found. > Bad bad bad bad situation for us. It's not the end of the world, but a good chance too think about how we could use nightlies or weeklies to bridge this gap. >From my side it's very simple to build tarballs, and when combined with an nice install script [¹] should work. It's more difficult to do the packaging because that relies on sensible version tags. [¹]: http://forum.dlang.org/post/n1v541$r99$1...@digitalmars.com
Re: 2.069.0 Installation problem with .exe for Windows
On Tuesday, 10 November 2015 at 14:17:28 UTC, Mike James wrote: The x64 sub-directory does not exist on my system. We found the bug and I build a new installer with the fix. https://dlang.dawg.eu/downloads/dmd.2.069.0~fix15824/ As soon as someone confirms the fix, we'll make a new point release.
Re: 2.069.0 Installation problem with .exe for Windows
On 11/09/2015 09:46 AM, Mike James wrote: > > Hi Martin, > > I've tried the new install with Windows Vista and Windows 7 and the > problem is the same as before. > > Regards, > -=mike=- Can you try again, I updated the installer and tried to revert the other part of the change (though I don't see why that would fix the problem). More details would help a lot at this point, e.g. what windows are open (also look whether the uninstaller hides any window) and what files are left in the install dir (C:\D by default) while the installation hangs. And let's please continue this in Bugzilla. https://issues.dlang.org/show_bug.cgi?id=15284
Re: Release D 2.069.0
On 11/09/2015 07:08 PM, Dicebot wrote: > More common practice is to declare such dependencies as optional though. I made a ticket https://issues.dlang.org/show_bug.cgi?id=15308. Simply changing https://github.com/D-Programming-Language/installer/blob/41fb25ce5e5ff2c14728f490ee4579ac49bb989a/linux/dmd_rpm.sh#L266 doesn't work b/c the rpmtool from debian used to build the rpm packages doesn't support Recommends.
Re: 2.069.0 Installation problem with .exe for Windows
On 11/04/2015 10:05 AM, Mike James wrote: > Copied here for extra visibility... > > Hi. > > There seems to be an install problem with the .exe version for > Windows. The installer removes the old DMD then doesn't install > the 2.069.0 version. In the task manager it's still running at > 50% CPU time. It fails on Windows Vista and Windows 7. Could some try and verify that this installer fixes the issue. I wasn't able to reproduce the issue myself. https://dlang.dawg.eu/downloads/dmd.2.069.0~fix15824/
Re: 2.069.0 Installation problem with .exe for Windows
On Wednesday, 4 November 2015 at 09:05:07 UTC, Mike James wrote: Regards, -- Could anyone help us to reproduce the issue?https://issues.dlang.org/show_bug.cgi?id=15284
Re: Release D 2.069.0
On Wednesday, 4 November 2015 at 17:52:23 UTC, Dmitry Olshansky wrote: If host machine is x64 bit windows try setting large address aware bit on the executable (there are tools to do that IRC), would allow it to eat up to ~4 gigs. We're already doing that since quite a while. https://github.com/D-Programming-Language/dmd/commit/172b55d22bd4a144d889c3fa8d9279d8e0a0ce1c
Re: Release D 2.069.0
On 11/04/2015 10:01 AM, deadalnix wrote: > > Bonus question: how soon can we expect travis to pick up the new version ? I updated http://ftp.digitalmars.com/LATEST now and added that step to http://wiki.dlang.org/DMD_Release_Building.
Re: Release D 2.069.0
On 11/04/2015 10:01 AM, Suliman wrote: >> Regards, >> -- > > Same problem. It's likely related to this fix which now let's the installer wait on the uninstaller to finish. https://github.com/D-Programming-Language/installer/commit/526f35495cdc615b26b65d73fa7b4aa0477b1d12 Did anything go wrong with the uninstall?
Release D 2.069.0
Glad to announce D 2.069.0. http://dlang.org/download.html http://downloads.dlang.org/releases/2.x/2.069.0/ This is the first release with a self-hosted dmd compiler and comes with even more rangified phobos functions, std.experimental.allocator, and many other improvements. See the changelog for more details. http://dlang.org/changelog/2.069.0.html -Martin
Re: D 2.068.2 test runner for Android ARM, please test and report results from your Android device
On 11/01/2015 10:50 AM, Joakim wrote: > http://forum.dlang.org/thread/bafrkjfwmoyriyhmq...@forum.dlang.org Nice works for me as well (Galaxy S3 on cm-12.1 (5.1.1)). Would be nice to run this as automated test on an Android Emulator.
Re: Release Candidate D 2.069.0-rc2
On 10/31/2015 01:00 PM, BBasile wrote: > > Despite of what I had say previously I've encountered another "inliner" > bug today that looks like a regression. I don't know what's the 2.069 > ETA but I'm not sure to be able to file a bugzilla entry quickly. Please just file ticket with whatever you have (e.g. project x fails with ...). We can reduce the code ourself or might already recognize the issue. Regarding the ETA, we're already overdue by 2 weeks. -Martin
