Re: SQLite-D alpha is here

On Saturday, 27 February 2016 at 17:03:17 UTC, Adam D. Ruppe wrote: On Saturday, 27 February 2016 at 16:54:49 UTC, Suliman wrote: Why? etc.c is for the C interface. This is not the C interface. Besides, the original code will surely be ahead of features and compatibility for a long time

Re: SQLite-D alpha is here

On Saturday, 27 February 2016 at 16:08:21 UTC, Stefan Koch wrote: Hello, I am happy to announce the official alpha version of sqlite-d! sqlite-d is a reader for the SQLite File Format 3. In the future I will implement a SQL-like API on top of it. Top-notch performance is one of the explicit

Re: SQLite-D alpha is here

I made a huge performance improvement sqlite-d is now 6-8 times faster then on the day were it wad able to read the first payloads. 2. I am heavily working on write-support. 3.Sqlite-d will then implement the allocator interface! (although I am flexible on that should it turn out to be a bad

Re: Berlin D Meetup March 2016

On Tuesday, 15 March 2016 at 14:30:20 UTC, Ben Palmer wrote: Hi All, The March Berlin D Meetup will be happening at 19:30 on Friday the 18th at Berlin Co-Op (http://co-up.de/) on the fifth floor. This time Martin Nowak will be doing a talk titled "Object (Relational) Mapper". The abstract

Re: SQLite-D alpha is here

On Sunday, 28 February 2016 at 12:14:14 UTC, Stefan Koch wrote: Update I just found another case that cannot be handled properly. It just happens with insanely huge databases. That bug is fixed now!

LZ4 decompression at CTFE

Hello, originally I want to wait with this announcement until DConf. But since I working on another toy. I can release this info early. So as per title. you can decompress .lz4 flies created by the standard lz4hc commnadline tool at compile time. No github link yet as there is a little bit

Re: LZ4 decompression at CTFE

On Tuesday, 26 April 2016 at 22:07:47 UTC, MrSmith wrote: I would like to use this instead of c++ static lib. Thanks! (I hope it works at runtime too). Sure it does, but keep in mind the c++ version is heavily optimized. I would have to make a special runtime version to archive comparable

Re: LZ4 decompression at CTFE

On Tuesday, 26 April 2016 at 22:07:47 UTC, MrSmith wrote: I would like to use this instead of c++ static lib. Thanks! (I hope it works at runtime too). Oh and If you could please send me a sample of a file you are trying to uncompress. That would be most helpful.

Re: LZ4 decompression at CTFE

On Thursday, 28 April 2016 at 06:03:46 UTC, Marco Leise wrote: There exist some comparisons for the C++ implementations (zlib's DEFLATE being a variation of lz77): http://catchchallenger.first-world.info//wiki/Quick_Benchmark:_Gzip_vs_Bzip2_vs_LZMA_vs_XZ_vs_LZ4_vs_LZO

Re: Proposed: start DConf days one hour later

On Wednesday, 27 April 2016 at 18:36:54 UTC, Andrei Alexandrescu wrote: The folks at Sociomantic suggested to start at 10:00 AM instead of 9:00 AM, therefore shifting the end time by one as well. Please reply with thoughts on this! We're particularly concerned about folks who need to take off

Re: LZ4 decompression at CTFE

On Wednesday, 27 April 2016 at 07:51:30 UTC, Dejan Lekic wrote: That is brilliant! I need LZ4 compression for a small project I work on... The decompressor is ready to be released. It should work for all files compressed with the vanilla lz4c -9 please regard this release as alpha quality.

Re: LZ4 decompression at CTFE

On Thursday, 28 April 2016 at 20:12:58 UTC, Stefan Koch wrote: On Wednesday, 27 April 2016 at 06:55:46 UTC, Walter Bright wrote: Sounds nice. I'm curious how it would compare to: https://www.digitalmars.com/sargon/lz77.html https://github.com/DigitalMars/sargon/blob/master/src/sargon/lz77.d

Re: LZ4 decompression at CTFE

On Thursday, 28 April 2016 at 17:29:05 UTC, Dmitry Olshansky wrote: Compression on the other hand might be helpful to avoid precompressing everything beforehand. I fear that is going to be pretty slow and will eat at least 1.5 the memory of the file you are trying to store. If you want a

Re: pl0stuff an optimizing pl0 > c transcompiler

On Friday, 20 May 2016 at 18:04:55 UTC, Stefan Koch wrote: Therefore you can transcompile code at compileTime at call PL/0 functions as there were naively implemented in D. If you do want to call functions from D. You cannot use the optimizer. As it does _very_ aggressive inlineing and will

Re: pl0stuff an optimizing pl0 > c transcompiler

On Monday, 28 December 2015 at 16:41:30 UTC, Stefan Koch wrote: On Monday, 28 December 2015 at 10:45:59 UTC, Nick B wrote: what languages do you plan to support for input and output ? I just planned on PL/0 as input and C as output. It is a simple one-pass (okay 2 pass if you count the

Re: [OT] Re: pl0stuff an optimizing pl0 > c transcompiler

On Friday, 20 May 2016 at 19:20:34 UTC, Johan Engelen wrote: On Friday, 20 May 2016 at 18:04:55 UTC, Stefan Koch wrote: Update I have implemented D codegen. The CodeGenerator as well as the optimizer work at CTFE. Therefore you can transcompile code at compileTime at call PL/0 functions as

Re: My ACCU 2016 keynote video available online

On Saturday, 21 May 2016 at 08:45:45 UTC, Manu wrote: Constraints are a good first-step in that direction, but they're unwieldy, produce the worst looking function signatures (read: documentation) of literally any language ever conceived, relatively awkward error feedback, and very quickly get

Re: Battle-plan for CTFE

On Tuesday, 17 May 2016 at 10:42:30 UTC, Don Clugston wrote: TL;DR: CTFE is actually a backend, so don't be afraid of creating a glue layer for it. My point exactly. The AST is not something I want to handle while inside the interpreter. It introduces too much complexity. There needs to

Re: Berlin D Meetup May 2016

On Tuesday, 17 May 2016 at 11:28:10 UTC, Ben Palmer wrote: Hi All, Apologies for the late notice but the May Berlin D Meetup will be happening at 19:30 on Friday the 20th at Berlin Co-Op (http://co-up.de/) on the fifth floor. The basic idea is to have a hackathon on improving the First 5

Re: Battle-plan for CTFE

On Friday, 13 May 2016 at 13:59:57 UTC, Don Clugston wrote: I think I need to explain the history of CTFE. Originally, we had constant-folding. Then constant-folding was extended to do things like slicing a string at compile time. Constant folding leaks memory like the Exxon Valdez leaks oil,

Re: DustMite now has -j

On Wednesday, 11 May 2016 at 19:53:54 UTC, Vladimir Panteleev wrote: By popular demand. https://github.com/CyberShadow/DustMite/compare/e175b95da070d84029f75ba8a15f5d900fb90704...15693cbd5a5c0f47ee9cc68be9dada39b99c3836 Wow! This is super nice! Thanks!

Re: Battle-plan for CTFE

On Sunday, 15 May 2016 at 10:29:21 UTC, Martin Nowak wrote: 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

Re: Battle-plan for CTFE

On Sunday, 15 May 2016 at 12:54:33 UTC, Daniel Murphy wrote: We really should have discussed this last week! I agree. Maybe we can have a skype conference or something in the next days. About the whole to BC or not to BC discussion. As Daniel already outlined, the main purpose it not

Re: Battle-plan for CTFE

On Sunday, 15 May 2016 at 14:56:02 UTC, Ola Fosheim Grøstad wrote: Well, this looks really bad. But a solver would get you much more than an interpreter. E.g. proving that asserts always hold etc. You want it ? Write it.

Re: D Conference - use twitter #dconf to keep up to date

On Tuesday, 3 May 2016 at 17:35:59 UTC, Iain Buclaw wrote: On 3 May 2016 at 05:10, Walter Bright via Digitalmars-d-announce wrote: Jet lagged as I am, I'll be at breakfast at Hotel Ibis at 630am. Come and join me! Speaking of which, is anyone around

Re: D Conference - use twitter #dconf to keep up to date

On Tuesday, 3 May 2016 at 19:29:08 UTC, Stefan Koch wrote: On Tuesday, 3 May 2016 at 17:35:59 UTC, Iain Buclaw wrote: On 3 May 2016 at 05:10, Walter Bright via Digitalmars-d-announce wrote: Jet lagged as I am, I'll be at breakfast at Hotel Ibis at 630am.

Re: D Conference - use twitter #dconf to keep up to date

On Tuesday, 3 May 2016 at 03:10:57 UTC, Walter Bright wrote: Jet lagged as I am, I'll be at breakfast at Hotel Ibis at 630am. Come and join me! I would like to. Let's see if I make it. Still got to do my slides :)

Re: Battle-plan for CTFE

On Tuesday, 10 May 2016 at 07:44:54 UTC, Rory McGuire wrote: On Tue, May 10, 2016 at 8:45 AM, Jacob Carlborg via Digitalmars-d-announce wrote: I was listening to a discussion Don and Daniel had about the current implementation of CTFE. They talked about

Re: LZ4 decompression at CTFE

On Thursday, 28 April 2016 at 18:31:25 UTC, deadalnix wrote: Also, the damn thing is allocation in a loop. I would like a have an allocation primitive for ctfe use. But that would not help too much as I don't know the size I need in advance. storing that in the header is optional, and

Re: LZ4 decompression at CTFE

On Wednesday, 27 April 2016 at 06:55:46 UTC, Walter Bright wrote: Sounds nice. I'm curious how it would compare to: https://www.digitalmars.com/sargon/lz77.html https://github.com/DigitalMars/sargon/blob/master/src/sargon/lz77.d lz77 took 176 hnecs uncompressing lz4 took 92 hnecs

Battle-plan for CTFE

Hi Guys, I have been looking into the DMD now to see what I can do about CTFE. Unfortunately It is a pretty big mess to untangle. Code responsible for CTFE is in at least 3 files. [dinterpret.d, ctfeexpr.d, constfold.d] I was shocked to discover that the PowExpression actually depends on

Re: Battle-plan for CTFE

On Monday, 9 May 2016 at 20:24:56 UTC, Walter Bright wrote: On 5/9/2016 9:57 AM, Stefan Koch wrote: [...] The memory consumption problem, at least, can be resolved by using stack temporaries instead of allocating new nodes. This was already done in constfold.d, but not in the rest of the

Re: New Diet template engine almost complete, ready for comments

On Monday, 25 July 2016 at 09:29:38 UTC, Sönke Ludwig wrote: The Diet template language is aimed at providing a way to define procedurally generated HTML/XML pages (or other output formats), with minimal visual noise. Syntax and feature set are heavily inspired by Jade ,

Re: Battle-plan for CTFE

Hi, I have fresh performance statistics: The test[1] involved running an empty while loop. Machine 1 Linux : DMD release : Interpreted : 3400 ms || Pseudo-Jited 230 || 50ms Native DMD Debug : Interpreted 4560 || Pseudo-Jited 260ms || Native 230 ms LDC release : Interpreted 2400 ms ||

Re: Battle-plan for CTFE

On Friday, 29 July 2016 at 13:07:12 UTC, Edwin van Leeuwen wrote: On Friday, 29 July 2016 at 11:30:20 UTC, Stefan Koch wrote: I have fresh performance statistics: Is there any improvement in memory usage? Yes! There memory usage is the same as run-time execution. plus about 16k for the

Re: Battle-plan for CTFE

On Friday, 29 July 2016 at 12:47:55 UTC, Robert burner Schadek wrote: On Friday, 29 July 2016 at 11:30:20 UTC, Stefan Koch wrote: please share your thoughts. When is this moving into dmd master? As soon as it passes the test-suite. And can execute diet-ng on the fast-path. Currently I have

Re: Battle-plan for CTFE

On Friday, 29 July 2016 at 14:28:03 UTC, Stefan Koch wrote: if ((a && b) || (a && c)) {//bla} This is now solved although quite naively at the cost of inserting twice the number of instructions for thoose cases. Then agian we are still much faster then the old interpreter. And I can still

Re: Beta D 2.071.2-b1

On Monday, 1 August 2016 at 11:02:41 UTC, Martin Nowak wrote: First beta for the 2.071.2 point release. We've prolonged the 2.071.x releases to fix all outstanding bugs related to the 2.071.0 import and lookup changes before moving on to 2.072.0. http://dlang.org/download.html#dmd_beta

Re: Battle-plan for CTFE

I am very happy to announce that calls are almost working now. And the code-gen-interface[1] is near finalization. It should be very easy to provide different back-ends such as LLVM or libJIT now. The missing pieces well be added during next week. I invite everyone to comment on the interface

Re: Battle-plan for CTFE

I have just committed the changes necessary for (ascii) string indexing and (ascii) string-foreach. Currently working on UTF8 => UTF32 auto-re-encoding and StringConcat and Slice-Support. Completion of Slice support will also fix the interplay between structs and arrays. Cheers, Stefan

Re: Battle-plan for CTFE

Hi, I took a break from work on string operations and focused instead of improving the robustness of the engine. I.E. for it not to halt the compiler on unsupported expressions. right now, I can compile druntime without failures. Phobos should be working by the end of next week. Have a nice

Re: Battle-plan for CTFE

On Saturday, 9 July 2016 at 20:09:14 UTC, Stefan Koch wrote: I decided to keep a gist updated to represent the current state the new engine can handle. https://gist.github.com/UplinkCoder/89faa06311e417aa93ea99bc92934d3e This is the currentState after approx. 50 hours of work First

Re: Battle-plan for CTFE

On Sunday, 17 July 2016 at 15:57:28 UTC, Rory McGuire wrote: Thanks that would be great, however I think its a while off before it can work on your ctfe implementation. It uses Pegged, so getting the Pegged JSON parser or pegged.peg working would be a first step. pegged uses templates.

Re: Battle-plan for CTFE

On Friday, 15 July 2016 at 20:36:46 UTC, Stefan Koch wrote: I decided to keep a gist updated to represent the current state the new engine can handle. https://gist.github.com/UplinkCoder/89faa06311e417aa93ea99bc92934d3e Internal changes to the bytecode engine make the manipulation of values

Re: Battle-plan for CTFE

On Sunday, 17 July 2016 at 16:43:18 UTC, Rory McGuire wrote: Nice, so I'll be able to see separate improvements in my CTFE stuff vs the pegged template stuff once structs, classes, etc.. are handled in your new ctfe. Yes. Btw while working on printing template-instantiations I discovered

Re: Battle-plan for CTFE

On Thursday, 14 July 2016 at 00:45:53 UTC, Stefan Koch wrote: On Saturday, 9 July 2016 at 20:09:14 UTC, Stefan Koch wrote: I decided to keep a gist updated to represent the current state the new engine can handle. https://gist.github.com/UplinkCoder/89faa06311e417aa93ea99bc92934d3e This is

Re: Battle-plan for CTFE

On Sunday, 17 July 2016 at 12:12:17 UTC, Rory McGuire wrote: Nice! how are you keeping track of changes? Are you tagging / branching each time you get something new working? I just push a new commit. And add code to the gist. Why would I branch ? It all goes towards the same goal.

Re: Battle-plan for CTFE

On Sunday, 17 July 2016 at 13:04:33 UTC, Rory McGuire wrote: On Sun, Jul 17, 2016 at 2:41 PM, Stefan Koch via Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> wrote: [...] A commit does pretty much the same thing. Tags/Branches just make UIs show a "menu&quo

Re: Battle-plan for CTFE

On Tuesday, 10 May 2016 at 00:36:21 UTC, Walter Bright wrote: On 5/9/2016 2:32 PM, Andrej Mitrovic via Digitalmars-d-announce wrote: On 5/9/16, Stefan Koch via Digitalmars-d-announce <digitalmars-d-announce@puremagic.com> wrote: I was shocked to discover that the PowExpression actually d

Re: Battle-plan for CTFE

On Thursday, 7 July 2016 at 13:55:44 UTC, Stefan Koch wrote: I just made a PR to fix it for ctfe. It's a hack but then again ... The whole handling of PowExp is a hack. Clarification now it works on Literals. It is still not available at ctfe and the full non-hackish fix will take a while.

Re: Battle-plan for CTFE

On Thursday, 7 July 2016 at 17:47:28 UTC, Stefan Koch wrote: On Thursday, 7 July 2016 at 13:55:44 UTC, Stefan Koch wrote: I just made a PR to fix it for ctfe. It's a hack but then again ... The whole handling of PowExp is a hack. Clarification now it works on Literals. It is still not

Re: Battle-plan for CTFE

On Friday, 8 July 2016 at 12:17:29 UTC, Rene Zwanenburg wrote: On Friday, 8 July 2016 at 11:32:10 UTC, Stefan Koch wrote: I forgot to mention I posted a short article about the CTFE design on my blog. https://codesoldier.blogspot.com Feel free to comment or give suggestions. Thanks! Posts

Re: Battle-plan for CTFE

On Monday, 9 May 2016 at 16:57:39 UTC, Stefan Koch wrote: Hi Guys, I have been looking into the DMD now to see what I can do about CTFE. [ ] I will post more details as soon as I dive deeper into the code. I decided to keep a gist updated to represent the current state the new engine

Re: DIP: Tail call optimization

On Sunday, 10 July 2016 at 07:43:14 UTC, ketmar wrote: we already has one optimization case speced -- NRVO. and it is BAD. adding another implementation detail to the spec will only worsen the situation, i believe. We have other cases cases where optimization is expected but it is poorly

Re: DIP1001: Exception Handling Extensions

On Sunday, 10 July 2016 at 19:55:37 UTC, Superstar64 wrote: link: https://github.com/dlang/DIPs/pull/9 file: https://github.com/Superstar64/DIPs/blob/exception_extensions/DIPs/DIP1001.md You don't have to use gc-allocated exceptions anyway. Allowing to throw any type makes chaining

Re: Berlin D Meetup July 2016

On Monday, 11 July 2016 at 10:05:15 UTC, Ben Palmer wrote: Hi All, The July Berlin D Meetup will be happening at 20:00 on Friday the 15th of July at Berlin Co-Op (http://co-up.de/) on the fifth floor. This time we will be doing a hackathon with DUB. Mathias Lang will be present to give a

Re: Battle-plan for CTFE

On Saturday, 6 August 2016 at 19:07:10 UTC, Rory McGuire wrote: Hi Stefan, Are you saying we can play around with ascii string slicing/appending already? No, not now, but very soon. I want to have _basic_ utf8 support before I am comfortable with enabling string operations. The gist with

Re: Battle-plan for CTFE

Time for an update. (ASCII)-Strings work reasonably well. I am now working on supporting general Sliceing and Appending. The effort on function calls is also still ongoing. I added a switch to my version of dmd which allows to toggle the ctfe engine. So now I can compare apples to apples when

Re: Battle-plan for CTFE

On Saturday, 6 August 2016 at 23:04:48 UTC, Stefan Koch wrote: On Saturday, 6 August 2016 at 19:07:10 UTC, Rory McGuire wrote: Hi Stefan, Are you saying we can play around with ascii string slicing/appending already? No, not now, but very soon. I want to have _basic_ utf8 support before I

Re: Battle-plan for CTFE

On Tuesday, 9 August 2016 at 12:30:18 UTC, Kagamin wrote: 1. You said CTFE engine can be ctfeable itself? But it uses unions in BCValue - it's not going to work in CTFE, is it? Just wondering myself what's the way to have polymorphism at compile time. 2. The byte code generator interface has

Re: Battle-plan for CTFE

On Monday, 8 August 2016 at 09:51:03 UTC, Johan Engelen wrote: On Sunday, 7 August 2016 at 16:52:28 UTC, Stefan Koch wrote: On Saturday, 6 August 2016 at 23:04:48 UTC, Stefan Koch wrote: No, not now, but very soon. I want to have _basic_ utf8 support before I am comfortable with enabling

Re: Battle-plan for CTFE

On Thursday, 30 June 2016 at 14:17:30 UTC, Timon Gehr wrote: Sorry, I had missed this. I see you were able to make progress. It's fine. Honestly the hardest thing was to actually get started. Once I see something working the excitement carries me forward :) I would appreciate a critical

Re: Battle-plan for CTFE

On Thursday, 30 June 2016 at 07:15:30 UTC, Nordlöw wrote: On Thursday, 30 June 2016 at 03:17:38 UTC, Stefan Koch wrote: 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. I can't wait to see the

Re: Ocean preview finally open sourced

On Thursday, 30 June 2016 at 16:45:43 UTC, Leandro Lucarella wrote: Hello again Dland! I'm happy to finally announce the open sourcing of our Ocean base library, just it time to keep our word and make it in June ;-) [...] I like the structTable :)

Re: Battle-plan for CTFE

On Thursday, 30 June 2016 at 01:32:47 UTC, Martin Nowak wrote: 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.

Re: Battle-plan for CTFE

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.

Re: Battle-plan for CTFE

On Thursday, 30 June 2016 at 14:26:29 UTC, Stefan Koch wrote: On Thursday, 30 June 2016 at 14:17:30 UTC, Timon Gehr wrote: Sorry, I had missed this. I see you were able to make progress. It's fine. Honestly the hardest thing was to actually get started. Once I see something working the

Re: Battle-plan for CTFE

On Monday, 4 July 2016 at 07:33:48 UTC, ZombineDev wrote: On Monday, 4 July 2016 at 07:29:49 UTC, ZombineDev wrote: Nice work! Any chance that you could also improve AliasSeq algorithms, like those in std.meta to compile faster and use less memory during compilation? Or is that too different

Re: Battle-plan for CTFE

Just a small update today. if(__ctfe) and if(!__ctfe) now get special treatment. Also working on getting compiletime-parsers to run.

Re: Moonshot: a DMD fork that outputs Lua

On Tuesday, 21 February 2017 at 12:45:47 UTC, Mithun Hunsur wrote: Hi all, Introducing Moonshot (https://github.com/Philpax/moonshot)! Hi Mithun, Looking over the code for lua it seems that you use std.format a lot a ctfe. I would advise against that as it needlessly increases compile

Re: Getters/setters generator

On Tuesday, 17 January 2017 at 06:26:35 UTC, Eugene Wissner wrote: On Friday, 9 December 2016 at 18:53:55 UTC, Andrei Alexandrescu wrote: Love it, and was toying with similar ideas too. One good extension is to add a predicate to the setter, which guards the assignment. -- Andrei What kind

Re: Battle-plan for CTFE

On Wednesday, 17 August 2016 at 18:24:37 UTC, Rory McGuire wrote: On 17 Aug 2016 18:50, "Stefan Koch via Digitalmars-d-announce" < digitalmars-d-announce@puremagic.com> wrote: Just a small update today. if(__ctfe) and if(!__ctfe) now get special treatment. Also working on get

Re: Battle-plan for CTFE

On Tuesday, 30 August 2016 at 22:01:45 UTC, tsbockman wrote: On Monday, 29 August 2016 at 08:39:56 UTC, Stefan Koch wrote: I just came up with a nifty little patch that makes it possible to ensure that a function is _only_ used at ctfe. Or the opposite. static assert(__ctfe, "This function is

Re: Battle-plan for CTFE

FunctionCall support is done. (with a lot of room for improvement) you can already return strings. now I just have to finish string-comparison and string-concat support to make it usable. And of course the correct translation of logical-expressions...

Re: Battle-plan for CTFE

On Thursday, 1 September 2016 at 20:43:16 UTC, David Nadlinger wrote: See also: https://github.com/dlang/dmd/pull/692 – it's about time we finally got __ctfeWrite() merged. — David Oh yeah. Let me get this into PR shape.

Re: Battle-plan for CTFE

On Thursday, 1 September 2016 at 19:27:17 UTC, Rory McGuire wrote: At the moment I just have a verbose logging mode with pragma(msg) for my CTFE stuff. I have something that will help with that a little bit. https://github.com/UplinkCoder/dmd/tree/__ctfeWriteln when you apply this patch

Re: Battle-plan for CTFE

compiling parts of phobos does no longer crash the new engine. However it still produces incorrect byte-code :)

Re: Battle-plan for CTFE

On Thursday, 8 September 2016 at 10:44:55 UTC, Stefan Koch wrote: compiling parts of phobos does no longer crash the new engine. However it still produces incorrect byte-code :) I think I have taken care of the incorrect bytecode. It was not an issue with the engine itself but rather with the

Re: Battle-plan for CTFE

On Thursday, 8 September 2016 at 14:48:25 UTC, Rory McGuire wrote: On Thu, Sep 8, 2016 at 3:11 PM, Stefan Koch via Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> wrote: On Thursday, 8 September 2016 at 10:44:55 UTC, Stefan Koch wrote: compiling parts of phobo

Re: Battle-plan for CTFE

On Tuesday, 30 August 2016 at 17:29:19 UTC, deadalnix wrote: worth trying to get it into master ? I would say maybe, but let's keep separate things separate. This is a language change. I would not include it in the same series of patch that change CTFE behavior. Yes. It would be confusing.

Re: Battle-plan for CTFE

On Thursday, 1 September 2016 at 13:18:18 UTC, Rory McGuire wrote: the _checkCTFE() function is just a function that does something we're not allowed to do at CTFE, but current implementation does not respect __traits(compiles, ); As far as I can tell that is a bug. Thoughts? It is

Re: Battle-plan for CTFE

On Tuesday, 30 August 2016 at 08:18:47 UTC, Johannes Pfau wrote: There are some nice use cases for this: * Do not enforce @nogc for CTFE only functions, so you can mark a complete module nogc: and CTFE only functions will get ignored * Do not emit code for CTFE only functions. This is

Re: Battle-plan for CTFE

On Thursday, 8 September 2016 at 13:11:23 UTC, Stefan Koch wrote: On Thursday, 8 September 2016 at 10:44:55 UTC, Stefan Koch wrote: compiling parts of phobos does no longer crash the new engine. However it still produces incorrect byte-code :) I think I have taken care of the incorrect

Re: DlangUI 0.9.0: Console backend added

On Tuesday, 13 September 2016 at 07:51:06 UTC, Vadim Lopatin wrote: On Friday, 9 September 2016 at 11:21:07 UTC, Vadim Lopatin wrote: [...] Screenshot of DlangIDE working in console: http://i68.tinypic.com/2hrmkup.png Looks great! can you fix dlang-ui to build on XP ?

Re: Battle-plan for CTFE

On Sunday, 25 September 2016 at 18:21:27 UTC, Rory McGuire wrote: :D congrats! I appreciate it. If all goes well there will be a separate nightly release build from the newCTFE branch, sometime in October. I hope to get alpha bug reports that way. Also I am now starting experimentation

Re: Munich D Meetup

On Sunday, 25 September 2016 at 20:49:47 UTC, Stefan wrote: We would be very glad to meet other people from the forum at the Meetups. Already pitiful enough, that Andrei will have no time this year for a visit. Will keep you informed once we scheduled the next Meetup. I'll try to come next

Re: SQLite-D goes beta!

On Monday, 30 May 2016 at 18:07:09 UTC, Stefan Koch wrote: It is my pleasure to announce that I now consider SQLite-D to be in Beta stage. The reader is now stable enough to read all the test tables I have been given. The fact that it took around 20 minutes to complete index-tree support

Re: Battle-plan for CTFE

On Monday, 19 September 2016 at 18:05:34 UTC, Lurker wrote: Good news anyway! Do you have any preliminary results or goals and expectations that you are going to achieve with your rework? Is it mostly perf/memory improvements, are there any new features that this rework will unlock? Thanks

Re: SQLite-D goes beta!

On Tuesday, 20 September 2016 at 20:34:19 UTC, Karabuta wrote: Great work! Can't wait to see sample code :) It's in app.d also see test.d

Re: Berlin D Meetup September 2016

On Friday, 16 September 2016 at 14:15:28 UTC, Steven Schveighoffer wrote: On 9/16/16 8:38 AM, Stefan Koch wrote: On Monday, 12 September 2016 at 17:26:25 UTC, Ben Palmer wrote: [...] Oh crap. I missed it :( You sure? It's still only Friday, well before 20:00 :) -Steve I am in the

Re: Berlin D Meetup September 2016

On Monday, 12 September 2016 at 17:26:25 UTC, Ben Palmer wrote: Hi All, The September Berlin D Meetup will be happening at 20:00 on Friday the 16th of September at Berlin Co-Op (http://co-up.de/) on the fifth floor. This month we will be having an open hackathon so feel free to bring along

Re: Berlin D Meetup September 2016

On Friday, 16 September 2016 at 20:35:18 UTC, default0 wrote: On Friday, 16 September 2016 at 20:32:46 UTC, Stefan Koch wrote: On Friday, 16 September 2016 at 20:20:23 UTC, default0 wrote: On Monday, 12 September 2016 at 17:26:25 UTC, Ben Palmer wrote: [...] Standing outside at entrance.

Re: Battle-plan for CTFE

On Thursday, 8 September 2016 at 18:54:52 UTC, Stefan Koch wrote: On Thursday, 8 September 2016 at 13:11:23 UTC, Stefan Koch wrote: On Thursday, 8 September 2016 at 10:44:55 UTC, Stefan Koch wrote: compiling parts of phobos does no longer crash the new engine. However it still produces

Re: Battle-plan for CTFE

Hi Guys, First of all, parsers will not make it before September. I am sorry about that. Currently I am fixing issues with the design, that for example prevent slices of slices to work. Also I am writing analysis and debugging code to (such as generating a call-graph and primitive DFA) that

Re: Battle-plan for CTFE

On Monday, 29 August 2016 at 08:05:10 UTC, Rory McGuire wrote: On Mon, Aug 29, 2016 at 9:51 AM, Dominikus Dittes Scherkl via The work you are doing is just awesome! Many thanks. +1 your work is key for our success as a community. R Thanks guys. I just came up with a nifty little patch

Re: Battle-plan for CTFE

On Tuesday, 20 September 2016 at 05:06:57 UTC, Nordlöw wrote: On Monday, 19 September 2016 at 10:07:06 UTC, Stefan Koch wrote: Compiling all of phobos does not crash my engine anymore! Great work! Keep up still! I am proud to announce, (and slightly embarssed because it took to long) that

Re: Battle-plan for CTFE

Another update on CTFE. I have found a few errors in my handling of switch-statments. An efficient solution for this is still pending, Futhermore I have begun to work on ctfe handling refernces. These are a little bit harder to do in bytecode and do pessimise performance if overused. I hope

Re: Battle-plan for CTFE

On Friday, 28 October 2016 at 16:52:46 UTC, Stefan Koch wrote: Another update on CTFE. I have found a few errors in my handling of switch-statments. An efficient solution for this is still pending, Futhermore I have begun to work on ctfe handling refernces. These are a little bit harder to do

Re: Battle-plan for CTFE

On Wednesday, 19 October 2016 at 07:11:24 UTC, Nordlöw wrote: On Sunday, 25 September 2016 at 20:47:41 UTC, Stefan Koch wrote: If all goes well there will be a separate nightly release build from the newCTFE branch, sometime in October. I hope to get alpha bug reports that way. Have you

Re: SQLite-D goes beta!

I just updated ~master with a little tool that will print a dot-file with describing the internal Tree-structure of database. All you need to do is to import layout2dot. And call TreeLayoutToDot on your database. it will give you back a string which you can then give to graph-viz. If dot

<    1   2   3   >