Re: Bounty for -minimal compiler flag
On 2/14/14, 0:22, John wrote: I haven't gone into the history, but the only thing to really object to is 'gc' surely. Isn't the rest of it fairly innocuous? J On Thursday, 13 February 2014 at 23:14:20 UTC, 1100110 wrote: 1. moduleinfo 2. exception handling 3. gc 4. Object Why object to gc? You can always simply not use it, and use only the flags you want. If a library that you use uses it, you don't have to worry about it since it will work without the flags as well as with. IMO this will help make it a lot easier to manage GC allocations if that is what you wish to do.
Re: Bounty for -minimal compiler flag
I haven't gone into the history, but the only thing to really object to is 'gc' surely. Isn't the rest of it fairly innocuous? J On Thursday, 13 February 2014 at 23:14:20 UTC, 1100110 wrote: 1. moduleinfo 2. exception handling 3. gc 4. Object
Re: early alpha of D REPL
On Tuesday, 11 February 2014 at 04:46:41 UTC, Martin Nowak wrote:
Barely running but already fun and a little useful.
Example:
D> import std.algorithm, std.array, std.file;
=> std
D> auto name(T)(T t) {
| return t.name;
| }
=> name
D> dirEntries(".", SpanMode.depth).map!name.join(", ")
=> ./drepl_sandbox
D>
https://github.com/MartinNowak/drepl
http://drepl.dawg.eu/
Very nice! thanks. I tried the following code but it print
nothing:
auto twice = (int a) => 2*a;
twice(2);
What's wrong with that?
Re: Mono-D v1.6 - method override completion
Okay, just implemented a completion mode for method overrides. I won't explain this over here, as there are screenshots depicting everything properly already :-) http://mono-d.alexanderbothe.com/method-override-completion-v1-6/
Bounty for -minimal compiler flag
I think it's about time I gave back to this wonderful community. I'm offering a $50 bounty on this. (Preferably Bitcoins, but I'll use bountysource if desired.) rules: Has to be called -minimal Has to fulfill Walter's original post. (listed below) Has to split the separate parts into different flags as well as -minimal(-nogc, -nomoduleinfo, etc. Naming is left to the implementer). This seems to be a good idea and has lots of support from the community, would anyone like to chip in a few more bucks? I haven't set the bounty yet, depends on if multiple people chip in. I'll probably set it sometime tonight. Let me know what y'all think, am I leaving anything out? Thanks On Tuesday, 11 February 2014 at 19:43:00 UTC, Walter Bright wrote: I've toyed with this idea for a while, and wondered what the interest there is in something like this. The idea is to be able to use a subset of D that does not require any of druntime or phobos - it can be linked merely with the C standard library. To that end, there'd be a compiler switch (-betterC) which would enforce the subset. (First off, I hate the name "better C", any suggestions?) The subset would disallow use of any features that rely on: 1. moduleinfo 2. exception handling 3. gc 4. Object I've used such a subset before when bringing D up on a new platform, as the new platform didn't have a working phobos. What do you think?
std.serialization
Well, I wrote the code for this a while back, and although it was originally intended as a replacement for just std.json (thus the repo name), it does have the framework in place to be a generalized serialization framework, and there is the start of xml, and bson implementations, so I'm releasing it as std.serialization. The JSON implementation is the only one I'd consider ready for production use however. The (de)serialization framework takes a step back and asks, "Why do we need pull parsers?", the answer to which is that allocations are slow, so don't allocate. And that's exactly what I do. The serializer does absolutely *no* allocations of it's own (except for float->string conversion, which I don't understand the algorithms enough to implement myself) even going so far as to create an output range based version of to!string(int/uint/long/ulong/etc.). And the benefits of doing it this way are very clearly reflected in the pure speed of the serializer. On my 2ghz i5 Macbook Air, it takes 50ms to serialize 100k objects with roughly 600k integers contained in them when compiled with DMD, this roughly half the time it takes to generate the data to serialize. Compile it with GDC or LDC and that time is cut in half. I have done the exact same thing with deserialization as well, the only allocations done are for the output objects, because there is no intermediate representation. So how do I use this greatness? Simple! import std.serialization, and apply the @serializable UDA to the class/struct you want to serialize, then call toJOSN(yourObject) and fromJSON!YourType(yourString) to your heart's content! Now, there are other serialization libraries out there, such as orange, that take the compile-time reflection approach, but the amount of code required to implement a single format is just massive 2100 lines for the XMLArchive. The entire JSON (de)serialization, which *includes* both the lexer and parser is only 900 lines. Wow, that went a bit more towards a salesman-like description than I as aiming for, so I'll just end this here and give you the link, before this ends up looking like a massive, badly written, sales pitch :D https://github.com/Orvid/JSONSerialization
Re: early alpha of D REPL
very cool
On Thu, Feb 13, 2014 at 12:27 PM, Tourist wrote:
> On Tuesday, 11 February 2014 at 04:46:41 UTC, Martin Nowak wrote:
>
>> Barely running but already fun and a little useful.
>>
>> Example:
>>
>> D> import std.algorithm, std.array, std.file;
>> => std
>> D> auto name(T)(T t) {
>> | return t.name;
>> | }
>> => name
>> D> dirEntries(".", SpanMode.depth).map!name.join(", ")
>> => ./drepl_sandbox
>> D>
>>
>> https://github.com/MartinNowak/drepl
>> http://drepl.dawg.eu/
>>
>
> http://i.imgur.com/LNYMNYw.png
>
Re: ACCU: Wednesday, February 12 - Amaury Séchet, "Multi-core Software Development Challenges and How D Helps"
On Thursday, 13 February 2014 at 02:24:21 UTC, Walter Bright wrote: On 2/11/2014 10:33 AM, Ali Çehreli wrote: Reminder... Ali Dang, wish I could be there. I had a lot of question, so I conclude I got people really interested or really confused. I'll share the slides when I have some time to take care of it.
Re: ACCU: Wednesday, February 12 - Amaury Séchet, "Multi-core Software Development Challenges and How D Helps"
On 02/05/2014 09:48 PM, Ali Çehreli wrote: > When: Wednesday, February 12, 2014 > Topic: Multi-core Software Development Challenges and How D Helps > Speaker: Amaury Séchet Both the speaker and the audience were great. I learned a lot. I hope Amaury will publish his slides. I apologize for not recording the presentation. We will get our equipment soon. Ali
Re: Scott Meyers will deliver a keynote talk at DConf 2014
On Thursday, 13 February 2014 at 10:36:37 UTC, tivadj wrote: Next announcement, please, "Linux moves to D" ;) I'm crossing my fingers for "Facebook is fully supporting D and is now working on solid cross-platform debugging tools." ...I can dream.
Re: Scott Meyers will deliver a keynote talk at DConf 2014
Next announcement, please, "Linux moves to D" ;)
Re: early alpha of D REPL
On Tuesday, 11 February 2014 at 04:46:41 UTC, Martin Nowak wrote:
Barely running but already fun and a little useful.
Example:
D> import std.algorithm, std.array, std.file;
=> std
D> auto name(T)(T t) {
| return t.name;
| }
=> name
D> dirEntries(".", SpanMode.depth).map!name.join(", ")
=> ./drepl_sandbox
D>
https://github.com/MartinNowak/drepl
http://drepl.dawg.eu/
http://i.imgur.com/LNYMNYw.png
Re: early alpha of D REPL
On Tuesday, 11 February 2014 at 04:46:41 UTC, Martin Nowak wrote:
Barely running but already fun and a little useful.
Example:
D> import std.algorithm, std.array, std.file;
=> std
D> auto name(T)(T t) {
| return t.name;
| }
=> name
D> dirEntries(".", SpanMode.depth).map!name.join(", ")
=> ./drepl_sandbox
D>
https://github.com/MartinNowak/drepl
http://drepl.dawg.eu/
It would be nice if in the online sandbox the window width could
be changed.
