Re: Damncheck - a property-based testing library
George: I was hoping to get some feedback from the community regarding the quality of the code and if something can be written the D-way. I have also written a blog post about the process (http://blog.zakhour.me/post/d/damncheck-on-building-a-property-based-testing-library-for-d/) Eventually a QuickCheck-like library needs to become standard tool used to test most D projects. There are many other related ideas, like: http://www.cse.chalmers.se/~nicsma/quickspec.pdf Bye, bearophile
Re: Cerealed v0.2.0 - a(nother) D serialisation library
I'll take a look. It's easier to post this on github though.
Atila
On Monday, 8 September 2014 at 19:09:30 UTC, Vicente wrote:
Hello Atila,
I've seen that cerealed has made much progress, it's now at
v0.5.0
This post is for a feature request, I would like to use it with
a struct like this:
import cerealed;
struct nested_associative_array { nested_associative_array[int]
x; }
struct some_struct {
string[] x;
int[][] y;
nested_associative_array[] z;
};
void main(char[][] args) {
some_struct original, restored;
auto enc = Cerealiser();
enc ~= original;
auto dec = Decerealiser(enc.bytes);
restored = dec.value!(some_struct);
assert(original==restored);
}
The serialization process compiles fine, but the restoring part
fails to compile.
I've tried to figure out how to do it, but I am still a
beginner on D.
How difficult do you think it is?
The alternative, orange, works fine, but the struct I'm trying
to export to disk is a few hundreds of MB in size and orange
takes hours to complete and may also run out of memory. Your
implementation, instead, is really fast and efficient!
Re: 438-byte Hello, world Win32 EXE in D
On Monday, 8 September 2014 at 08:18:32 UTC, Ola Fosheim Grøstad wrote: On Monday, 8 September 2014 at 08:08:23 UTC, Kagamin wrote: But that downloaded file is bloatware, because it has to implement functionality, which is not provided by the system. That tiny pe file doesn't download anything, it's completely done by the system. Yeah… http://stackoverflow.com/questions/284797/hello-world-in-less-than-20-bytes My personal best -- At my first job, a customer once made a request for a very simple DOS utility. They did mention that they didn't have much disk space on their machine, so they asked me to try to make the program small. That was a once-in-a-lifetime opportunity. Naturally, I wrote it in asm. The final executable size was 15 bytes. g The customer loved it.
Re: [Mono-D] v2.1.18 Parser/Completion/General fixesimprovements
On 05/09/2014 07:30, Jacob Carlborg wrote: On 04/09/14 23:41, Bruno Medeiros wrote: Why is that ugh? You don't have to save the file on each keystroke, just when completion is invoked, right? In MonoDevelop/Visual Studio the completion is basically invoked as soon as you start to type something. Not as in Eclipse when it's invoked manually or only when typing a dot. Oh I see. Do people like this behavior BTW? Eclipse could also be configured to work like this, but I'm not sure I would like it, (even if there are no problems such as slow autocompletion.). But maybe it just cause I'm used to it. -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: [Mono-D] v2.1.18 Parser/Completion/General fixesimprovements
On 05/09/2014 00:23, Brian Schott wrote: On Thursday, 4 September 2014 at 22:05:35 UTC, Bruno Medeiros wrote: BTW, what is the relation of dscanner to DCD? Or more precisely, why are they separate tools?.. Originally there was just dscanner. One of the things that it did was autocomplete. It wasn't very good at this for a variety of reasons. One of them was that being a plain command-line tool, it had to re-parse EVERYTHING every time you asked for autocomplete. Over time I split the project three ways: The parser/lexer/ast is now libdparse, the autocomplete functionality is in DCD, and static analysis and other stuff is in dscanner. The reason I ask is because there seems to be some functionality only present in dscanner that would be useful for IDEs too, such as dscanner --declaration -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: [Mono-D] v2.1.18 Parser/Completion/General fixesimprovements
On 05/09/2014 17:40, Alex wrote: On Friday, 5 September 2014 at 12:15:09 UTC, Bruno Medeiros wrote: On 05/09/2014 07:32, Jacob Carlborg wrote: Perhaps I'm nitpicking but an external tools doesn't sound like a good idea. A completely separate library that can be shared among tools and be integrated into an IDE, absolutely yes. But not a tool. It's like it was said earlier, a library is easier to integrate, but only if across the same language (for the code the library is written in, and the code the IDE extensions are written in). Well, I spent a (very little though) time getting informed on how everything could be done using dcd-server running in the background. 1) the communication between dcd-server and dcd-client happens via tcp ipc. So extremely easy to implement 2) The currently edited module's text can be piped through that IPC channel to not have to query the hardware IO all the time. 3) My completion 'model' allows having individual import paths for each edited file, project, super-project aka solution. DCD seems not to support this atm(?). 4) D_Parser is heavily woven with all kinds of Mono-D features, so just ripping out the completion component and replacing it with dcd won't bring anything sustainable, since I'd still had to have raw access to all ASTs out there in order to e.g. display a 'breadcrumb' path bar on the editor's top, the doc outline, refactoring features etc. -- An entirely separate Mono-D is needed imho which probably only features basic projecting/build support as well as dcd bindings. Did you, Bruno, discarded your customly written completion framework in favor of dcd? I didn't discard my completion engine, since from what I saw in DCD (at least at the time), DCD didn't seem better than mine (only Mono-D has that honor at the moment ;) ) So I'm keeping it, also because there are a lot of improvements I can make to DDT's completion engine with relative low effort (I just had my time caught up in other features to go into that). Also, there were several limitations with the DCD protocol and/or options. First was lack of DUB support. Then, limited information on the resolved symbols (for example function symbols don't have the full function signature). Then there was also the inability to perform completion with in-memory files. (At least using DCD-client. Are you saying what if the we communicate directly to DCD-server, that is possible? I haven't looked into that, only the README documentation of DCD) I fixed most of these by rolling my own semantic daemon (note, it's not finished yet). Although, to be honest, even though I made an API that supports semantic operations in multiple in-memory files, after I saw Atila Neves lightning talk about fly-check in Vim, I'm fairly convinced just automatically writing all files to the disk would have been good enough, if not even better (I'm thinking the OS would cache the files, so I/O would not be an issue... but that premise would have to be tested) The only significant issue is the same as you mentioned in 4) . I could shift all my semantic features to the daemon at this point, but I would still need a D parser as part of DDT for all the syntax features - the editor outline, code folding, the breadcrumb, etc.. This functionality would have to be moved to the daemon so that the IDE could be completely free of any D parser or D engine. While that is certainly feasible, I wonder if there could be a significant performance hit: The semantic features (code complete, open definition) are only invoked sporadically, but parsing/syntax features require parsing on more or less every keystroke - so that info would have to be retrieved from the daemon nearly constantly, and would add some overhead... It's something to consider. -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: [Mono-D] v2.1.18 Parser/Completion/General fixesimprovements
On 2014-09-09 15:06, Bruno Medeiros wrote: Oh I see. Do people like this behavior BTW? Eclipse could also be configured to work like this, but I'm not sure I would like it, (even if there are no problems such as slow autocompletion.). But maybe it just cause I'm used to it. I wouldn't mind having an option for it. -- /Jacob Carlborg
Re: 438-byte Hello, world Win32 EXE in D
And how do ldc and gdc do? =)
Re: Programming in D book, User Defined Attributes (UDA) chapter
On Friday, 29 August 2014 at 05:35:12 UTC, Ali Çehreli wrote: Would you recommend considering at least some of Blurb.com's competitors as well? Who? Right. Blurb has a number of pages limitation that would require a two volumes release of your book. :/ Lulu can make it to 740 pages. CreateSpace offers packages up to 828 pages. Both can distribute through Amazon. Prices are somewhat similar... I found this post interesting: http://www.cnet.com/news/self-publishing-a-book-25-things-you-need-to-know/ Otherwise did you contact any publisher? olivier
