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: 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

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

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 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 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: 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

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: 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 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

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: 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

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 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 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 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 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 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 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: 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: 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: 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: 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: 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 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 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 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 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

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: 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 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: 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.

bf-ctfe

Hi, I just wrote a brain-fuck trans-compiler that works at CTFE. It is at https://github.com/UplinkCoder/bf-ctfe I am using it to profile my CTFE-Engine. However it also nicely demonstrates the power of CTFE. I will be uploading a video describing how it and why it works shortly. Feel

Re: Berlin D Meetup June 2016

On Wednesday, 8 June 2016 at 16:31:47 UTC, Ben Palmer wrote: Hi All, The June Berlin D Meetup will be happening at 20:00 (note new time) on Friday the 17th of June at Berlin Co-Op (http://co-up.de/) on the fifth floor. Danny Arends will be giving a more detailed version of his lightning

Re: Button: A fast, correct, and elegantly simple build system.

On Wednesday, 15 June 2016 at 05:42:21 UTC, Jason White wrote: On Monday, 13 June 2016 at 20:12:27 UTC, Walter Bright wrote: On 6/12/2016 4:27 PM, Jason White wrote: I don't understand this dependency-phobia. It's the "first 5 minutes" thing. Every hiccup there costs us maybe half the

Re: Berlin D Meetup June 2016

On Wednesday, 8 June 2016 at 16:31:47 UTC, Ben Palmer wrote: Hi All, The June Berlin D Meetup will be happening at 20:00 (note new time) on Friday the 17th of June at Berlin Co-Op (http://co-up.de/) on the fifth floor. Danny Arends will be giving a more detailed version of his lightning

Re: Berlin D Meetup June 2016

On Friday, 10 June 2016 at 14:40:41 UTC, Ali Çehreli wrote: On 06/10/2016 05:11 AM, Stefan Koch wrote: On Wednesday, 8 June 2016 at 16:31:47 UTC, Ben Palmer wrote: Danny Arends will be giving a more detailed version of his lightning talk he gave at the D conference on his web server,

Re: Berlin D Meetup June 2016

On Wednesday, 8 June 2016 at 16:31:47 UTC, Ben Palmer wrote: Hi All, The June Berlin D Meetup will be happening at 20:00 (note new time) on Friday the 17th of June at Berlin Co-Op (http://co-up.de/) on the fifth floor. Danny Arends will be giving a more detailed version of his lightning

Re: Recursive SymbolNames solved.

On Wednesday, 8 June 2016 at 13:28:19 UTC, Stefan Koch wrote: Hi, I solved the issue. PR is coming shortly. Solution is as follows: Keep a list of already visited symbols in the mangler. And information where we store the mangle. meaning the position in the mangle string. If a symbol is

Recursive SymbolNames solved.

Hi, I solved the issue. PR is coming shortly.

Re: Battle-plan for CTFE

On Friday, 3 June 2016 at 15:46:27 UTC, Stefan Koch wrote: On Monday, 9 May 2016 at 16:57:39 UTC, Stefan Koch wrote: I will post more details as soon as I dive deeper into the code. Okay I briefly evaluated the current IR dmd uses for backend communication, and it seems usable for the

Re: Battle-plan for CTFE

On Monday, 9 May 2016 at 16:57:39 UTC, Stefan Koch wrote: I will post more details as soon as I dive deeper into the code. Okay I briefly evaluated the current IR dmd uses for backend communication, and it seems usable for the purposes of a CTFE-Interpreter/JIT. The Memory-Management

Re: Fast Deterministic Selection

On Friday, 3 June 2016 at 12:27:13 UTC, Andrei Alexandrescu wrote: I just put a pre-publication draft of a paper on a new algorithm for the selection problem. I'll submit an implementation to D's standard library in the near future. http://arxiv.org/pdf/1606.00484v1.pdf

Re: D Embedded Database v0.1 Released

On Wednesday, 1 June 2016 at 16:03:09 UTC, Piotrek wrote: On Wednesday, 1 June 2016 at 09:41:43 UTC, Stefan Koch wrote: Providing a nice query interface and so on. Do you mean any form of DSL (as it's SQL for SQLite)? I hope to get by without a DSL. And instead to something nice with UFCS.

Re: D Embedded Database v0.1 Released

On Wednesday, 1 June 2016 at 05:45:49 UTC, Piotrek wrote: On Tuesday, 31 May 2016 at 22:08:00 UTC, Stefan Koch wrote: Nice effort. How would you like collaboration with the SQLite-D project. Thanks. Correct me if I'm wrong but SQLite-D is a compile time SQLite3 file reader. If so, I can

Re: D Embedded Database v0.1 Released

On Saturday, 28 May 2016 at 14:08:18 UTC, Piotrek wrote: Short description A database engine for quick and easy integration into any D program. Full compatibility with D types and ranges. Design Goals (none is accomplished yet) - ACID - No external dependencies - Single file

SQLite-D goes beta!

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 convinced mt that I have chosen a solid design. I have

Re: PowerNex - New release of my D kernel

On Sunday, 29 May 2016 at 23:15:13 UTC, Wild wrote: Hey! I have new release of my D kernel called PowerNex. This release should be a bit more interesting than the last one that I release back in November 2015. This one contains a working memory manager, a custom TTY renderer, BMP image

Re: SQLite-D alpha is here [did it mention it works at CTFE]

Support for reading Index-Trees and there(WITHOUT ROWID) tables, has landed in master! Now the real fun can start. CTFE Query translation and optimization.

Re: C++ to D converter based on clang

On Saturday, 28 May 2016 at 11:02:37 UTC, Loïc HAMOT wrote: Hello, I am working on a C++ to D converter. The project is opensource, on github : https://github.com/lhamot/CPP2D [...] Interesting!

Re: Battle-plan for CTFE

On Friday, 27 May 2016 at 23:31:24 UTC, Stefan Koch wrote: 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. Update : int bug6498(int x)

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. Update : int bug6498(int x) { int n = 0; while (n < x) ++n; return

Re: Battle-plan for CTFE

On Saturday, 21 May 2016 at 21:20:54 UTC, Martin Nowak wrote: 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

Re: SQLite-D alpha is here [did it mention it works at CTFE]

On Friday, 27 May 2016 at 07:08:30 UTC, Stefan Koch wrote: On Friday, 27 May 2016 at 05:12:33 UTC, Stefan Koch wrote: There is a locking mechanism in SQLite-proper. However SQLite-D currently makes no attempt in looking for the lock-page. Opps I was wrong :) The Lock-page has nothing todo

Re: SQLite-D alpha is here

On Friday, 27 May 2016 at 05:12:33 UTC, Stefan Koch wrote: There is a locking mechanism in SQLite-proper. However SQLite-D currently makes no attempt in looking for the lock-page. Opps I was wrong :) The Lock-page has nothing todo with threading :)

Re: SQLite-D alpha is here

On Friday, 27 May 2016 at 05:03:43 UTC, xenon325 wrote: For example, I have one thread with traditional (slow) SQLite client, which seldom updates data. And another thread which reads data with sqlite-d. Will not program crash or read trash/inconsistent data ? sqlite-d provides no safety

Re: SQLite-D alpha is here

On Thursday, 26 May 2016 at 19:35:22 UTC, Suliman wrote: Oh! Look like for all time I misunderstood the purpose of your project. Do you mean that your tool is created not for being SQL compatible driver, but make possible to use D code for iteration with DB? Yes and no, currently it does

Re: SQLite-D alpha is here

On Thursday, 26 May 2016 at 14:45:58 UTC, Suliman wrote: Could you explain more details? What do you mean by indirection work with data? Sure, I can explain. So, all that sqlite-d does is reading the sqlite-db files. However the proper sqlite does much more: It implements a whole

Re: SQLite-D alpha is here

On Wednesday, 25 May 2016 at 03:48:48 UTC, Stefan Koch wrote: This project is currently on the back burner. However in the next days there will be another significant performance improvement :) A 20% performance improvement has landed in master! It is possible that there are more places in

Re: SQLite-D alpha is here

On Wednesday, 25 May 2016 at 06:52:22 UTC, Suliman wrote: Even faster then official version? What about futures, would it possible to make it's 100% compatibility with C version? Not really. The reason why it is faster is because there is no indirection in working with the data. If I had

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: [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: 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: 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 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: 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: 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 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 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 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: 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

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: 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 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 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: 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 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

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: 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 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: 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: 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 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 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

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: 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!

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: 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: Terminix 0.51.0 Released

On Saturday, 27 February 2016 at 23:13:47 UTC, Gerald wrote: Terminix is a tiling Linux terminal emulator I've been working on designed for the Gnome 3 environment and using GtkD. This newest release fixes a number of bugs and adds some new features. I'm announcing it here primarily for D

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: Berlin D Meetup February 2016

I'll also try to be there.

<    1   2   3   >