Re: Mono-D v1.6 - method override completion
On Friday, 14 February 2014 at 01:26:18 UTC, Alexander Bothe wrote: 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/ new version is cool, but i have found one bug already. when using autocompletion with symbol having trailing numbers in name it matches only last trailing char, for example trying to get completion for ID3D1 will match ID3D10(properly) stuff and also ID3D(1)1 with (1) grayed out, making it impossible to get completion for ID3D11 string. i'm still can't figure exact cases when it happens.
Re: Mono-D v1.6 - method override completion
On Friday, 14 February 2014 at 08:40:04 UTC, evilrat wrote: On Friday, 14 February 2014 at 01:26:18 UTC, Alexander Bothe wrote: 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/ new version is cool, but i have found one bug already. when using autocompletion with symbol having trailing numbers in name it matches only last trailing char, for example trying to get completion for ID3D1 will match ID3D10(properly) stuff and also ID3D(1)1 with (1) grayed out, making it impossible to get completion for ID3D11 string. i'm still can't figure exact cases when it happens. Consider filing an issue for this stuff on github: https://github.com/aBothe/D_Parser Alex usually fixes those kind of issues very fast.
Re: std.serialization
Nice, hope the code is prettier than your speech. :D On Fri, Feb 14, 2014 at 12:56 AM, Orvid King blah38...@gmail.com wrote: 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: std.serialization
On Thursday, 13 February 2014 at 22:56:38 UTC, Orvid King wrote: so I'm releasing it as std.serialization. What does that even mean? I'm pretty sure you should NEVER call a library std.something if it hasn't been approved for inclusion into standard library. Other than that, nice work.
Re: Bounty for -minimal compiler flag
1100110 wrote in message news:tjgimnoqoflzrcrlw...@forum.dlang.org... I'm offering a $50 bounty on this. (Preferably Bitcoins, but I'll use bountysource if desired.) I'd say just put it on bountysource, because then there's more chance others will add to it. rules: Has to be called -minimal Dealbreaker. The description for the switch reads prevents all use of features which rely on druntime and therefore the only reasonable switch name is -nodruntime or a variation of that. 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). Make a enhancement report on bugzilla with the details.
Re: std.serialization
Orvid King wrote in message news:ntpjdeutsxqicjywt...@forum.dlang.org... (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.). std.format.formatValue / std.format.formattedWrite ?
Re: Bounty for -minimal compiler flag
On 2/14/14, 5:10, Daniel Murphy wrote: 1100110 wrote in message news:tjgimnoqoflzrcrlw...@forum.dlang.org... I'm offering a $50 bounty on this. (Preferably Bitcoins, but I'll use bountysource if desired.) I'd say just put it on bountysource, because then there's more chance others will add to it. I thought that would be best, unfortunately. rules: Has to be called -minimal Dealbreaker. The description for the switch reads prevents all use of features which rely on druntime and therefore the only reasonable switch name is -nodruntime or a variation of that. I don't think we'll ever please everyone here. All I'm really trying to do by specifying the name is prevent some cutesy annoying name. I'd be fine with the switch being name -nodruntime, and honestly I like that better. 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). Make a enhancement report on bugzilla with the details. I will as soon as I iron a few wrinkles. I need to figure out if typeinfo should be a part of this as well.
Re: Bounty for -minimal compiler flag
On Friday, 14 February 2014 at 11:28:30 UTC, 1100110 wrote: I thought that would be best, unfortunately. Bitcoins are nice, but bountysource is the way to go. It's both more official and easier to contribute to the bounty. I'd be fine with the switch being name -nodruntime, and honestly I like that better. I like it too. I will as soon as I iron a few wrinkles. I need to figure out if typeinfo should be a part of this as well. Work on the details, take your time, no hurry. I'm in for chipping around 50$ too.
Re: early alpha of D REPL
On Friday, 14 February 2014 at 05:32:12 UTC, Asman01 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/
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?
Drop the semicolon after twice(2)
Re: Bounty for -minimal compiler flag
On 2/14/14, 5:45, Daniel Murphy wrote: 1100110 wrote in message news:ldkuku$1sgt$1...@digitalmars.com... I don't think we'll ever please everyone here. All I'm really trying to do by specifying the name is prevent some cutesy annoying name. It's pretty hard to get a pull request in with a silly switch name, so I wouldn't worry too much about that. I'd be fine with the switch being name -nodruntime, and honestly I like that better. Me too! 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). Make a enhancement report on bugzilla with the details. I will as soon as I iron a few wrinkles. I need to figure out if typeinfo should be a part of this as well. I strongly recommend putting only goals in the enhancement request, and avoiding implementation details (and especially syntax) whenever possible. Eg Struct equality requires typeinfo, but and implementation that changed it to use templates instead would probably be fine. The typeinfo part is irrelevant here, you just want to avoid having to link druntime in. Specifying individual flags is also not recommended, because a better interface might emerge and then the issue of whether the ER is completed gets messy. Instead saying I want a way to disable just the GC avoids this. Alright, I want a way to disable the GC, and have the compiler verify that no GC allocations may occur. I want a way to disable Exceptions, and have the compiler verify that no Exceptions may occur. I want a way to disable linking either the standard library and the runtime, and be able to run a minimal D program without needing to stub anything out manually. The idea can be boiled down to: 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. Can you name anything I'm missing? Finally, putting many things in one request discourages partial fixes, makes discussion harder to follow, and could get complicated with a bounty involved. (what if two people implement different parts etc) It would be better (IMO) to split each atomic feature into its own ER and cross-link them, even if this means splitting the bounty across them. Good point, I'll do that.
Re: std.serialization
On Thursday, 13 February 2014 at 22:56:38 UTC, Orvid King wrote: 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 It's much easier for people to get the gist of it if you generate documentation. It's kind of off-putting to have to rummage through source files with no direction. In the vein of shameless self-promotion, I recommend using bootDoc[1]. :) [1] https://github.com/JakobOvrum/bootDoc
Re: Bounty for -minimal compiler flag
On 2/14/14, 5:42, Francesco Cattoglio wrote: On Friday, 14 February 2014 at 11:28:30 UTC, 1100110 wrote: I thought that would be best, unfortunately. Bitcoins are nice, but bountysource is the way to go. It's both more official and easier to contribute to the bounty. Meh, I just have a lot more spare Bitcoins than actual money at the moment. I can do both though. I'd be fine with the switch being name -nodruntime, and honestly I like that better. I like it too. I will as soon as I iron a few wrinkles. I need to figure out if typeinfo should be a part of this as well. Work on the details, take your time, no hurry. I'm in for chipping around 50$ too. Ok. I think It'd be best if we split this into two bounties for the moment. Here are the two I think are most important. 1. GC -- Give us a way to disable it, GC allocations will not be allowed, and the GC will not run. 2. Runtime -- Give us a way to disable the stdlib and runtime completely, and be able to compile and link programs that do not depend on them. Got any thoughts?
Re: Bounty for -minimal compiler flag
1100110 wrote in message news:ldl2pf$20b0$1...@digitalmars.com... I want a way to disable the GC, and have the compiler verify that no GC allocations may occur. I want a way to disable Exceptions, and have the compiler verify that no Exceptions may occur. Good, this is what I had in mind. I want a way to disable linking either the standard library and the runtime, and be able to run a minimal D program without needing to stub anything out manually. The idea can be boiled down to: 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. Cool. Can you name anything I'm missing? TLS, dynamic cast, profiling, static this/static ~this, assert, -cov, -profile, class == and synchronized all rely on druntime code. Also, D classes will fail to link without Object. Should `array.length = x` be an error or just unsafely set the length? Should it be ABI-compatible with normal D? If you don't have strong feelings about any of these they should still probably be listed.
Re: Bounty for -minimal compiler flag
On Friday, 14 February 2014 at 12:39:11 UTC, 1100110 wrote: Can you name anything I'm missing? * no module info * no runtime type info * treat TLS as __gshared for single threaded programs Mike
Re: Bounty for -minimal compiler flag
On 2/14/14, 7:09, Daniel Murphy wrote: 1100110 wrote in message news:ldl2pf$20b0$1...@digitalmars.com... I want a way to disable the GC, and have the compiler verify that no GC allocations may occur. I want a way to disable Exceptions, and have the compiler verify that no Exceptions may occur. Good, this is what I had in mind. I want a way to disable linking either the standard library and the runtime, and be able to run a minimal D program without needing to stub anything out manually. The idea can be boiled down to: 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. Cool. Can you name anything I'm missing? TLS, dynamic cast, profiling, static this/static ~this, assert, -cov, -profile, class == and synchronized all rely on druntime code. This does come with a cost. I dont know enough about TLS to comment really. Thoughts? Dynamic cast can be disabled. static this/~this is tougher. If it is possible for it to work, then it should. I feel that this is more of a language feature. similarly, I'd expect scope(exit) to still work. profiling and code coverage are fine left out, since other tools can fill the same task. It would be nice if assert didn't depend on the runtime, but it's easy enough to implement. conditional, message and exit(); unittests are out as well. All of those are optional features really. It would be nice to have them, but I feel that those pretty much require a runtime, and the whole point is to *not* require the runtime. Also, D classes will fail to link without Object. I'm unsure how useful classes will be without a GC or the runtime... Thoughts? I'd be fine with then being disabled. Should `array.length = x` be an error or just unsafely set the length? Unsafely set the length. Justification: There is no way to know whether or not you have manually adjusted the array or not. I see it as similar to pointer arithmetic in current D. Whether it works or not is dependent on the programmer. Should it be ABI-compatible with normal D? Yes. It should be as compatible as possible. If that is not possible, then C, as D is compatible with C. If you don't have strong feelings about any of these they should still probably be listed.
Re: early alpha of D REPL
On Friday, 14 February 2014 at 11:58:43 UTC, John Colvin wrote: auto twice = (int a) = 2*a; twice(2); What's wrong with that? Drop the semicolon after twice(2) Yeah, with a semicolon it's a statement, so it doesn't have any result value to print. Without the semicolon it's an expression.
Re: Bounty for -minimal compiler flag
1100110 wrote in message news:ldl6v6$255r$1...@digitalmars.com... I dont know enough about TLS to comment really. Thoughts? It's probably platform dependent, I guess it should work everywhere that C supports TLS. Dynamic cast can be disabled. Sure, but should it be an error or be replaced with a static cast? static this/~this is tougher. If it is possible for it to work, then it should. I feel that this is more of a language feature. These might work with init sections, but maybe not. similarly, I'd expect scope(exit) to still work. With no exceptions, scope(xxx) will work just fine. Similarly, try-catch will be valid, just not throwing. profiling and code coverage are fine left out, since other tools can fill the same task. Yah. It would be nice if assert didn't depend on the runtime, but it's easy enough to implement. conditional, message and exit(); mmm... unittests are out as well. Most likely. All of those are optional features really. It would be nice to have them, but I feel that those pretty much require a runtime, and the whole point is to *not* require the runtime. I don't think it's worth throwing out assert over. A runtime that supported assert + Object would be about 8 lines and would IMO be worthwhile. ie small enough to copy+paste into your main.d Also, D classes will fail to link without Object. I'm unsure how useful classes will be without a GC or the runtime... Thoughts? I'd be fine with then being disabled. I'll take it you've never seen how virtual functions are implemented in C? Classes are awesome. Should `array.length = x` be an error or just unsafely set the length? Unsafely set the length. Justification: There is no way to know whether or not you have manually adjusted the array or not. I see it as similar to pointer arithmetic in current D. Whether it works or not is dependent on the programmer. This puts us in the nasty situation of having code behave differently with and without the switch. Like dynamic cast, I'd rather it was a compile-time error and you had to use arr.ptr[0..newlen] instead.
Re: Bounty for -minimal compiler flag
On 2/14/14, 8:07, Daniel Murphy wrote: 1100110 wrote in message news:ldl6v6$255r$1...@digitalmars.com... I dont know enough about TLS to comment really. Thoughts? It's probably platform dependent, I guess it should work everywhere that C supports TLS. Dynamic cast can be disabled. Sure, but should it be an error or be replaced with a static cast? static this/~this is tougher. If it is possible for it to work, then it should. I feel that this is more of a language feature. These might work with init sections, but maybe not. similarly, I'd expect scope(exit) to still work. With no exceptions, scope(xxx) will work just fine. Similarly, try-catch will be valid, just not throwing. profiling and code coverage are fine left out, since other tools can fill the same task. Yah. It would be nice if assert didn't depend on the runtime, but it's easy enough to implement. conditional, message and exit(); mmm... unittests are out as well. Most likely. All of those are optional features really. It would be nice to have them, but I feel that those pretty much require a runtime, and the whole point is to *not* require the runtime. I don't think it's worth throwing out assert over. A runtime that supported assert + Object would be about 8 lines and would IMO be worthwhile. But then where do we stop? This is why I think it's an excellent idea to have multiple flags, or options, one for each thing disabled. So you can only disable what you do not want. ie small enough to copy+paste into your main.d Also, D classes will fail to link without Object. I'm unsure how useful classes will be without a GC or the runtime... Thoughts? I'd be fine with then being disabled. I'll take it you've never seen how virtual functions are implemented in C? Classes are awesome. Should `array.length = x` be an error or just unsafely set the length? Unsafely set the length. Justification: There is no way to know whether or not you have manually adjusted the array or not. I see it as similar to pointer arithmetic in current D. Whether it works or not is dependent on the programmer. This puts us in the nasty situation of having code behave differently with and without the switch. Like dynamic cast, I'd rather it was a compile-time error and you had to use arr.ptr[0..newlen] instead. Very Very good point there. I didn't think about that. Code should not behave any differently with different switches. Period. I seriously doubt it would make it into the repo either.
Re: Bounty for -minimal compiler flag
1100110 wrote in message news:ldl9fj$28g6$1...@digitalmars.com... I don't think it's worth throwing out assert over. A runtime that supported assert + Object would be about 8 lines and would IMO be worthwhile. But then where do we stop? This is why I think it's an excellent idea to have multiple flags, or options, one for each thing disabled. So you can only disable what you do not want. 'assert' is pretty fundamental (compared to something like exceptions) and is especially important in low-level code. It can also be disabled using -release. I guess worst case the compiler could inline it as `e || _whatever_the_clib_calls_on_assert_failure` This puts us in the nasty situation of having code behave differently with and without the switch. Like dynamic cast, I'd rather it was a compile-time error and you had to use arr.ptr[0..newlen] instead. Very Very good point there. I didn't think about that. Code should not behave any differently with different switches. Period. I seriously doubt it would make it into the repo either. Hmm, I forgot about new and delete. They would be nice to have as wrappers around malloc, but that would change the meaning of code...
Re: Bounty for -minimal compiler flag
On Fri, 14 Feb 2014 10:46:19 -0500, Adam D. Ruppe destructiona...@gmail.com wrote: On Friday, 14 February 2014 at 15:34:16 UTC, Steven Schveighoffer wrote: I think classes heavily depend on druntime, I believe Walter was indicating they would not be allowed (which trivially excludes class ==) My problem with excluding them is that it isn't hard to bring in the druntime parts they depend on when you need it. It's not like writing a class is a hidden feature - you don't need the compiler to help you find places you used them, and the linker error about the missing functions are fine. Then we can just provide class support in one module that you just start compiling in to opt-in to the feature. Classes are typically written with an expectation that the GC will clean them up. I don't think you can just get rid of that expectation. A class written without the assumption of the runtime is a very different object, and I would be hesitant to name it 'class' in D. I recommend not supporting classes, at least for now. -Steve
Re: Bounty for -minimal compiler flag
Steven Schveighoffer wrote in message news:op.xa929juueav7ka@stevens-macbook-pro.local... static this/~this is tougher. If it is possible for it to work, then it should. I feel that this is more of a language feature. These might work with init sections, but maybe not. No, static ctor/dtor is not a trivial mechanism. There is a runtime graph analysis to make sure there are no cycles, and then run them in the proper order. I think this feature has to be disabled. I meant that we could get something mostly working using init sections, but it's probably not a good idea. unittests are out as well. Most likely. Yes, this also depends on moduleinfo, like static ctor/dtor. Same with this, not worth the hack. I'll take it you've never seen how virtual functions are implemented in C? Classes are awesome. This requires vtables and typeinfo. I've seen virtual functions implemented in C (back when I wrote Xt widgets). I also think that with D's compile-time power, one could probably recreate it using templates. I don't want to recreate it, I want to avoid it. The issue I have with allowing classes is the implications of classes. D classes are infinite-lifetime, meaning requiring GC. What we would end up with is classes written for the minimal no-gc version of D, and classes that were written to be allocated on the GC heap in full-D. And both would be named 'class' This is a very good point. extern(C++) classes do not depend on druntime, and currently do not have their destructors run by the GC!
Re: std.serialization
On Friday, 14 February 2014 at 11:22:22 UTC, Daniel Murphy wrote: Orvid King wrote in message news:ntpjdeutsxqicjywt...@forum.dlang.org... (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.). std.format.formatValue / std.format.formattedWrite ? Both of them fall back on a form of printf internally.
Re: std.serialization
On Friday, 14 February 2014 at 10:41:54 UTC, Francesco Cattoglio wrote: On Thursday, 13 February 2014 at 22:56:38 UTC, Orvid King wrote: so I'm releasing it as std.serialization. What does that even mean? I'm pretty sure you should NEVER call a library std.something if it hasn't been approved for inclusion into standard library. Other than that, nice work. Yes, well, I'm bad at coming up with creative names, and, once I get around to writing full documentation for it, as well as do a bit of other cleanup, I'll submit it for inclusion in Phobos.
Re: Bounty for -minimal compiler flag
I don't think, everything should be done by the compiler. Most trouble with gc is that its usage can't be traced similar to tls, so the feature will be diagnostics similar to -vtls option, say, -vminimal. The compiler can write the trace of runtime usage in machine-readable format to stdout (format: `vminimal:feature:file:line`) and a separate frontend (stylesop) can analyze the trace and apply arbitrary feature usage policy. Don't change semantics of language constructs. The first step would be to implement tracing of gc usage.
Re: std.serialization
On 2014-02-13 23:56, Orvid King wrote: 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. What features does it support? How does it handle: * Arrays * Slices * Pointers * Reference types * Support for events * Custom serialization * Serialization of third party types 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! Why require a UDA? 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. The reason for that might be: 1. XML is untyped unlike JSON 2. It supports quite a lot of features that most other serialization libraries don't support -- /Jacob Carlborg
Re: Bounty for -minimal compiler flag
On 2014-02-14 14:50, 1100110 wrote: This does come with a cost. I dont know enough about TLS to comment really. Thoughts? Dynamic cast can be disabled. static this/~this is tougher. If it is possible for it to work, then it should. This requires ModuleInfo, if I recall correctly. profiling and code coverage are fine left out, since other tools can fill the same task. Doesn't that require another flag anyway? It would be nice if assert didn't depend on the runtime, but it's easy enough to implement. conditional, message and exit(); unittests are out as well. Theoretically it should be possible to just disabled the ModuleInfo part and then use __traits(getUnitTests) instead. -- /Jacob Carlborg
Re: Bounty for -minimal compiler flag
On 2014-02-14 15:07, Daniel Murphy wrote: It's probably platform dependent, I guess it should work everywhere that C supports TLS. Well, on OS X it's natively supported on since 10.7 but DMD still uses emulated TLS: Dynamic cast can be disabled. Sure, but should it be an error or be replaced with a static cast? static this/~this is tougher. If it is possible for it to work, then it should. I feel that this is more of a language feature. These might work with init sections, but maybe not. similarly, I'd expect scope(exit) to still work. With no exceptions, scope(xxx) will work just fine. Similarly, try-catch will be valid, just not throwing. profiling and code coverage are fine left out, since other tools can fill the same task. Yah. It would be nice if assert didn't depend on the runtime, but it's easy enough to implement. conditional, message and exit(); mmm... unittests are out as well. Most likely. Theoretically it should be possible to just disabled the ModuleInfo part and then use __traits(getUnitTests) instead. I don't think it's worth throwing out assert over. A runtime that supported assert + Object would be about 8 lines and would IMO be worthwhile. Perhaps leave the assert handler, which could be overridden, which could default to a halt like assert(0) does in release mode? -- /Jacob Carlborg
Re: Bounty for -minimal compiler flag
On 2014-02-14 16:42, Steven Schveighoffer wrote: I'm 90% sure that MacOS does not natively support TLS, and uses the core.Thread class to store it. OS X support TLS natively since 10.7, but DMD still uses emulated TLS on OS X. Yes, this also depends on moduleinfo, like static ctor/dtor. As I've replied to other posts, there's __traits(getUnitTests) as well. -- /Jacob Carlborg
Re: Bounty for -minimal compiler flag
On Fri, 14 Feb 2014 15:39:24 -0500, Jacob Carlborg d...@me.com wrote: On 2014-02-14 16:42, Steven Schveighoffer wrote: I'm 90% sure that MacOS does not natively support TLS, and uses the core.Thread class to store it. OS X support TLS natively since 10.7, but DMD still uses emulated TLS on OS X. That's... old. Why doesn't DMD start using it? 10.7 came out in 2011. Yes, this also depends on moduleinfo, like static ctor/dtor. As I've replied to other posts, there's __traits(getUnitTests) as well. I wasn't aware of that. One has to consider how it will be expected to work. Most of the time, D compiles and runs unit tests if -unittest is passed. What happens in -nodruntime -unittest? Does it just compile the unit tests into the objects but not store the pointers since there is no moduleinfo? Here is a possible compromise: -unittest and -nodruntime are mutually exclusive. If you want to run unit tests, run with -unittest. If you want to run without druntime, use -nodruntime. Any code that builds under -nodruntime should also build without that switch. -Steve
Re: Bounty for -minimal compiler flag
On 2014-02-14 22:02, Steven Schveighoffer wrote: That's... old. Why doesn't DMD start using it? 10.7 came out in 2011. It wasn't that old until recently, when 10.9 was released. It's the same as with everything else. Someone just have to commit time and implement it. I guess this is a bit different though, since we might need to drop support for 10.6. I wasn't aware of that. One has to consider how it will be expected to work. Most of the time, D compiles and runs unit tests if -unittest is passed. What happens in -nodruntime -unittest? -unittest need to be passed for __traits(getUnitTests) to return anything. Does it just compile the unit tests into the objects but not store the pointers since there is no moduleinfo? I would say so, yes. -- /Jacob Carlborg
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/
This approach with separate modules is far superior to what I did
with dabble, and much simpler. My target was windows initially,
where I guess this won't work currently. Hopefully the situation
there will improve soon.
Re: Bounty for -minimal compiler flag
On Thursday, 13 February 2014 at 23:14:20 UTC, 1100110 wrote: 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? I'll throw in $300 extra (maybe more), but can you please first formalize the requirements (list of flags, and what each flag should mean, required unittests to pass etc). I also think it's best to split into a few tasks (e.g. a task per feature or compiler flag). This way it is: - easier to verify correctness/completeness - many people can work without interfering with each other - easier to implement and grab a bounty
Re: Bounty for -minimal compiler flag
Denis Koroskin wrote in message news:wjdvvungwvpemwmxl...@forum.dlang.org... I'll throw in $300 extra (maybe more), but can you please first formalize the requirements (list of flags, and what each flag should mean, required unittests to pass etc). Required unittests are very helpful, specifying switch names less so. I also think it's best to split into a few tasks (e.g. a task per feature or compiler flag). This way it is: - easier to verify correctness/completeness - many people can work without interfering with each other - easier to implement and grab a bounty Yes.
Re: Bounty for -minimal compiler flag
On Saturday, 15 February 2014 at 04:13:49 UTC, 1100110 wrote: 1. Disable Garbage Collector (suggestion: -nogc) https://github.com/D-Programming-Language/dmd/pull/1886 3. Disable ModuleInfo (suggestion: -nomoduleinfo) dmd -betterC though note https://d.puremagic.com/issues/show_bug.cgi?id=11881 5. Disable linking of druntime (suggestion: -nodruntime) dmd -defaultlib= -debuglib=
Re: Bounty for -minimal compiler flag
On 2/14/14, 22:20, Adam D. Ruppe wrote: On Saturday, 15 February 2014 at 04:13:49 UTC, 1100110 wrote: 1. Disable Garbage Collector (suggestion: -nogc) https://github.com/D-Programming-Language/dmd/pull/1886 Oh dmd! Why won't you build on my computer!? Why!? 3. Disable ModuleInfo (suggestion: -nomoduleinfo) dmd -betterC though note https://d.puremagic.com/issues/show_bug.cgi?id=11881 Needs a name that describes what it does, and also needs to be documented. I knew it existed, but I'm a little fuzzy on what all it actually does. Is it just ModuleInfo, or...? 5. Disable linking of druntime (suggestion: -nodruntime) dmd -defaultlib= -debuglib= I thought that was for the stdlib, not the runtime? See? Now I know even less than I did before! Sigh.
Re: Bounty for -minimal compiler flag
On Saturday, 15 February 2014 at 04:34:30 UTC, 1100110 wrote: Is it just ModuleInfo, or...? Yeah, that's pretty much all it actually does, and it isn't quite complete - array bounds checking for example won't work because they depend on module info. But I don't think they should depend on it anyway, regardless of compiler switches. I thought that was for the stdlib, not the runtime? They're the same thing when they are build - druntime and phobos are compiled together into phobos.lib. So turning them off means it won't link it. Then if you provide an object.d in your local directory, it won't even try to load any of the regular druntime. This is how I did it in my minimal.zip.
Re: Bounty for -minimal compiler flag
On 2/14/14, 22:44, Adam D. Ruppe wrote: On Saturday, 15 February 2014 at 04:34:30 UTC, 1100110 wrote: Is it just ModuleInfo, or...? Yeah, that's pretty much all it actually does, and it isn't quite complete - array bounds checking for example won't work because they depend on module info. But I don't think they should depend on it anyway, regardless of compiler switches. I thought that was for the stdlib, not the runtime? They're the same thing when they are build - druntime and phobos are compiled together into phobos.lib. So turning them off means it won't link it. Damn. I *knew* that. I remember reading about it when linux was getting shared lib support. Then if you provide an object.d in your local directory, it won't even try to load any of the regular druntime. This is how I did it in my minimal.zip. Oh good. Then what I actually want is for -betterC to be cleaned up and renamed (and Documented!), add compiler flags for no exceptions, no Object, and a way to turn the silent and link failures into compiler errors. 1) array concats. use the module memory.d instead (link failure) 2) module constructors and destructors (silent failure) 3) looping ModuleInfo without libc or bare metal (silent failure) 4) TLS variables. always use __gshared (runtime crash) 5) threads. 6) unittests (silent failure)
Re: Bounty for -minimal compiler flag
On Saturday, 15 February 2014 at 04:55:32 UTC, 1100110 wrote: Then what I actually want is for -betterC to be cleaned up and renamed (and Documented!) BTW I did *not* actually use -betterC for my minimal.zip. I've been playing with it a bit recently to make an even more minimal thing, but I'm fairly happy with how the first try turned out: it runs on bare (x86) metal and the test binary is 30 KB in size. That's really not too bad: most the language works and some of the parts that don't can be fixed for small cost too. Up from the 5 KB I have going with the -betterC thing and my TypeInfo patches locally (or the 3 KB with no runtime at all, but that means no structs either which massively sucks) but 30 KB isn't really that large and IMO the other parts of the language are worth it. Classes and exceptions are cool. 2) module constructors and destructors (silent failure) What we should get is RTInfo for modules. Why? Then you can have a library module scan the modules for static ctor/dtors and issue a static assert failure. No compiler switch needed, we can do custom project rules. Works in regular D too, totally awesome.
Re: Bounty for -minimal compiler flag
Daniel Murphy, el 14 de February a las 22:10 me escribiste: 1100110 wrote in message news:tjgimnoqoflzrcrlw...@forum.dlang.org... I'm offering a $50 bounty on this. (Preferably Bitcoins, but I'll use bountysource if desired.) I'd say just put it on bountysource, because then there's more chance others will add to it. rules: Has to be called -minimal Dealbreaker. The description for the switch reads prevents all use of features which rely on druntime and therefore the only reasonable switch name is -nodruntime or a variation of that. -nort for short :) -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- Ideas claras, libertad y patriotismo, para mejorar la calidad de vida; claro que todo con mucha calidad, porque, joven, ideas claras, libertad o patriotismo tiene cualquiera. -- Ricardo Vaporeso
