Re: From the D Blog: Driving with D
On Tuesday, 1 June 2021 at 11:57:34 UTC, Mike Parker wrote: Dylan Graham writes about his experience using D in a microcontroller project and why he chose it. Does anyone know of any similar projects using D? I don't. This may well be the first time it's been employed in this specific manner. At first, when I saw the title, I thought Ali applied some D code to a Mercedes ECU;) But the story is really heartening to me. A great initiative. Congratulations :) Cheers, Piotrek
Re: Beta 2.093.0
On Friday, 3 July 2020 at 15:03:28 UTC, aberba wrote: I don't think I've ever said this but the DMD experience is incredible. I actually enjoy using it. ♥️ to all the people making things happen. +1 I think I discover new goodies in D ecosystem very month. Thank you everyone! Cheers, Piotrek
Re: Our HOPL IV submission has been accepted!
On Saturday, 29 February 2020 at 01:00:40 UTC, Andrei Alexandrescu wrote: Walter, Mike, and I are happy to announce that our paper submission "Origins of the D Programming Language" has been accepted at the HOPL IV (History of Programming Languages) conference. "Origins of the D Programming Language" - a good title for the movie of the year ;) Getting a HOPL paper in is quite difficult, and an important milestone for the D language. We'd like to thank the D community which was instrumental in putting the D language on the map. Big thanks to all involved. And of course to you, Andrei. Good luck! Cheers, Piotrek
Re: The Serpent Game Framework - Open Source!!
On Thursday, 27 February 2020 at 22:29:41 UTC, aberba wrote: Pew! Pew!! Nailed it. https://itsfoss.com/ikey-doherty-serpent-interview/ Thank you for sharing. Cheers, Piotrek
Re: The Serpent Game Framework - Open Source!!
On Saturday, 29 February 2020 at 13:14:47 UTC, Patrick Schluter wrote: Unfortunately, I’m too stupid to use Rust I would add to this that I am also lazy ;) And my observation is that 95% of programmers won't use voluntarily any language requiring manual memory management. Doing SW development with GC is a blessing. Of course, allowing manual memory management as opt-in feature is a requirement for system programming (my domain). And D wins here both with Rust(no GC) and Go (only GC). Cheers, Piotrek
Re: Two New Manpower Initiatives
On Monday, 15 April 2019 at 10:08:31 UTC, Mike Parker wrote: I've just published a post on the blog introducing two new initiatives, the Manpower Share and the Manpower Fund, that came out of our quarterly D Language Foundation meetings. The goal is to help focus energy on getting more effort directed at the issues that fall by the wayside. The blog post has all the details, so I encourage everyone who cares about improving D and its ecosystem to give it a read. The blog: https://dlang.org/blog/2019/04/15/manpower-in-the-d-ecosystem-or-resources-resources-resources/ Reddit: https://www.reddit.com/r/d_language/comments/bde7zq/manpower_in_the_d_ecosystem_or_resources/ Great write-up. IMO, the direction is right and looks promising. Of course, besides me only talking, I'm aware that something material can be done. And hopefully, I won't miss a chance ;) Cheers, Piotrek
Re: New DConf Blog Post
On Saturday, 23 March 2019 at 10:09:12 UTC, Ali Çehreli wrote: Thank you but this is only about software development tools. I know. But that's still a good marketing. And I'm fan of your tech talks as well. Coding guidelines like MISRA and AUTOSAR have been developed and matured for C++ for years. There is no equivalent for D for it to be even considered by the automotive industry. Well, MISRA is an evidance that C (C++) is quite error prone by desing. I think, D can do better, . And the lack of dedicated tools is just a consequence of shortage on funds. And I always say that the fact that C needs so many different tools (including those for AUTOSAR) is its disadventage actually (they consumes a lot of money and development time). But it is how the World works now. But who knows the furure? ;) Cheers, Piotrek
Re: New DConf Blog Post
On Friday, 22 March 2019 at 13:58:01 UTC, Mike Parker wrote: The DConf schedule was announced last Sunday. I've just published a write-up about it on the blog for the world-at-large. Please help us out by sharing this post in your social media circles. As usual, Ali is bringing something cool: "The D programming language is used in writing development tools at Mercedes-Benz Research and Development, North America." This is a great sign that D can get more awareness in the automotive industry. Looking forward to D on wheels. Cheers, Piotrek
Re: D is helping from porch pirates
On Monday, 17 December 2018 at 23:13:18 UTC, Daniel Kozák wrote: https://gma.abc/2zWvXCl D supports the bright side of life ;) That's a good spirit. Thanks for sharing. Cheers, Piotrek
[OT] "I like writing in D" - Hans Zimmer
You may already know that from youtube. It seems D starts getting traction even among musicians: https://www.youtube.com/watch?v=yCX1Ze3OcKo=youtu.be=64 That really put a smile on my face :D And it would be a nice example of a D advertising campaign ;) Cheers, Piotrek
Re: ModuleInfo, factories, and unittesting
On Friday, 23 December 2016 at 17:07:29 UTC, Atila Neves wrote: On Friday, 23 December 2016 at 16:28:58 UTC, Piotrek wrote: On Friday, 23 December 2016 at 11:21:00 UTC, Atila Neves wrote: The worst is how useless plain `assert` is. But, all of these issues can (and have) be solved by libraries. Atila Cheers, Piotrek Would assert fixing take into account it's presence in betterC code? Why would you care if the unittest build is betterC or not? The main build, sure, but it really shouldn't matter if the unit tests need druntime or the whole kitchen sink. Atila I was referring to "assert" call in general here. I don't have enough experience for all betterC requirements. And I think I have never used unit tests and betterC switch together. Cheers, Piotrek
Re: ModuleInfo, factories, and unittesting
On Friday, 23 December 2016 at 17:22:48 UTC, Kagamin wrote: On Friday, 23 December 2016 at 16:25:13 UTC, Piotrek wrote: In result I have to accept small obstacles and go on. Otherwise I wouldn't go anywhere. So the real question is: what can we do and what should we do with the current amount of resources we have? If you need a testing framework, try dunit https://wiki.dlang.org/Libraries_and_Frameworks#Unit_Testing_Framework No. I want to use build-in unit testing. Cheers, Piotrek
Re: ModuleInfo, factories, and unittesting
On Friday, 23 December 2016 at 11:21:00 UTC, Atila Neves wrote: The worst is how useless plain `assert` is. But, all of these issues can (and have) be solved by libraries. Atila Would assert fixing take into account it's presence in betterC code? Cheers, Piotrek
Re: ModuleInfo, factories, and unittesting
On Friday, 23 December 2016 at 14:06:24 UTC, Adam D. Ruppe wrote: Have you seen my filthy hack for getting individual unittests to continue on failure? http://stackoverflow.com/a/40896271/1457000 I have to say you are a master of D hacks :) This code can potentially reprogram a CPU and break my HW! pragma(joking, off). It'd be a lot easier though to just actually get the compiler or library to do it. There's so many ways, I personally like the RTInfo for modules approach, it is easy to implement, easy to customize per project, and gives us access to the CT features. But there's others too. And that's why I said *quick development*. In theory, I can add any feature to any language by myself with a certain level of investment. But it's not the reality for 99,999% (all poor and lazy) programmers. In result I have to accept small obstacles and go on. Otherwise I wouldn't go anywhere. So the real question is: what can we do and what should we do with the current amount of resources we have? Personally I can also be involved in development of new (important in my opinion) enhancements to one of the greatest features in D, i.e. built in uinttesting. I'm even opting for changing the compiler if it's necessary (like expanding "-unittest" switch). But of course limiting to DRuntime only would be a step forward anyway. I wonder what Walter thinks about it now, because as far as I remember he was against build-in unittest improvements. Cheers, Piotrek
Re: ModuleInfo, factories, and unittesting
On Thursday, 22 December 2016 at 09:10:53 UTC, Walter Bright wrote: On 12/21/2016 11:24 PM, Walter Bright wrote: On 12/21/2016 9:43 AM, Johannes Pfau wrote: You need some kind of linker support to do this to provide the start/end symbols. That's partially correct. I've done this for decades by having the compiler itself emit those symbols. There are other tricks one can do, such as putting the pointers into the exception handler tables sections. Or have the compiler call a "registerUnittest()" function with a parameter that's the pointer to the unittest info. Of course, that would require that a registerUnittest function exists somewhere. I don't know what other people think but the current status of build-in unittests are #1 issue for a quick development. The inability to give test a name (plus selective unittesting) and continue on failure is puzzling to me. Cheers, Piotrek
Re: DIP 1007 - keywords as identifiers with an escape symbol - feedback
On Thursday, 22 December 2016 at 10:47:37 UTC, Basile B. wrote: End of story. This was worth trying anyway. Especially for the "body" keyword. Personally I don't need it anymore, but it is substantial issue for newcomers wanting to use it badly for web/sci dev. This is probably the most controversial keyword. It is a big pain for a pedant person but on the other hand it is really a non-issue among other programming problems. I bet this case will be brought up continuously. So be prepared. It could have been called something like "fbody" or "def". ;) Cheers, Piotrek
Re: DIP 1003: remove `body` as a keyword
On Monday, 21 November 2016 at 20:59:32 UTC, Timon Gehr wrote:
How about this alternative ("in" and "out" blocks inside
function body):
void foo(int a)
{
in
{
assert (a > 0);
}
out
{
(ret) assert(ret > 0);
}
// body code
return a;
}
or for one-liners:
void foo(int a)
{
in assert (a > 0);
out (ret) assert(ret > 0);
// body code
return a;
}
BR,
Piotrek
Won't work. Contracts are part of the function signature.
That's the point.
How does "auto" work? Can't the inner in be applied to the
signature?
BR,
Piotrek
Re: DIP 1003: remove `body` as a keyword
On Saturday, 19 November 2016 at 21:16:15 UTC, Dicebot wrote:
DIP 1003 is merged to the queue and open for public informal
feedback.
PR: https://github.com/dlang/DIPs/pull/48
Initial merged document:
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1003.md
If you want the change to be approved and have ideas how to
improve it to better match on
https://github.com/dlang/DIPs/blob/master/GUIDELINES.md and
existing published reviews - please submit new PR with
editorial and ping original author.
How about this alternative ("in" and "out" blocks inside function
body):
void foo(int a)
{
in
{
assert (a > 0);
}
out
{
(ret) assert(ret > 0);
}
// body code
return a;
}
or for one-liners:
void foo(int a)
{
in assert (a > 0);
out (ret) assert(ret > 0);
// body code
return a;
}
BR,
Piotrek
Re: We need to enhance the standard library!
On Wednesday, 7 September 2016 at 15:22:01 UTC, Jack Stouffer wrote: 2. Everything but the math library is extremely prone to change within a couple of years and is therefore not really a good candidate for standardization. There's a reason that there are three different ways to connect to a MySQL database within the PHP standard library: they tried to standardize something that shouldn't really be standardized. Almost every "standard" evolves (e.g. USB, 3GPP, etc) and are subject to change in subsequent releases. Stopping the progress is not a case in good standardization process. As for PHP, it did most things wrong. What I mean is if one of car manufactures makes bad cars shouldn't we use all of them. Piotrek
Re: We need to enhance the standard library!
On Wednesday, 7 September 2016 at 05:58:37 UTC, Brian wrote: Standard library thin! The lack of a lot of commonly used functions! For example, HTTP client, database abstraction layer, mail delivery, Mathematical calculation standard library. We can refer to the implementation of some of the standard library golang/java/rust, so that the whole language active up: Https://golang.org/pkg/ Https://docs.oracle.com/javase/8/docs/api/ Https://doc.rust-lang.org/std/ The only problem is lack of resources. IMO, there is no valid argument to limit the Phobos functionality used by most of programmers (like database, gui, multimedia, network, dsp, numeric, etc) Piotrek
Re: Why I can't catch the exception?
On Sunday, 5 June 2016 at 18:20:12 UTC, Era Scarecrow wrote: The assertion is being thrown in the storage.d and backtracking it basically points to line 115 (usersCollection), so am going to guess based on error messages alone that you are passing a struct/class that doesn't match inputs that it is expecting for one of the elements it needs to store. So my advice is to look at the User struct/class, and then look at the DB's User table. But this is just a far thrown guess at the problem. You are very close. This is just a limitation of the current database code which can only handle the simplest structs. https://gitlab.com/PiotrekDlang/DraftLib/issues/4 Piotrek
Re: D Embedded Database v0.1 Released
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)? Well I can see the non-realtime property being a factor for every database. And this is actually disadvantage of those databases ;) BTW1. Thank to the one who posted my reply on Reddit :) BTW2. Somebody on the Reddit suggested the LMDB is an equivalent of this DB. However I fear it's not true. To me, LMDB is a key/value storage backed by a memory-mapped file. However my DB will have more features including: - internal references (no data replication - aka database normalization) - indexes - transparent data compression and more :) Piotrek
Re: D Embedded Database v0.1 Released
On Wednesday, 1 June 2016 at 06:47:36 UTC, Suliman wrote: I still think that gitlab is bad place for DB. People prefer look sources at git or in Google. So DB should have site or git mirror to be popular. I don't think I fully understand what you mean. This is a D library not a separate product. Also what is the difference between git mirror and Gitlab? Piotrek
Re: D Embedded Database v0.1 Released
On Tuesday, 31 May 2016 at 20:31:26 UTC, Dmitri wrote: This might provide useful information if you're aiming for something like sqlite (hopefully not offtopic): https://github.com/cznic/ql It's an embeddable database engine in Go with goals similar to yours and at an advanced stage. The key difference is that ql is an SQL database and mine is not. I know it may sound scary, but I think an SQL layer is a burden when the D power is at hand (unless you need a DB running on a separate machine than the rest of the application). Piotrek
Re: D Embedded Database v0.1 Released
On Wednesday, 1 June 2016 at 05:45:49 UTC, Piotrek wrote: BTW. Would someone be so kind and post the above paragraph on Reddit under a comment about Sqlite db. I'm not registered there. I mean this thread of course: https://www.reddit.com/r/programming/comments/4lwufi/d_embedded_database_v01_released/ Piotrek
Re: D Embedded Database v0.1 Released
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 predict not many common parts. Maybe the one would be a data deserialization component however I didn't check how it's done in SQLite-D. With has similar goals albeit file format compatible to SQLite. When I was selecting possible file format I was thinking about SQLite one. I am actually a fan of the SQLite project. However there are some shortcomings present in current SQlite3 format: - SQlite3 is not really a one file storage (i.e. journal file) - it gets fragmented very quickly (check out design goals for SQLite4) - it's overcomplicated and non deterministic with respect to real time software - it has unnecessary overhead because every column is actually a variant type Add to this the main goal of replacing SQL with D ranges+algorithms. In result it turned out it would be great to have an alternate format. BTW. Would someone be so kind and post the above paragraph on Reddit under a comment about Sqlite db. I'm not registered there. Piotrek
Re: Copyright for Phobos to D Foundation
On Monday, 30 May 2016 at 16:03:05 UTC, Andrei Alexandrescu wrote: On 05/28/2016 01:50 PM, Seb wrote: Ping @WalterBright, @andralex & people with legal experience. I have none, sorry. We have an attorney at least temporarily to help our nonprofit status application, I can forward precise questions if needed. -- Andrei AFAIK, there is no trick to defend you entirely from trolls (bad guys in general). The Boost and MIT seem to be the best we can do. I would leave any copywrite line as it is. We can always add more holders. Is there any reason to remove the old ones? Piotrek
D Embedded Database v0.1 Released
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 storage
- Multithread support
- Suitable for microcontrollers
Example code:
import draft.database;
import std.stdio;
void main(string[] args)
{
static struct Test
{
int a;
string s;
}
auto db = DataBase("testme.db");
auto collection =
db.collection!Test("collection_name",true);
collection.put(Test(1,"Hello DB"));
writeln(db.collection!Test("collection_name"));
}
More info for interested at:
Docs:
https://gitlab.com/PiotrekDlang/DraftLib/blob/master/docs/database/index.md
Code:
https://gitlab.com/PiotrekDlang/DraftLib/tree/master/src
The project is at its early stage of development.
Piotrek
Re: My ACCU 2016 keynote video available online
On Tuesday, 17 May 2016 at 08:42:42 UTC, Bill Hicks wrote: On Monday, 16 May 2016 at 13:46:11 UTC, Andrei Alexandrescu wrote: Uses D for examples, showcases Design by Introspection, and rediscovers a fast partition routine. It was quite well received. https://www.youtube.com/watch?v=AxnotgLql0k Andrei Incidentally, 2_000_000 D users have been waiting 10 years for one guy, you, to complete the containers/allocators and many other things. Man, this sh*t writes itself. And here you go again with your borderline racist jokes. Not very cool. If you honestly want to find out if it's "confusing to Africans", I suggest you go to a black neighborhood and ask them. If you want to be a troll please go to the Rust forums. They need you there to protect "underrepresented minorities". Piotrek
Re: Walter's Famous German Language Essentials Guide
On Sunday, 1 May 2016 at 08:30:16 UTC, jack wrote: you keep forgetting about the english who were with the netherlands the largest slave traders of the world up to the first world war. additionally the english plundered most of the world f. ex. india etc. the americans who butchered the native people and sterilized them until 1956. they bring us democracy and forced trade with wars to everyone and create along the way the islamic states. as for the turks and arabs - nobody wants them in europe. as the english found out (guardian), they are a continual problem because of their incest marriages and therefore rapidly sinking iq`s. most people would love it, if the american war mongers would leave europe with the turks and arabs together. Please consider that you won't defeat evil writing such posts on this forum. The point is there bad and good people in all countries. And as I can see you indirectly insulted Ali who seems to be a good person. I know what you are talking about, and believe me, I can agree with you in some points. But this forum is not a good place to start a fight on this matter, especially by accusing all members of a country for its history. There are more proper ways of making this world a better place. For example you can give a positive example of being a good person. I don't mean you should be naive, but I guess you know that already. Piotrek
Re: Phobos posix.mak -> D file using reggae: round 2
On Monday, 18 April 2016 at 15:15:26 UTC, Atila Neves wrote:
Here's[1] another attempt at converting the Makefile for POSIX
systems to D using reggae[2].
...
Destroy!
Atila
I know you your intention was to keep it similar to makefile, but
for me it looks unnecessarily complex.
What whould you say about different approach e.g.:
void configure()
{
with (targets["linux shared library"])
{
inheritConfig("linux 32");
sources = "lib/*.d";
dependency ~= "objects";
output = "somthing.so";
}
}
Piotrek
Re: dlang.org makefile pains
On Tuesday, 22 March 2016 at 23:23:56 UTC, Jakob Ovrum wrote: Bump. Please help. If Martin is the only one who understands the makefile then we have a serious problem. Makefiles are for chosen people. That's why I suggested moving to a d build system. However I'm aware it's not political correct. Piotrek
Re: Idea: std.build instead of dub and make-like tools
On Saturday, 19 March 2016 at 14:20:23 UTC, Atila Neves wrote: On Saturday, 19 March 2016 at 09:54:53 UTC, Piotrek wrote: On Saturday, 19 March 2016 at 09:51:03 UTC, Piotrek wrote: 2. Not "slim" syntax I have similar view on the syntax as Dicebot: http://forum.dlang.org/post/vqdhbplqezgdmgumf...@forum.dlang.org But have to add that I want event simpler (no templates etc.) The reason why there are templates is so that the declarations can be in global scope, like a scripting language. declarations and primitives like e.g. in SCons. You mean like `Program` and `Object`? The equivalent are `scriptlike` and `objectFiles`. There are several high-level rules as well. Atila I was thinking about simple declarative syntax plus fallback to imperative style for custom needs. I will try to give a feedback on reggae after I go further with experimenting. Piotrek
Re: Idea: std.build instead of dub and make-like tools
On Saturday, 19 March 2016 at 17:57:24 UTC, Dicebot wrote: Even 90% is not enough because it leads to forking functionality for those 10%, greatly diminishing standartization. And build systems are highly opinionated. Some people praise imperative systems like SCons - I find it very hard to reason about compared to declarative ones (even compare to Makefiles). Some like magic deduction of dependencies, some stand hard by making stuff explicit. And list goes on. I agree. That's why I wa wondering if consensus is possible. For me declarative style is also the nicest when aplicable. I started that Piotrek Good luck with that anyway :) Sorry it was unfinished sentence :) I'm rather on recon stage. Piotrek
Re: Idea: std.build instead of dub and make-like tools
On Wednesday, 16 March 2016 at 16:36:47 UTC, Dicebot wrote: NB: this is orthogonal to development of dub. Most important functionality of dub is dependency management, acting as a build tool is secondary to that (and can be adjusted to support other build systems instead). Idea itself is good and this is something that reggae could do but it isn't as easy project as it may sound. I didn't know about reggae, looks interesting. However after brief review is seems to be overcomplicated and inconvenient in some cases. As for dub I don't think it is unrelated. Why std.build couldn't be dependency manager? What about: std.build = part of reggae + part of dub Piotrek
Re: Idea: std.build instead of dub and make-like tools
On Thursday, 17 March 2016 at 15:49:07 UTC, Dicebot wrote: On 03/17/2016 07:15 AM, Piotrek wrote: As for dub I don't think it is unrelated. Why std.build couldn't be dependency manager? For same reason you don't want to distribute any other non-trivial tools as sources :) Compilation takes time and has non-trivial dependencies (i.e. networking libraries, git providers etc.), you simply can't put that stuff as a stdlib module/package and expect developers to compile it each time. Hmm, the build module could be compiled once. It sources are supposed to stay unchanged, right? Tight coupling of dependency management and build tool in one entity is just too inflexible. This is single biggest issue I have with dub in its current form. Can you explain it by example (I don't mean dub problems, which I agree exist, but the inflexibility in general)? I can't see a conflict between the two functionalities. Piotrek
Re: Idea: std.build instead of dub and make-like tools
On Saturday, 19 March 2016 at 09:51:03 UTC, Piotrek wrote: 2. Not "slim" syntax I have similar view on the syntax as Dicebot: http://forum.dlang.org/post/vqdhbplqezgdmgumf...@forum.dlang.org But have to add that I want event simpler (no templates etc.) declarations and primitives like e.g. in SCons. Piotrek
Re: Idea: std.build instead of dub and make-like tools
On Friday, 18 March 2016 at 09:51:07 UTC, Atila Neves wrote: Could you explain what is overcomplicated and inconvenient? I'd love some feedback and to be able to fix it. This is rather broad topic and most of the points are related to different view on design goal for build tool. Let me try to list general comments (remember that they are not bugs but mostly consequences of chosen requirements) 1. Unnecessary reliance on external backends. 2. Not "slim" syntax I have similar view on the syntax as Dicebot: http://forum.dlang.org/post/vqdhbplqezgdmgumf...@forum.dlang.org I don't think mixing up dependency management and build systems is a good idea. I made an explicit decision to defer all dependency management to dub. Yeah, that's additional complexity IMO. I still don't see a good reason this has to be separated. Piotrek
Re: Idea: std.build instead of dub and make-like tools
On Friday, 18 March 2016 at 15:31:26 UTC, Dicebot wrote: Hmm, the build module could be compiled once. It sources are supposed to stay unchanged, right? Even "once" will be too much for majority of D users (those who are not also Gentoo users at least :D). Remember - we are not speaking about build as simple as `rdmd std/build.d` at this point, it will have numerous additional dependencies, including linker dependencies. And has to be perfectly cross-platform. I think that std.build could be up to 10KLOC so the compilation time would be not relevant. Tight coupling of dependency management and build tool in one entity is just too inflexible. This is single biggest issue I have with dub in its current form. Can you explain it by example (I don't mean dub problems, which I agree exist, but the inflexibility in general)? I can't see a conflict between the two functionalities. Typical example - we use custom Makefile based framework for internal Sociomantic D projects, one which is much more capable than existing dub build support and works decently for our needs overall. There is no way it can be replaced with dub at its current state. However using the very same dub to fetch sources of 3d-party libraries and ensure version compatibility is something quite desired. When build tool and package management system are packed into one tool, you pretty much need for both to be perfect to match everyones desires. And that is simply impossible. Thanks for explanation. Then let me quote Teoh's great description of a practical build tool: "I think a good balance can be drawn between providing enough primitives that cover almost all conceivable use cases in a build tool, and at the same time provide an "escape hatch" into a full-fledged programming language for those rare but inevitable cases where you need to go outside the box and do what the designers didn't anticipate." IMO this applies to all of compiling, configuring and fetching sources or binaries and their dependencies. I'm aware it's not possible to cover all use cases. But 90-95% is achievable. The rest is relatively easily to be covered by custom d code. I started that Piotrek
Re: Idea: std.build instead of dub and make-like tools
On Thursday, 17 March 2016 at 06:13:48 UTC, H. S. Teoh wrote: I think a good balance can be drawn between providing enough primitives that cover almost all conceivable use cases in a build tool, and at the same time provide an "escape hatch" into a full-fledged programming language for those rare but inevitable cases where you need to go outside the box and do what the designers didn't anticipate. Fully agree. Do you think is it worth to have such a tool as std.build? Piotrek
Re: Idea: std.build instead of dub and make-like tools
On Wednesday, 16 March 2016 at 18:36:48 UTC, Mark Isaacson wrote: From experience, it turns out that having a restricted language to specify your builds/dependencies is a very good thing. You really don't really want a turning complete language for this; it just makes it harder to reason about. I agree that everybody has different experience. My, for example, is opposite. 1. Make and derivatives are unintuitive to use and lead to unmaintained mess. 2. Simple and descriptive formats like JSON means neverending demand for extension and alternatives (dub situation). Piotrek
Idea: std.build instead of dub and make-like tools
Hi, What do you think about concentrating D build system around a hypothetical "std.build" module instead of investing in dub or other custom tools? Also instead of custom build file format like JSON/SDL/XML/YAML we could simply use a d source file, e.g "build.d". All specification would be included in "std.build". Did I miss any blocking point? Piotrek
Re: std.database
On Friday, 4 March 2016 at 16:41:35 UTC, Chris Wright wrote: With embedded databases, there's a lot of variety out there, probably a decent selection of tradeoffs, so I'm not sure any one would be appropriate to phobos. The one written from scratch specially for D (I'm talking in general, nothing particular in mind). This is my idea of the optimal solution. And I can be wrong of course. And there is a need for a module with interface to other databases, something like Erik's project. Piotrek
Re: std.database
On Thursday, 3 March 2016 at 18:48:08 UTC, Chris Wright wrote:
You were a bit vague before. I interpreted you as saying "just
offer a range and an array-like API, and then you can use it
with std.algorithm". But if you meant to offer an API that is
similar to std.algorithm and also array-like, that's more
feasible.
I agree I could be better in describing the concept. But I just
sketched the idea.
You're still left with the task of transpiling D to SQL.
If someone wants to use SQL in its *full power* no D API nor any
other language will suffice. Mainly because it will be always a
traslation layer . The only we can to is to provide an aid like
things suggested by Andrei (sql parser, value binding, etc).
This model does not work with CouchDB.
I don't know CouchDB so I can't comment.
You must avoid using std.algorithm and std.range functions
assiduously because they would offer terrible performance.
For big data in db, plain vanilla std.algorithm won't be
insufficient. I agree.
* No support for complex queries.
Not sure what you mean by complex queries. Also I think the
API allows arbitrary complex queries.
Aggregates, especially with joins. Computed fields.
Regarding computed fields and other database vendor specific
features you are right.
But on the other hand aggregations and joins can be represented
as objects and proxies of objects.
* No support for joins.
Can be done by @attributes or other linking functionality
between DbCollections.
With attributes, you need users to define aggregate types
instead of just using Row and the like. That's ORM territory.
I don't like ORM with respect to SQL. But quasi object database
which can look similar to ORM is not a problem for me.
At a previous job I maintained an internal BI site that exposed
50-100 different queries, each with their own set of result
fields. We didn't want to use ORM there; it would have been
cumbersome and inappropriate.
I can see your point. But the problem can be solved by not using
SQL.
Also, that assumes that you will always want a join when
querying a table. I maintained an application once, using ORM,
in which we sometimes wanted an eager join and sometimes wanted
a lazy one. This posed a nontrivial performance impact.
Something like DbProxy would handle lazy "joins".
I'm not sure ORM would be a candidate for phobos.
As I don't plan to use an (traditional) ORM I'm not involved.
However if other people would find it worthy I don't object.
* No support for projections.
You mean something like referring to part of the item's
fields? I see no problem here.
Let me point you to the existence of the TEXT and BLOB
datatypes. They can each hold 2**32 bytes of data in MySQL.
This is something a DbProxy would handle. Eventually:
struct OrginalObject
{
int id;
string bigString;
}
struct StrippedObject
{
int id;
}
then
auto collA = db.collection!OrginalObject("Big");
auto collA = db.collection!StrippedObject("Big");
In the second line the string is not fetched.
I'm not splitting those off into a separate table to port my
legacy database to your API. I'm not dragging in multiple
megabytes of data in every query.
If you're going full ORM, you can add lazy fields. That adds
complexity. It's also inefficient when I know in advance that I
need those fields.
* In your implementation, updates must bring every affected
row over the wire, then send back the modified row.
In my implementation there is no wire (that's why I call it
embedded). However I thought we talk about API and not
particular implementation. I don't see how this API excludes
RPC. Query strings (e.g. SQL) can be provided in old fashioned
way.
I'm running a website and decide that, with the latest changes,
existing users need to get the new user email. So I write:
UPDATE users SET sent_join_email = FALSE;
-- ok; 1,377,212 rows affected
Or I'm using your database system. If it uses std.algorithm, I
have to iterate through the users list, pulling each row into
my process's memory from the database server, and then I have
to write everything back to the database server.
Depending on the implementation, it's using a database cursor
or issuing a new query for every K results. If it's using a
database cursor, those might not be valid across transaction
boundaries. I'm not sure. If they aren't, you get a large
transaction, which causes problems.
If your database system instead offers a string-based API
similar to std.algorithm, you might be able to turn this into a
single query, but it's going to be a lot of work for you.
For client-server approach I agree with the above. For embedded
design (as in my project) this is not a case.
* Updates affect an entire row. If one process updates one
field in a row and another one updates a different field, one
of those
writes gets clobbered.
I think this is just a "must have" for any db engine. I don't
see how it applies
Re: std.database
On Wednesday, 2 March 2016 at 17:13:32 UTC, Erik Smith wrote: There are a number of areas where this design is an improvement over DDBC: ease-of-use, better resource management (no scope, no GC), phobos compatibility, to name a few. There is a lot more that needs to be added to make it standards grade. I agree with you we need database manipulation in Phobos. However modules like db, gui, xml or similar are too much work for a one developer. And as you can see from time to time there apears someone with its own vision. That's why, long time ago, I suggested DIP73 (http://wiki.dlang.org/DIP73) so the collaborative work would be controlled by the D community (or the D foundation). But I am aware that there is no agreement nor resources for that. Your engine project is interesting. I think there is common ground in the interfaces in the two projects, particularly in how the interface for the results might work. I will look more closely at the details to see what might be workable. erik I agree that we (as a community) should work on common and effective APIs. Maybe when D foundation is big enough... Piotrek
Re: std.database
On Thursday, 3 March 2016 at 01:49:22 UTC, Chris Wright wrote:
If you're trying to connect to a SQL database or a document
database, as I'd expect for something called "std.database"
The thing is I strongly encourage to not reserve std.database for
external database clients and even what is more limiting to SQL
ones only.
, it's a pretty terrible API:
* No index scans, lookups, or range queries.
Indexes can be supported by strings and CTFE, can't they?
e.g.
filter!q{item.elements.length < 10 && item.model == "Sport"}
* No support for complex queries.
Not sure what you mean by complex queries. Also I think the API
allows arbitrary complex queries.
* No support for joins.
Can be done by @attributes or other linking functionality between
DbCollections.
* No support for projections.
You mean something like referring to part of the item's fields?
I see no problem here.
* No support for transactions.
* If you add support for transactions, you'll crash all the
time because
the transactions got too large, thanks to the full table scan
mentality.
Isn't it just the "index support" case?
* In your implementation, updates must bring every affected
row over the
wire, then send back the modified row.
In my implementation there is no wire (that's why I call it
embedded). However I thought we talk about API and not particular
implementation. I don't see how this API excludes RPC. Query
strings (e.g. SQL) can be provided in old fashioned way.
* Updates affect an entire row. If one process updates one
field in a
row and another one updates a different field, one of those
writes gets
clobbered.
I think this is just a "must have" for any db engine. I don't see
how it applies to the proposed API other than any implementation
of db engine has to handle it properly.
When I say DbCollection should behave similar to an ordinal array
I don't mean it should be an ordinal array.
* The API assumes a total ordering for each DbCollection. This
is not valid.
I don't know what you mean here. Example would be good.
* If there are multiple rows that compare as equals, there's
no way to
update only one of them in your implementation.
* In your implementation, updating one row is a ϴ(N)
operation. It still
costs ϴ(N) when the row you want to update is the first one in
the collection.
I'm still not sure if you are referring to my implementation or
hypothetical API. To be clear: my current implementation is still
proof of concept and surly *unfinished*. And in case you refer to
my implementation I plan to support O(1), O(log n) and O(n)
access patterns with its "rights and duties".
Cheers,
Piotrek
Re: C++ UFCS update
On Wednesday, 2 March 2016 at 13:29:03 UTC, Dejan Lekic wrote: I am not sure I agree with this. "->" will make it *visible* what is going on, while "." can mean many things, and I would have to investigate what .something in part of a chain does. Right? Are you sure that "->" is obvious in C++? I ask because it can mean many things, not mentioning it can be overloaded! Piotrek
Re: std.database
On Tuesday, 1 March 2016 at 21:00:30 UTC, Erik Smith wrote: The main focus of this project is to bring a standard interface for database clients.This is similar to the purpose of JDBC (java) and DBI (perl). While there is some existing work in place (ddbc, etc.c.odbc.sql, vibe.d and other newer projects), my goal, after a lengthly period of community review/revision, is to achieve Phobos inclusion for the interface standard and also some of the implementations. There is debate on whether the implementations belong there, but I have made the implementation Phobos compatible (by using templates) while this issue is sorted out. My quick comments: 1. In my opinion it should not be called std.database, but let's say "std.dbc". This is because it looks like a wrapper over db clients. Moreover one may say it's almost impossible to make a common and effective interface which would work with all databases. e.g. someone on Wikipedia argues ODBC is obolete (check "ODBC today") 2. I'm not against such a functionality in Phobos. However your project seems to be a duplication of the DDBC project. And it was not proposed for inclusion so often. 3. What I call a D Database API could be described as: - Database object - DbCollection object (equivalent to array) - ranges + std.algorithm And here is my implementation (experimental) of this API: https://github.com/PiotrekDlang/AirLock/tree/master/docs/database/design.md https://github.com/PiotrekDlang/AirLock/tree/master/src Piotrek
Re: GSoC 2016 - D Foundation was accepted!
On Tuesday, 1 March 2016 at 13:57:00 UTC, Andrei Alexandrescu wrote: Congratulations to everyone who helped, and especially to Craig for driving this! Craig, you should be really proud - this is a great accomplishment. -- Andrei Agree. Craig did a great job. BTW. It is also good news in terms of marketing. The D foundation logo looks awesome along other cool projects. Piotrek
Re: Vision for the first semester of 2016
On Friday, 29 January 2016 at 02:18:38 UTC, Rikki Cattermole wrote: Right now, image library is more or less ready for next feedback. Windowing is almost there, really just needs a bit of testing and its done. So in other words, the hold up, is me. Where can I find the code to be tested? You have too many projects on github :) Piotrek
Re: Proposal: Database Engine for D
On Saturday, 6 February 2016 at 00:14:08 UTC, Mengu wrote: and while we were talking the talk, rust community rolled out something good called diesel. check it out at http://diesel.rs/. we need tools that get things done. we do not need tools that makes things more complex than they already are. Almost no one (including me) is interested in ORM for SQL. The point is ORM+SQL is limiting and sooner or later you fallback to SQL. Additionally there is no critical mass for this kind of big project (combining all the SQL engines - good luck). Andrei suggested a CTFE sql parser, so people who like SQL (not me) can benefit from the D metaprogramming power. For the rest there is my proposal ;) : a language embedded DB. As far as I can tell none of the known PLes has this "killer" feature. Piotrek
Re: Proposal: Database Engine for D
On Saturday, 6 February 2016 at 14:04:42 UTC, Ola Fosheim Grøstad wrote: A good ORM-like interface is mandatory for working with NoSQL databases... Fortunately, I don't plan to work with so called NoSQL databases... BTW. Take a look at the example from the PoC code and check what works currently (i.e. passing unit tests) https://github.com/PiotrekDlang/AirLock/blob/master/docs/database/design.md#example Piotrek
Re: Proposal: Database Engine for D
On Tuesday, 5 January 2016 at 04:19:01 UTC, Chris Wright wrote: You could equivalently have a string containing valid D code, accompanied by CTFE parsers that will determine which indices to use. This has typically been considered an antipattern. It tends to work poorly with refactoring tools, for instance, and there's an assumption that string literals are data and not code. Would the D string tokens do? BTW. Thanks for all your valuable comments. I really like that kind of critique. C#'s system of lambda expressions that you can access as expression trees keeps the benefits of writing everything in the same language. I think I'm still not convinced to that approach (seems hacky). I agree with Walter in that matter (language changes, AST, overloading etc). Especially, D is number one in meta-programming capabilities (among C++ and Rust) and nothing seems to change it in foreseeable future (https://users.rust-lang.org/t/rust-vs-dlang-i-want-more-experienced/4472/11) Piotrek
Re: Vision for the first semester of 2016
On Monday, 25 January 2016 at 03:49:56 UTC, Rikki Cattermole wrote: That won't be happening anytime soon. Until we have image and windowing in Phobos (I'm working on both) there is no way a GUI toolkit is going in. And from what I know there will be a LOT of work to update it. I've read this thread partially and I agree with you. In my opinion the key to the success is a good standard library with batteries included. The opinion that this approach is outdated is very subjective. I hope D GUI will be usable some day for me and other people not wanting to fight with tools (and external libraries). If there is something from your project ready for test drive let me know. Piotrek
Re: Proposal: Database Engine for D
On Saturday, 2 January 2016 at 20:47:37 UTC, Chris Wright wrote:
So you want to create the following query:
people.filter!(x => x.surname == "Slughorn");
And you've got ten million people in the collection, and you
want this query to finish soonish. So you need to use an index.
But a full index scan isn't so great; you want to do an index
lookup if possible.
Correct.
That's simple enough; we generate proxy types to record what
properties you're using and what operations you're performing.
PersonProxy records that you're accessing a field 'surname',
gives a StringFieldProxy, and that records that you're checking
for equality with the string "Slughorn". The lambda returns
true when opEquals returns true.
But people write queries that are more complex than that, like:
people.filter!(x => x.surname == "Slughorn" || x.age <= 17);
First time you run this, x.surname.opEquals("Slughorn") returns
true and the expression as a whole returns true. You missed the
second part of the expression. That's bad.
So we need to evaluate this lambda twice per parameter.
Hmm. Probably we don't think about the "proxy" term in the same
way.
When I mentioned proxy I thought about a skeleton object to
access parts of the original heavy object. So in fact, filter
works on proxy and one evaluation is performed no matter how
complex the condition is. The proxy is responsible to retrieve
needed data. Additionally (I haven't mentioned it yet) we can
provide mechanism for data integrity when joining separate
objects.
You might be able to support queries as large as ten
comparisons in a reasonable timeframe. But for all but the most
trivial queries, it'll be faster to use SQL.
SQL is no magic. You can write a code to beat any SQL planner.
Also I think you had "joins" in mind which I guess are the
biggest problem for performance.
But "What if I tell there is no SQL" Not even under the hood.
Piotrek
Re: Proposal: Database Engine for D
On Sunday, 3 January 2016 at 19:48:42 UTC, Abdulhaq wrote: My two pence, if you want it to be fast then it must have a good implementation of indices. Your filter functions should not actually start collecting real records, but instead should simply change the way that the cursor traverses the underlying data store. You will need good query 'compilation' like the big boys do, which work out which tables and indices to use and in which order, based on stats of the data / indices. Agree (I mentioned about proxies before). But I'm not sure about "good query compilation" thing. Good storage management should do. Rest can be done in user code. If you want ACID then SQL seems like a good approach to me, certainly I wouldn't want anything ORM-like for updating / inserting data. Well. Some people really like SQL. I'm not one of them. I'm neither a fan of ORM+SQL. But I think ACID is not only reserved for SQL. There a number of good libraries out there already, SQLite obviously springs to mind. The SQLite project is great. It would be a fun project but perhaps a lot more work than you realised if you really want isolation levels, speed etc. Yes, I know. But one step at a time. It's a some kind of fun for me as well ;) Cheers Piotrek
Re: Proposal: Database Engine for D
On Monday, 4 January 2016 at 07:59:40 UTC, Jacob Carlborg wrote: On 2016-01-04 00:50, Andrei Alexandrescu wrote: This may in fact be good signal that an approach based on expression templates is not the most appropriate for D. -- Andrei This whole thread has already discussed and showed that D operator overloading is lacking in terms of expression templates. The post by Chris assumes no language changes. If D supported overloading all operators the opEquals method would not return true, it would return a proxy that overloaded the || operator. The whole lambda expression would only generate a single query. The rest of the post falls apart from this mistake. But most of the posts are related to DSL (->SQL). What do you think about solution where no DSL, VM or other intermediate layer is used? Also I have a theory that SQL appeared because of limiting expressiveness of other programming languages (like C) ;) Cheers Piotrek
Re: Proposal: Database Engine for D
On Sunday, 3 January 2016 at 23:22:17 UTC, Jakob Jenkov wrote: You could just target your database at data analysis. Then you don't need to care about ACID, transactions etc. Just load all the data into memory, and start analyzing it. Also, you'd typically be scanning over large parts of the data set for each query, so you may not need to support a full query language. Just what is needed for data analysis. Later you can modify your engine to support ACID, more expressive query language etc. That's the plan:) Except no dedicated query language is planned. At least that's my vision based on what I know about D and databases currently. On one of the projects I am working on right now, we will also implement our own database engine. We need it to integrate tightly with the rest our architecture, and the only way to do that is to roll our own. We will also not be using SQL because SQL is so limiting. So, I'd say "go ahead" - you can only learn something from the project. I've "reinvented a lot of wheels" over the years, and each time I came out smarter than before. Not every reinvention was a success, but I always learned something from the process. Thanks! So at least one more soul believing that D can approach the SQL expressiveness in db domain. Cheers Piotrek
Re: Proposal: Database Engine for D
On Friday, 1 January 2016 at 04:20:19 UTC, tcak wrote: You know someone needs to maintain all that code base continuously. When SQLite is a separate project, it has its own developers and we just bind to its library; it is same for other DBs. Your proposal is nice, but creating another standard, and a group of people needs to take care of it in both documentation and coding wise continuously are biggest issues. Agree. Lack of resources is an enemy of every project. BTW. I don't introduce any new standard except a new file format. Piotrek
Re: Proposal: Database Engine for D
On Friday, 1 January 2016 at 01:34:53 UTC, Rikki Cattermole wrote: You've just introduced two topics. The first is a database engine, abstracting away the drivers. And second an ORM. And maybe even an object-oriented database management system to some extent. OTOH, I removed SQL from the stack. Piotrek
Re: Proposal: Database Engine for D
On Friday, 1 January 2016 at 10:00:43 UTC, Kapps wrote: This example shows the difficulty of doing this in D. You can't really have something like `p.Name == "James"`, or `p.Age < 21` translate to SQL properly without language changes, which I believe Walter or Andrei were against. This has been the key problem when things like Linq to Sql for D have been brought up before. Not really. There is no translation stage to SQL or any other DSL in the proposal. So this problem doesn't exist and no language changes are needed. However there is another issue which must be taken into account. One should decide if the object is retrieved directly or via via proxy. Especially for big objects with lot of aggregated types. Piotrek
Proposal: Database Engine for D
The goal of this post is to measure the craziness of an idea to
embed a database engine into the D language ;)
I think about a database engine which would meet my three main
requirements:
- integrated with D (ranges)
- ACID
- fast
Since the days when I was working on financing data SW I become
allergic to SQL. I though that NoSQL databases would fill the
bill. Unfortunately they didn't. And I want to have an ability to
write a code like this without too much effort:
struct Person
{
string name;
string surname;
ubyte age;
Address address;
}
DataBase db = new DataBase("file.db");
auto coll = db.collection!Person("NSA.Registry");
auto visitationList = coll.filter!(p => p.name == "James");
writeln (visitationList);
And other things like updating and deleting from db. I think you
get my point.
So I started a PoC project based on SQLite design:
https://github.com/PiotrekDlang/AirLock/blob/master/docs/database/design.md#architecture
The PoC code:
https://github.com/PiotrekDlang/AirLock/tree/master/src/database
Can you please share your thoughts and experience on the topic?
Has anyone tried similar things?
Piotrek
Re: PowerNex - My 64bit kernel written in D
On Sunday, 22 November 2015 at 21:05:29 UTC, cym13 wrote: Heck, even the GPL is compatible! http://www.gnu.org/licenses/license-list.html#boost Hi, No. It isn't. It is the other way around "Boost Software License ... is compatible with the GNU GPL.". But GPL is not compatible with the Boost license. Piotrek
Re: PowerNex - My 64bit kernel written in D
On Wednesday, 25 November 2015 at 14:44:09 UTC, Wild wrote: On Saturday, 21 November 2015 at 11:34:57 UTC, Piotrek wrote: On Tuesday, 17 November 2015 at 23:35:58 UTC, Wild wrote: Hey! I have recently started working on a 64bit kernel ... Hi, Good to see more work in the OS area. I am even more happy there is more developers interested in GUI stuff. I have one fundamental question though: Is it possible for you to pick the Boost license (especially for libs)? This is my general concern for all libs developed by the D community. IMO license other than Boost is very cumbersome and doesn't comply with the D core libs. Piotrek Like cym13 said, there should not be any problems with the MPLv2 license. MPLv2 is basically LGPL but at a file level and it won't "infect" any other files. My code can included in any close source projects. The only thing is that if any of my files are changed, those changes need to published. - Dan Hi, No worries :) Feel free to use whatever license you want. It is your code. However my point was that the code released with license other than Boost (or similar) cannot be included in Phobos. That's one thing. The second is, non liberal licenses put burden on commercial adoption and put risk on legal actions. I know that from the employee POV who worked for many corporations and was obliged to follow the rules. The bottom line is that viral licenses (with varying aggressiveness) are in opposition to business. Yes, I know GPL is used by companies but the cost is high. To use analogy: you can live with viruses, but you need money for medicines. BTW. Sorry if I sounded to harsh and forgive me stealing your announcement for my propaganda ;) I'll try to figure out a way to present my ideas in proper way before I have to many enemies. Piotrek
Re: PowerNex - My 64bit kernel written in D
On Tuesday, 17 November 2015 at 23:35:58 UTC, Wild wrote: Hey! I have recently started working on a 64bit kernel ... Hi, Good to see more work in the OS area. I am even more happy there is more developers interested in GUI stuff. I have one fundamental question though: Is it possible for you to pick the Boost license (especially for libs)? This is my general concern for all libs developed by the D community. IMO license other than Boost is very cumbersome and doesn't comply with the D core libs. Piotrek
Re: The D Language Foundation is now incorporated
On Tuesday, 20 October 2015 at 17:08:42 UTC, Andrei Alexandrescu wrote: Walter Bright (President) A snap election in US? ;) Congrats Mr President. Piotrek
Re: Fastest JSON parser in the world is a D project
On Friday, 16 October 2015 at 10:08:06 UTC, Andrei Alexandrescu wrote: On 10/15/15 10:40 PM, Jacob Carlborg wrote: On 2015-10-15 14:51, Johannes Pfau wrote: Doesn't the GPL force everybody _using_ fast.json to also use the GPL license? Yes, it does have that enforcement. Then we'd need to ask Marco if he's willing to relicense the code with Boost. -- Andrei I've just crossed my fingers. Piotrek
Re: Interfaces, traits, concepts, and my idea for a DIP
On Friday, 31 July 2015 at 16:28:30 UTC, jmh530 wrote:
Looking at the PR also resolved my earlier question. Running
the code as below (do not import std.range) will tell you
exactly what isn't implemented from isInputRange (in this case,
I commented out popFront). Very cool.
template satisfies(alias Constraint, R) {
enum check = check ~ Constraint.stringof[2..$-3] ~ !(R);
enum assert_ = static assert(~ check ~ );;
mixin(assert_); //mixes in static
assert(checkInputRange!R)
}
template isInputRange(R)
{
enum bool isInputRange = is(typeof(checkInputRange!R));
}
bool checkInputRange(R)(inout int = 0)
{
if (__ctfe)
{
R r = R.init; // can define a range object
if (r.empty) {} // can test for empty
r.popFront(); // can invoke popFront()
auto h = r.front; // can get the front of the range
}
return true;
}
@satisfies!(isInputRange, Zeroes)
struct Zeroes {
enum empty = false;
//void popFront() {}
@property int front() { return 0; }
}
void main()
{
Zeroes Z;
}
Nice. Here are the actual error messages for the record:
/d125/f236.d(18): Error: no property 'popFront' for type 'Zeroes'
/d125/f236.d(24): Error: template instance
f236.satisfies!(isInputRange, Zeroes) error instantiating
Piotrek
Re: Wait, what? What is AliasSeq?
On Saturday, 18 July 2015 at 01:32:45 UTC, Andrei Alexandrescu wrote: On 7/17/15 8:20 PM, Mike wrote: On Friday, 17 July 2015 at 20:54:33 UTC, Walter Bright wrote: Should just be Aliases. I'd be happy to do the pull request if you wish. Let's get the +1s on this - please reply. I'm fine with Aliases with an extra umph that the BDFL favors it. -- Andrei +1 The code would be just better to read and write with Aliases. To some extent I understand confusion point raised by others. However I not sure if it's overexaggerating. Piotrek
Re: DLL symbol identity
On Sunday, 10 May 2015 at 19:27:03 UTC, Benjamin Thaut wrote: Does nobody have a opinion on this? Sorry for being an extreme noob in the matter. Probably, only Manu fought with Windows dlls for real. As a user I would say I want short startup times as I change/execute the active application *very* often. However I'm not sure I hit HDD seek time penalty or the system loader activity. TBH I think Linux is more sleepy which I don't like (but again, this may be prefetch problem, I don't know). And by maintenance overhead for 1st option you mean explicit handling in library source code? Isn't it the job for compiler/linker? Piotrek
Re: I came up with a new logo for the D language
On Monday, 13 April 2015 at 20:25:21 UTC, Barry Smith wrote: On Monday, 13 April 2015 at 18:56:45 UTC, Walter Bright wrote: On 4/13/2015 12:12 AM, deadalnix wrote: It does not matter if one knows this is planets or not (these aren't planet technically, but phobos and deimos, mars's moons). What does matter is that the logo is recognized and associated with D. Any logo change goes against that goal, so that's probably won't happen. I appreciate the effort going into making a new logo, and it's always fun to do it and talk about it, but I like the existing one better (and I agree that constantly changing the logo is tantamount to not having one, making it pointless). Well, I guess that's that then. The master has decided. I think it's better to create logos for community events (like the latest DConf logo). Just for the record the upcoming D Hackathon needs more marketing. It would be good to attract some people from the outside. Piotrek
Re: D Hackathon: April 25 - May 1
On Monday, 13 April 2015 at 20:37:02 UTC, Andrei Alexandrescu wrote: On 4/13/15 7:10 AM, Russel Winder via Digitalmars-d wrote: I can only make the D Hackathon 2015, on 2015-04-30 and 2015-05-01. I'd love to get stuck in on something. Probably best for me to find out the state of play (!) at 2015-04-30T06:00+01:00 and find out how/where to contribute then. Sounds great. See you on the barricades! -- Andrei BTW. What do you mean here: Walter and I will observe them and invite others to join us: Piotrek
Re: DConf schedule: share, discuss, vote!
On Monday, 23 March 2015 at 17:17:19 UTC, Andrei Alexandrescu wrote: Please help us spread the word on DConf 2015. We have a strong schedule this year. Share with your coworkers and friends. Talk to your manager about attending. Be there! https://www.facebook.com/dlang.org/posts/1037831199563894 https://www.reddit.com/r/programming/comments/3010w6/the_d_programming_language_conference_2015/ https://twitter.com/D_Programming/status/580048927178629120 Andrei The link to the schedule seems to be broken on Reddit http://dconf.org/2015/index.html?schedule should be http://dconf.org/2015/schedule/index.html Piotrek
Re: [Semi OT] The programming language wars
On Saturday, 21 March 2015 at 14:07:28 UTC, FG wrote: Now imagine the extra trouble if you mix languages. Also, how do you include meta-text control sequences in a message? By raising your voice or tilting your head when you say the magic words? Cf.: There was this famous quote QUOTE to be or not to be END QUOTE on page six END PARAGRAPH... Very awkward, if talking to oneself wasn't awkward already. Therefore I just cannot imagine voice being used anywhere where exact representation is required, especially in programming: Define M1 as a function that takes in two arguments. The state of the machine labelled ES and an integer number in range between two and six inclusive labelled X. The result of M1 is a boolean. M1 shall return true if and only if the ES member labelled squat THATS SQUAT WITH A T AT THE END is equal to zero modulo B. OH SHIT IT WAS NOT B BUT X. SCRATCH EVERYTHING. Just for fun. A visualization of the problem from 2007 (I doubt there was breakthrough meanwhile) https://www.youtube.com/watch?v=MzJ0CytAsec Piotrek
Re: A few notes on choosing between Go and D for a quick project
On Friday, 13 March 2015 at 17:11:06 UTC, Israel wrote: Well see the real problem is that D cant seem to cater to one group or another. It cant cater to new/inexperienced people because it isnt portrayed that way. I don't think D is a priori not suitable for rookies. It just needs more paint. Just show me what Go has what can't be simple in D :) It cant cater to the hardcore/DieHard C/C++ people because it is difficult to convince them. Or even impossible for some kind of personalities. C++ couldn't convince Linus to abandon C. Tell him about D then ;) I suggest to leave that type of people with their own toys. The better is going to win eventually. You need to pick a target audience and stick with it... Or create multipurpose tool. I think D is the best multipurpose tool in the programming languages business. Of course D community doesn't have enough resources to produces high quality products on all fronts. Number of resources is critical. D fights using its brilliance to overcome lack of resources. Go is on opposite position. Piotrek
Re: Standard GUI framework inspired by Qt
On Tuesday, 10 March 2015 at 01:25:05 UTC, karl wrote: Please don't use SDL2 and such as basis, or OpenGL with glBegin+glReadPixels without FBOs and PBOs (not Pbuffers). I'm a GL driver dev (userspace) for a smaller company, and I see too much gore in popular software like that (gnome3 is the most-horrific). A fully-featured GUI with GL needs only a thin wrapper for glXGetProcAddress, GL context creation, BitBlt-like things and font-glyph cache (or better yet, signed-distance-field text rendering). Something like this: Base (sans clipping, I haven't ported it from asm yet): https://github.com/idinev/pub_toys/tree/master/Blitters/oDraw SDF text: https://www.mapbox.com/blog/text-signed-distance-fields/ Also, GL should be optional, just like with Qt; it introduces noticeable lag of 16 to 48ms while being a resource hog unnecessary for most apps. I could help with implementing the abstraction layer and create a software blitter (I was professionally doing such stuff before, for GUI toolkits and stuff; but then again this stuff is trivial). A 32-bit backing-store is always vital (DDB+GDI dibsection, GL texture and such). Qt has it (and implemented really-well) and that's the first pixel-related thing we should implement. BGRA8 will be the best format (blue in LSB). A 9-cell blit will also be vital functionality. @karl Can you check the proposal of the new color module by Manu? https://github.com/D-Programming-Language/phobos/pull/2845 Do you see any issues there? Piotrek
Re: What Features Should A GUI toolkit have?
On Friday, 6 March 2015 at 06:30:45 UTC, Rikki Cattermole wrote: I'll summarize my views on all of this. We keep making the same damn mistakes time after time. Especially with GUI's. Stop trying to make GUI toolkits! Seriously just stop. WE DO NOT HAVE THE INFRASTRUCTURE FOR IT. Yes I know that is yelling but it is true. We're still a long way off having proper image manipulation. Or even basic OpenGL wrapping functions. DirectX don't even joke. Agree to some extent. But we can make small steps. At least if we figure out right architecture. TLDR: We think far too big and never actually work with a clear strategic path towards a goal in mind. Can you write briefly somewhere an analysis for gui development? Or possibly use add ideas/comments here: https://github.com/D-Programming-Language-Labs/Proposals/blob/master/proposals/1_std_gui.md I don't have too much time for gui as I'm currently in the process of including Phobos proposal modules into drafting library. Piotrek
Re: GSoC 2015 - Application Rejected
On Monday, 2 March 2015 at 19:08:49 UTC, CraigDillabaugh wrote: Unfortunately our organizational proposal for the 2015 Google Summer of Code was rejected. Thanks to everyone who helped out on this, especially to those who volunteered to mentor. I've asked Google to provide me with feedback, and I will post that here once/if I get something from them. If I am not asked to resign I am happy to volunteer for this post again next year. Hopefully I can learn something from this year and any feedback they provide. Cheers, Craig Respect for your uphill battle. I remember someone somewhere suggested to make our own summer of code (however I don't know how this would look like). As for a free money from corporations I'm skeptical in general. http://imgur.com/W5AMy0P Nevertheless, great job. Cheers Piotrek
Re: std.allocator ready for some abuse
On Friday, 27 February 2015 at 08:18:53 UTC, ANtlord wrote: I think, that if use this project https://github.com/andralex/std_allocator/, than you can post the issue to related issue tracker. Oh, I must be blind. I thought the issue tracker was disables on the repository in the same way as for Phobos. Thanks for checking. I submitted the issue. And I see, that types in traceback are different from source https://github.com/andralex/std_allocator/blob/master/source/std/allocator.d#L857. Maybe you need to upgrade package. If you mean size_t and uint difference it's because size_t is an alias for uint on 32-bit os. roundUpToMultipleOf(size_t s, uint base) becomes roundUpToMultipleOf (uint s, uint base) Piotrek
Re: std.allocator ready for some abuse
Hi, Sorry for putting it here but I don't know where to file a bug report for the allocator project. On 32-bit linux with the latest dmd beta I get errors for ulong - uint (size_t) conversions. dmd -main -unittest allocator.d allocator.d(2015): Error: cannot implicitly convert expression (i * 4096LU) of type ulong to uint allocator.d(2015): Error: cannot implicitly convert expression ((i + cast(ulong)blocks) * 4096LU) of type ulong to uint allocator.d(1743): Error: template instance std.allocator.HeapBlock!(4096u, 4u) cut the long line allocator.d(331):instantiated from here: HeapBlock!(4096u, 4u) allocator.d(334): Error: template instance Segregator! cut the long line allocator.d(2015): Error: cannot implicitly convert expression (i * 128LU) of type ulong to uint allocator.d(2015): Error: cannot implicitly convert expression ((i + cast(ulong)blocks) * 128LU) of type ulong to uint allocator.d(1743): Error: template instance std.allocator.HeapBlock!(128u, 4u) cut the long line , __ctmp2303).this(m)) error instantiating allocator.d(1342):instantiated from here: HeapBlock!(128u, 4u) allocator.d(1493): Error: cannot implicitly convert expression (x / 64LU) of type ulong to immutable(uint) allocator.d(1495): Error: cannot implicitly convert expression (y / 64LU) of type ulong to immutable(uint) allocator.d(1520): Error: cannot implicitly convert expression (x / 64LU) of type ulong to uint allocator.d(1526): Error: cannot implicitly convert expression (i) of type ulong to uint allocator.d(1527): Error: cannot implicitly convert expression (i) of type ulong to uint allocator.d(1544): Error: cannot implicitly convert expression (w) of type ulong to uint allocator.d(1553): Error: cannot implicitly convert expression (w) of type ulong to uint allocator.d(1572): Error: cannot implicitly convert expression (w) of type ulong to uint allocator.d(1582): Error: cannot implicitly convert expression (w) of type ulong to uint allocator.d(1607): Error: cannot implicitly convert expression (i) of type ulong to uint allocator.d(1615): Error: cannot implicitly convert expression (i) of type ulong to uint allocator.d(1627): Error: cannot implicitly convert expression (i) of type ulong to uint allocator.d(1633): Error: cannot implicitly convert expression (i) of type ulong to uint allocator.d(4143): Error: function std.allocator.roundUpToMultipleOf (uint s, uint base) is not callable using argument types (ulong, uint) Is it a known issue? Or are there currently only 64-bit OSes supported by the allocator project? Piotrek
Re: Will D have a standard cross platform GUI toolkit?
On Thursday, 26 February 2015 at 18:20:12 UTC, Rinzler wrote: Hello, I was wondering if D will have a standard cross platform GUI toolkit. I think that any modern language should provide a cross-platform GUI toolkit. I know that there are some GUI toolkits, but are there cross-platform? Are there serious works? That is, will them always be supported and evolve along with the D programming language? I think that having bindings of a GUI toolkit for a programming languages can be useful, but they have to be well supported. Will QT support D programming language? I really love the Qt framework (except from the fact it's not open source, as far as I know), even though I have not used it a lot. I have to admit that I love D, even if I did not start programming with it. It seems it combines the most useful things of C++ and Java, which are my favourite programming languages. Maybe there are other questions already in the forum, since I am new, I don't know, but a new question, more up to date, can also be useful. Thanks! Hi, There were several discussions about the std gui in the past. And the current state is not so bad. There are some big contributions in the gui domain. However the complexity of the topic is so hi that there is no *standard* gui for D for the time being. However I've been trying to start with the concept of DIP73 http://wiki.dlang.org/DIP73 (I'm the submitter and the only executor ;) with the hope that there is a chance. Currently I'm choosing some example ideas of new modules (including database and gui especially). Piotrek
The outcome of DIP73 discussion – D Programming Language Labs
Hi, Because there is no strong evidence that DIP73 would fly, I had to take some modification to initial plan. Firstly I needed a workaround for the blocking point (creating an official repository) on my implementation list. In result I created a satellite project at: https://github.com/D-Programming-Language-Labs The main goals remain sill the same: Speed up the development of standard modules by uniting majority of D developers Lower the commitment barrier and attract more contributors Provide out of the box and batteries included experience All with emphasis on collaborative work and being in line with the official D development. And I ask all of you to resolve the following two issues: 1. I presume that a part of the community don't want me to spam the main D development forum, so I have a question how to handle further discussion related to the idea? Can I temporary use some other unused forum (e.g. digitalmars.empire) to carry out the initial phase of the project? 2. What's the best choice for codename of the drafting library: - Mars - (I think Walter should comment if it's not reserved for the language itself) - Curiosity – I like it more (reference to the Mars Science Laboratory ) but I don't now what's the native English speakers perception of using the “curiosity” word in this context. - Other Piotrek
Re: New DIP73: D Drafting Library
On Thursday, 5 February 2015 at 06:56:52 UTC, Dicebot wrote: You have clearly put a lot of effort in this. That makes me very uneasy to repeat the same critique as earlier but, sadly, it still all applies. This proposal tries to fix problems it doesn't prove exist, doing so with solutions that are not guranteed to help. No need to be sorry. D needs quality guards. It also wrongly explains current process of inclusion into Phobos in general and specifically std.experimental - being probably one of more involved persons with Phobos review queue I feel like this needs to be explained. Considering all the discussion that happened during std.experimental.logger I understand that we have settled with pretty much this: 1) All Phobos proposals must go through std.experimental.logger When you say I put the current process wrongly, you mean there is no way to submit a new module avoiding a std.experimental namespace? Or something else? Can you provide a link to the latest official description? I will update the pictures. 2) It must implement something generally desired in Phobos Which is? 3) Implementation is supposed to be at least stable enough to not undergo a full rewrite after inclusion. Major API changes are acceptable. This point is one of the main problems the DIP tries to avoid. According to your statement the module should be almost complete before the pull request is accepted. I mean without any design flows. In many cases that is really hard to achieve for one developer (e.g gui). OTOH if you don't see the full implementation and can't test it you may not see the fundamental flows in design. Of course this may be doable for less complex modules. Then the current way of using std.experimental alone may be applicable. 4) Before DMD/Phobos release is made existing packages that feel stable can undergo a formal review for inclusion in Phobos main package With that in mind initial public review is supposed to only determine if (2) and (3) is true which is mostly a formality as people rarely propose modules they are not serious about. How could you be sure that after long lonely work the proposal is worth inclusion? As you may see requirements are very lax. Only real difference is that your poposal allows to accept modules that are not supposed to ever go to Phobos at all - which I am still convinced is a bad thing and belongs to code.dlang.org How do you know what modules should not be in Phobos? Is there any widely accepted list? Even C++ is getting more open minded. Speaking about objections vs code.dlang.org community driven development as opposed to individually driven (ownership/control of the source code) see no reason to expect this is actually better of makes any notable difference in general out of the box readiness dub is planned to be distributed with DMD wide range of community members involved in the development to reduce controversy and fragmentation staring from the initial stage no idea where this even comes from Maybe I'm wrong but there is a big controversy and fragmentation e.g. in database and gui domain. Pretty much all extra goodies from DIP73 can be implemented by creating special officially endorsed category in code.dlang.org and showing it as a default package list at code.dlang.org front page This may lead to competing packages. How would we decide what are the proper packages. There can be impossible to fully control the development by the whole community (yes I know I repeat myself). In general, there needs to be a good analysis backing the proposal to change anything - good intention and good idea alone are not enough. Fully agree. Of course I provided only ideas based on my personal experience and NG posts. Any hint what else I could do is welcome. It is better to do nothing than do something unless one is extremely sure that it will help. I guess there is always risk there. But I agree that we should be convinced about the progress beforehand. Piotrek
Re: New DIP73: D Drafting Library
On Thursday, 5 February 2015 at 22:25:28 UTC, Laeeth Isharc wrote: There is no contradiction between distributing the latest version of 'Mars' with DMD releases (including the library update tool) and having more frequent releases in between, if that is thought to be the right thing to do. Small frictions have large effects when starting something new, so if you want something to succeed you ought to make it as easy as possible to get started. I agree with both points. Even more with the letter. Piotrek
Re: New DIP73: D Drafting Library
On Thursday, 5 February 2015 at 23:04:03 UTC, Laeeth Isharc wrote: If it's worth inclusion in phobos, it will rise to the top. I admire idealists, but in the past few years how many independent projects have been adopted by phobos? Is it the case that none of those that were not are essentially at core unworthy of adoption, or is it that they need some polishing to be of more general use and doing so simply doesn't appeal to the library author, whilst others with the skills are less inclined to help on a private project? I don't know the answer, but obviously have a tentative assessment. Despite you mixed up many posts in the one answer I like most of you points. Since there is so much hidden gold in dub, I wonder if it makes sense to ask notable library authors how they might feel about adoption of parts of their work into Mars. What does Adam Ruppe think, for example? +1 Maybe I'm wrong but there is a big controversy and fragmentation e.g. in database and gui domain. So don't start with databases and guis. And at least down the line consider the possibility that there might not be just one option when the needs of the problem domains may be very different in spite of apparent superficial technical similarity. I mean I want to have a functionality in D like in Qt, i.e. gui for: -Windows -Linux -Android This would need a huge amount of work. I don't need it to be ready in the first release though. Also I don't mind to have it changing rapidly in the first stage of development. Moving things towards phobos won't help with fragmentation, will just piss those off who disagree. Better path is to put solutions in dub for people to use and abuse, see if one becomes dominant. Only then look at moving to phobos. If Mars doesn't accomplish its goals then people won't use it and all that will have happened is a little wasted effort - but one doesn't learn without experimentation, including in the social domain. It just hasn't happened that people mystically converge on a solution just because it is in dub, polish the code and write documentation for somebody else's code base - possibly because someone needs to lead the effort. The idea seems to be cheep in implementation (e.g. just creating the official project would be something) and can be reverted any time as it won't be any kind of dependency. This may lead to competing packages. How would we decide what are the proper packages. One might start with exploring what is already out there and seeing which authors are agreeable to having their work adopted. Making decisions isn't easy in life, and people are going to criticize you because not everyone will be happy with the outcome - but that isn't a reason not to do something if it is worth doing. +1 For me, the issue is high entry barrier for Phobos. OTOH I can imagine myself making pull requests for the drafting library. Not mentioning testing the progress. I like the idea of having a 'recommended' section in dub, for those things considered by the community to be good. This is a start, but doesn't address the problem that to be useful to a broad audience one needs much more than raw code and that the library author may not want to or be good at doing these other things. +1 http://wiki.dlang.org/DIP73#Comparison_to_code.dlang.org_packages Piotrek
Re: New DIP73: D Drafting Library
On Thursday, 5 February 2015 at 22:04:04 UTC, Jeremy Powers wrote: Snipped a bit, tl;dr is you should use dub. I use it but with no success in the matter of the proposal. How could you be sure that after long lonely work the proposal is worth inclusion? .. If it's worth inclusion in phobos, it will rise to the top. I actually don't know how to comment that in regards to the DIP. I don't recall dedicated protects for particular modules. Maybe I'm wrong but there is a big controversy and fragmentation e.g. in database and gui domain. Moving things towards phobos won't help with fragmentation, will just piss those off who disagree. Any example of existing Phobos modules (added recently)? I like the idea of having a 'recommended' section in dub, for those things considered by the community to be good. I don't think anything should even think about phobos inclusion (even on-path-to-inclusion) until it has been used and abused enough. I don't have nothing against. But IMO this won't solve the problem with standardization of functionality. From the perspective of usual user. We have this nice package system for non-phobos stuff, should leverage it. The functionality of dub is not related to the DIP. I tried to keep it as a separate topic. Piotrek
Re: New DIP73: D Drafting Library
On Wednesday, 4 February 2015 at 23:15:25 UTC, Jonathan Marler wrote: This looks very similar to std.experimental. In one way, yes, it is similar to std.experimental, but not that much as it seems. More precisely: 1. Take the namespace designed for new module drafting out of the Phobos 2. Put it in a separate library 3. Allow community common development from the beginning of the drafting stage 4. Propose Phobos inclusion when module is ready I originally thought that the difference between std.experimental and this library was going to be how it was used. std.experimental: module that may become part of the standard libary later your proposed library mars?: modules that will probably not become a part of the standard library. Just small clarification. Drafting library would include modules that are welcome to become a standard. The final decision about Phobos submission is made after standardization attempt failed, not before! They are addons to the standard library. i.e. Maybe you would like the SDL library, but it doesn't make sense to include in the standard library because it it not useful to everyone. For these kinds of libraries it would be nice to have a set of community supported libraries that shouldn't be in the standard library but are still useful to a subset of the community. The DIP is defined in the spirit of what you originally thought. 1. If you want SDL (literaly) then use code.dlang.org package 2. If you want SDL like functionality then propose a new draft module (including gui functionality) Piotrek
New DIP73: D Drafting Library
Hi, Abstract: D Drafting Library is an official library modeled by the D community and designed to support the development process of the D Standard Library. The drafting library is coupled with the standard library and doesn't introduce any duplicated functionality. It should be used during the drafting stage of the new functionality development. Link to the DIP: http://wiki.dlang.org/DIP73 and to the recent discussion for initial proposal: http://forum.dlang.org/post/rwavdkzmkqxpldveu...@forum.dlang.org Please comment, share your view and doubts. Don't hesitate to ask any question. I tried to define the proposal to be almost non-intrusive for not interested developers. I can handle point 3 and 4 from Proposal implementation steps section as a pull requests when proposal is accepted. Step 1 and 2 are trivial but can't be done by me as I'm not the person in charge. Piotrek
Re: Problem with creating a new account on wiki.dlang.org
On Wednesday, 4 February 2015 at 07:02:01 UTC, Zach the Mystic wrote: Vladimir fixed it. Yay! That was quick action. Thank you both Zach and Vladimir. Piotrek
Re: Mars Drafting Library - Official community driven library
On Tuesday, 3 February 2015 at 02:38:57 UTC, Zach the Mystic wrote: I'm arguing from the perspective that the approval must come first, and the piloting second. Who would want to develop a module in the pre-pilot phase, without having any idea of whether they were developing it finally for phobos or just 3rd-party use, then wait months or years to find out if the leadership is even *interested* in what they're doing? Why would people try to meet high standards without knowing if those standards are actually going to be required or not? It's like an unpaid internship: Work for us for free, and we'll let you know at the end whether we want your work or not. Al least the module will be available in draft namespace until controversy is resolved. I don't think there would be any blocking campaign without providing sane requirements to move on. BTW. I tried to publish the DIP but got into the following issue: http://forum.dlang.org/post/yoqwuqhtlpifgwude...@forum.dlang.org It looks the DIP will be delayed at least by day. Piotrek
Problem with creating a new account on wiki.dlang.org
Hi, I wanted to create my account at wiki.dlang.org: Went to: http://wiki.dlang.org/?title=Special:UserLoginreturnto=Wish+listtype=signup And got: No questions found; set some in LocalSettings.php using the format from QuestyCaptcha.php. Anyone familiar with the issue? Piotrek
Re: Mars Drafting Library - Official community driven library
On Monday, 2 February 2015 at 06:07:29 UTC, Zach the Mystic wrote: Therefore, I think std.experimental is for all in flux APIs, from the drafting stage to the later less in flux stages. Definitely this is what I thought initially. But, IMO, it can be really hard or impossible to carry out, as you pointed one of the issues in the following part: The danger is that the phobos management will want to have their cake and eat it too, as the saying goes. You simply can't promise users both stability and a perfectly designed API at the same time, tempting as it is. Hence the *proposal* of the drafting library. Piotrek
Re: Mars Drafting Library - Official community driven library
On Sunday, 1 February 2015 at 23:22:55 UTC, Dicebot wrote: Newbie confusion? In what way? What library to use between Phobos and Mars, why those are separate, why those have different stability guranatees, where to submit new contributions, why bother - it all would need to be written down and explained over and over again. And this alone is huge -. IMO, there is no more confusion than using std.experimental vs other modules. Drafting modules are for developing functionality not present in Phobos, but build upon Phobos foundation. I admit I don't understand where confusion may come from. I will pay more attention to it as you described it as a huge problem. Piotrek
Re: Mars Drafting Library - Official community driven library
On Sunday, 1 February 2015 at 23:21:36 UTC, Dicebot wrote: As per latest agreement everything in std.experimental is considered subject to any change so is perfectly flexible. - new drafting modules won't disturb usual users of the standard library That statements needs some hard data that current situation is disturbing to be considered as a rationale. If you put to many uncompleted modules in the std.experimental it can influence stable part of the Phobos. - binary size - pull request with more experimental stuff etc. IMO, std.experimental is not for the drafting stage of the SW development. Depends on your definition of draft. Anything that is good enough to be actually used in real app is good enough for std.experimental - and anything less is of no use to end user anyway. I agree that all is a matter of definition. I still doubt that fast evolving drafts would be possible in std namespace. 2) what would it give over code.dlang.org ? - community driven as opposed to individual driven - out of the box readiness - minimal fragmentation and controversy code.dlang.org is actually much more community driven because it is naturally decentralized. Controversy is inevitable anyway (hello std.json). I used the community driven in contrast to individually driven. The key property of the proposal is to minimize the controversy by community (common) drafting process. Fragmentation is a thing though - but I yet to be convinced that is a bad thing that needs to be fixed. I consider fragmentation a major problem for standards. 3) what problems are you trying to solve and why do you think this is suitable solution? Adding new modules (replacing the deprecated ones) in more robust and quicker manner. It is as quick as it can be for standard library - and code.dlang.org takes care of everything else. I have non-trivial modules in mind like gui, json, database, etc. Any library that risks quick removal of deprecated modules / API is not acceptable for standard stamp. The drafting lib is a proposition of standard not a standard itself. And I didn't said anything about removal. I was referring to: Warning: This module is considered out-dated and not up to Phobos' current standards. It will remain until we have a suitable replacement, but be aware that it will not remain long term. So far this does not seem a proposal that pulls own weight to me. I can put the burden on my shoulders. I'm in the middle of DIP creation. Unfortunately I have a regular job and other duties. Still, I hope to finish it as soon as promised. Piotrek
Re: Mars Drafting Library - Official community driven library
On Monday, 2 February 2015 at 21:19:01 UTC, Zach the Mystic wrote: I think std.experimental should essentially be its own library, with its own slot next to phobos on the github repo. I'm open to changing the name or something... but if we have both std.experimental *and* your new mars, what do you think is the real difference? How can std.experimental be sort of experimental, but really not, whereas mars is really actually experimental? Where is the cutoff line? How would anyone know whether they reached it or not? Hard to admit but I thought about removal of std.experimental ;), then I tried to find a better solution (not sure I did). After all I don't want to make more enemies than I have. So I got an idea that std.experimental can be adopted for the piloting new modules into Phobos when approved to be a standard. After Wikipedia: A pilot project refers to an initial roll-out of a system into production My attitude is that any given module in std.experimental should simply indicate its current level stability at the top of its documentation - full disclosure about where it is from, say, 0 to 95%, (with anything above that already assumed qualified for std proper). Yes, the drafting stage can have many sub-stages, but I didn't want to complicate the initial proposal too much and risk both low chance of the approval and later, inability of proper implementation. I learned that there can be taken only limited steps at once. I'd even make one more point, that all current phobos modules known to be in need of revamping be copied wholesale in their current forms to std.experimental, with the top documentation saying, This is the experimental version of the old std.xxx, which needs *your* help with its redesign and implementation. Feel free to break the current API by improving it. This is *not* currently considered a stable module. Haha, let's not lose our nerves :) It's not that bad. Moreover. I can barely find the equivalent level of code awesomeness as it is in D libraries. We just need to speed up the progress and reduce work fragmentation. Piotrek
Re: Mars Drafting Library - Official community driven library
On Saturday, 31 January 2015 at 20:47:43 UTC, ZombineDev wrote: I like the idea of having an additional library that we would ship alongside Phobos with every release. There of course some obvious pros and cons for having 'Mars' (or whatever is called) as a DUB packages vs included in the standard library: Thanks for comments:) I'm going to address most of them. Pros being included alongside Phobos: + Better testing because more people can/will use it + Potentially better code, because of code review during pull requests and generally high standards for new stuff (like with std.experimental.logger). + More stable, because people may care more for backwards comparability (though the points is that this will not be guaranteed). + People new to the language will feel more comfortable using 'standard' libraries. + etc... Cons: - Extremely slow release cycle. There can be nightly/weekly builds if really needed. But in general, yes, release cycle would be the same as DMD package. - Hard to get new stuff (controversial like GUI) in. The key aspect of the proposal it to have that kind of functionality go through a processes of eliminating controversy as much as possible during developing stage. - Not being able to have external dependencies than druntime and Phobos (like bindings for C libraries) - etc... Being a part of official packet it is actually advantage. As an opposite example I couldn't get curl module working under Ubuntu in sensible time. I think a good compromise would be the following: 1. Include DUB with DMD. We don't need a stable DUB as a library API to just use it to get other packages. 2. Make 'Mars' a DUB package and use semantic versioning to tag new releases. 3. Move it to github.com/D-Programming-Language/. 4. Include last known 'well working' with every DMD release. (Of course other implementations are free to decide whether to include it). Or we can have some post-installation script which would call DUB. 5. Afterwards if a new version of 'Mars' is released users can just do a 'dub upgrade' to update the one that's already included, or wait for a new official release. Another good idea is to separate Phobos from DMD and also put it on DUB. As you can see[2] many of the integral parts of.NET are provided as packages and people have no problem using them as such (you can see by the large download numbers). [1]: http://blogs.msdn.com/b/dotnet/p/nugetpackages.aspx [2]: https://www.nuget.org/packages This proposal's aim is to be the least intrusive so that kind of changes are out of the scope. DMD and Phobos are often coupled in terms of changes (bug fixes etc). I'm against moving standard library to DUB. Piotrek
Re: Mars Drafting Library - Official community driven library
On Saturday, 31 January 2015 at 20:55:11 UTC, Jonathan Marler wrote: On Saturday, 31 January 2015 at 14:06:20 UTC, Piotrek wrote: Hi, The history of std.(experimental.)logger and the latest thread about gui functionality inclusion into Phobos made me think about how to solve the problem of adding new modules. I came up with the idea (maybe not new) to create a additional library(along druntime and Phobos) delivered with dmd package and named Mars (Deimos is unfortunately already taken ). The library itself would be driven by community (not individual library developer) in order to be... the standard. The process would be something similar to that other committees use (e.g http://www.iec.ch/standardsdev/how/processes/development/) where before the standard is approved it goes through a draft stage. Still a draft can be used to create a working product (e.g. some Wi-Fi solutions based on IEEE 802.11 drafts) Possible initial prerequisites: - User awareness about the usage consequences - Library placed at https://github.com/D-Programming-Language/ - Only well recognized community members have pull rights - design decision made on the best known sw engineering patterns used in D - New module should be functional with D/Phobos standards applied - API and implementation allowed to change any time in order to make a progress - no external dependencies beside OS services - draft as the root module name e.g. module draft.gui Advantages: - community driven process which ensures the lowest level of controversy - fast path for modules like GUI to be standardized Disadvantages: - additional effort for the sw release process Ready to be destroyed ;) Piotrek I approve :) +1 Thanks for your vote. If there is no official veto to the proposal, I will create a DIP in a day or two. Meanwhile, we can still discuss unclear or problematic issues. Piotrek
Re: Mars Drafting Library - Official community driven library
On Sunday, 1 February 2015 at 14:40:17 UTC, Zach the Mystic wrote: The intention of creating draft modules would be the inclusion in Phobos. In simplistic way, the following stages of development will be applied: 1. Proposal (DIP, NG discussion, DUB package showcase, local meet-up events etc) 2. Draft module creation and development 3 Approval for Phobos merge, i.e. draft - std I really can't see the difference between `std.experimental` and this. If `std.experimental` doesn't get used for this, `std.experimental` will end up a marginalized experiment itself. I think `std.experimental` runs the huge risk of not being recognized as what it is - i.e. a shop for building things (from scratch if necessary, IMO). If you're not worried about the name Mars, why are you worried about `std.experimental`? I initially thought about the std.experimental, but came up to the conclusion that when modules are in drafting stage they shouldn't pollute the Phobos. Basically because the final standard is not defined. A simple distinction can be seen as follows: draft - drafting std.experimental - piloting The Drafting library can be omitted during DMD installation without any harm for Druntime and Phobos. I briefly read the article and some parts are similar. However the difference is that Curiosity/Mars would form some kind of trinity with Druntime and Phobos. See also my answer to weaselcat's post (http://forum.dlang.org/post/mtqjtavxzjucixuyc...@forum.dlang.org). Piotrek Yes, we're basically talking about the two categories I mentioned to begin with. You're focusing on those libraries which can be pre-approved as worthy of phobos. The way I figure it, only Andrei and Walter can ultimately give pre-approval for such libraries. I don't treat Walter and Andrei as a blocking point. I think they will do anything is good for the language. Many time the D community initiated successful campaigns seconded by the key designers. But I think the second kind I mentioned -- high-quality libraries which aren't suited for phobos -- also need official, or at least prominent, recognition. It's really important for people not to have to investigate every program listed on code.lang.org in order to find high-quality existing code. I would even argue that such recognition is more important than the library you're proposing here (which already seems to exist with `std.experimental`). I truly agree that there are many valuable DUB packages needing the advertisement. However this is out of the scope of the proposal. Piotrek
Re: Mars Drafting Library - Official community driven library
On Sunday, 1 February 2015 at 21:54:13 UTC, Dicebot wrote: Just few quick questions: Hi 1) what would it give over std.experimental ? - draft modules will be more flexible for changes than in the ones in standard library - new drafting modules won't disturb usual users of the standard library IMO, std.experimental is not for the drafting stage of the SW development. 2) what would it give over code.dlang.org ? - community driven as opposed to individual driven - out of the box readiness - minimal fragmentation and controversy 3) what problems are you trying to solve and why do you think this is suitable solution? Adding new modules (replacing the deprecated ones) in more robust and quicker manner. IMO, this is a change in the direction how standards are made. Piotrek
Re: Mars Drafting Library - Official community driven library
On Sunday, 1 February 2015 at 09:28:42 UTC, HaraldZealot wrote: Approximately a half year ago I have similar idea and suggestion. Thanks for your input. Yes, there are similarities, but there are also some differences. See some of my comments below: This is my idea: * make new feature in dub, that it can place some libraries in common namespace. For example CyberShadow's ae will be placed in something like advancex.image, or logger (lucky it is in std.experimental already, but as alternative history) is placed in stdx.logger. But they are not part of phobos in that time but usual dub package on dub registry. * create namespaces advance (or any other) for useful but not so common components (e.g. proposal windowing, image processing an so on), bind for Deimos. Phobos is std already :). And also create their experimental counterpart like advancex, bindx and stdx. (It can be other name but I prefer one worded stdx than two worded std.experimental in other level of hierarchy). This differ from the Drafting Library proposal in the following points: - modules/packages are owned/driven by one developer - dub packages are not inclined to work out of the box with dmd release package * make new feature in dub and dub register that counts download, likes and bugs. When some package receives essential feedback it can be started pull request process. By the pull request process you mean inclusion in Phobos? Then, in result, wouldn't it just mean: make the most popular dub package in some category a standard? For now I drive two interesting project, but I also try to find forces for this one. The important thing about the proposal is to provide a process so one can be a part in creating the standard. You could contribute to drafts for the modules related to areas of your expertise. Piotrek
