Re: dub projects generate docs and host on code.dlang.org?
On Monday, 4 September 2017 at 10:47:47 UTC, Manu wrote: Suggest; code.dlang.org should attempt to generate ddoc for each hosted project, host it, and clearly link to it from the project front-page. Hosted docs should be styled consistently (matching phobos?). Thoughts? - Manu It would be nice if the DUB will be able to generate "docsets" for offline documentation browsers: https://kapeli.com/dash (can be integrated into various IDEs!) https://zealdocs.org/ http://devdocs.io/
Online documentation generator for D projects?
Hi! Why know site what can be hooked to a github project and (re)generate documentation after commit pushing? For tiny projects it seems to be cool to put a link to this site into README.md and don't worry about documentation page.
Re: What about std.lockfree ?
"falls"? I mean fails, of course :-) sorry for my English
What about std.lockfree ?
Anyone interested in std.lockfree - lock-free lists, FIFOs, stacks etc? I spent a few days doing implementations of procs, but has not reached any success. My plan: For many of lock-free algorithms it is need a function MCAS (multiple compare-and-swap) also called CASN (cas for n elements). In fact, it is looks very easy to maintain a doubly-linked lists or a trees or graphs if you can at the same time to change (or not change) all links of one or more of its elements. (But do not forget about ABA problem.) But: 0. MCAS/CASN and RDCSS algorithms at first seem looks like brain damaging mocking puzzles 1. It is forbidden to use unproven algorithms - otherwise there is a risk that the algorithm will falls sometimes and find them will be difficult. This simplifies matters: just copy and paste ready procs from articles! 2 Almost everywhere in these algorithms need a function CAS1 - proposed function core.atomic: casw (http://d.puremagic.com/issues/show_bug.cgi?id=8831#c4) - on casw basis CAS1 can be implemented easily (line 136: https://github.com/denizzzka/casn/blob/75b0377aaa1424f3bd3fa3d47eddf4b5fd4e8038/casn.d) 3. I could not run a well-known algorithm RDCSS: it falls on line 198 (Complete() function): if(isDescriptor(r)) Complete(r); I am understand why it falls - at the time of call Complete(r) pointer r can point to garbage because descriptor can be already removed by another thread. But I do not understand why this algorithm works in other places. RDCSS described in a article "A Practical Multi-Word Compare-and-Swap Operation", explanation also can be found here: http://cstheory.stackexchange.com/questions/7083/a-practical-multi-word-compare-and-swap-operation But it does not matter, because RDCSS algorithm has one major flaw - it uses two least significant bits as flags (perhaps the number of flags can be reduced to one) that indicate the type of information transmitted. It is bad dirty hack and, as a result, RDCSS can be used only for the exchange of pointers to aligned data, which is not always acceptable. It is available another procedure called GCAS. (http://lampwww.epfl.ch/~prokopec/ctries-snapshot.pdf) This procedure has semantics similar to that of the RDCSS. But I have not examined closely. I have plan to try it later. This all is a very complex, right? Someone else interested on it? You see here the error in reasoning? Can someone help or has finished implementation of these algorithms? It would be great if std.lockfree will be created, because it will reveal many benefits of D associated with shared variables. As I know Java and C# already have this.
Re: What about std.lockfree ?
(RDCSS is a part of MCAS)
Re: D interface for C library problems
On Monday, 15 October 2012 at 11:37:22 UTC, Oleg wrote: I got error: In function `gpgme_error_from_syserror': src/main.d:(.text.gpgme_error_from_syserror+0x5): undefined reference to `gpgme_err_code_from_syserror' --- errorlevel 1 collect2: ld returned 1 exit status Anyone knows how to fix this? Thanks and sorry for my English. I think you missed a library with err codes and functions. You should used -L compiler flag or pragma(lib, "nameoflib");
Re: Feature request: enum init shouldn't create a new enumeration
On Saturday, 13 October 2012 at 15:39:24 UTC, Tommi wrote:
enum MyEnum
{
init = -123,
first = 0,
second = 1
}
void main()
{
static assert(MyEnum.min == -123);
MyEnum me;
final switch (me)
{
case MyEnum.first: break;
case MyEnum.second: break;
case MyEnum.init: // I'm forced to specify init case too
}
}
Also, a quick question:
Why in case its need to write name of the enum?
case first: break;
case second: break;
case init: // I'm forced to specify init case too
looks better for me.
Re: immutable method not callable using argument types () - doesn't make sense
On Tuesday, 27 March 2012 at 12:57:18 UTC, bearophile wrote: Steven Schveighoffer: So what the compiler is saying is that you can't call dup with arguments (), you must call it with arguments '() immutable', meaning you must call it on an immutable B, not a mutable B. Any space for compiler error message improvements here? +1, spent two hours with a similar problem
Re: SQL working [ was Re: The sorry state of the D stack? ]
On Monday, 8 October 2012 at 07:35:13 UTC, Paulo Pinto wrote: On Sunday, 7 October 2012 at 20:05:22 UTC, denizzzka wrote: On Sunday, 7 October 2012 at 17:06:31 UTC, Joseph Rushton Wakeling wrote: On 10/07/2012 10:55 AM, Russel Winder wrote: Why only PostgreSQL. Shouldn't it also work with MySQL, Oracle, DB2, PervasiveSQL, SQLite3, etc.? I don't have sufficient experience with SQL to be able to really make a judgement here, but is there a case for a std.sql or std.db that would provide a uniform D interface to the arbitrary DB of choice? Each database engine has a unique distinguishing features that make this engine interesting. (for example, different implementations of transactions - SQL standard does not describe the SQL transactions precisely enough) There are plenty of existing interfaces to base D's design on, just a few of them: Perl - DBI Python - DB API C, C++ - ODBC (there is an UNIX variant of it) C++ - OLE DB (Although Windows specific) Java - JDBC .NET - Data Providers Ruby - DBI TCL - TDBC Go - database package Delphi - Data Access Haskell - HaskellDB (HDBC) So, I do not know is it possible to make a universal interface. And why it may need in real life? At least in the enterprise world, we tend to write applications in a DB independent way. One reason is to be able to deploy the applications without forcing the customers to invest in new DB engines, thus reaching a broader client base. Sometimes inside the same organization different business units have different DB engines running (even different versions of the same DB). Finally, to minimize costs when management decides for whatever reason, to change the DB licenses being used. -- Paulo For this to work you need to implement an independent way to create queries that would work on all database engines the same way. I believe that this problem is in principle much more complicated than it would have been implemented interfaces to databases in separate libs.
Re: The sorry state of the D stack?
On Sunday, 7 October 2012 at 08:05:10 UTC, Thomas Koch wrote: denizzzka wrote: https://github.com/denizzzka/dpq2 Thank you very much. I think I haven't seen this project. Would you like to add it to this wiki page? http://www.prowiki.org/wiki4d/wiki.cgi?DatabaseBindings#PostgreSQL I could not register there. :( Who have the opportunity, please add https://github.com/denizzzka/dpq2 to this wiki. Thank you!
Re: SQL working [ was Re: The sorry state of the D stack? ]
On Sunday, 7 October 2012 at 17:06:31 UTC, Joseph Rushton Wakeling wrote: On 10/07/2012 10:55 AM, Russel Winder wrote: Why only PostgreSQL. Shouldn't it also work with MySQL, Oracle, DB2, PervasiveSQL, SQLite3, etc.? I don't have sufficient experience with SQL to be able to really make a judgement here, but is there a case for a std.sql or std.db that would provide a uniform D interface to the arbitrary DB of choice? Each database engine has a unique distinguishing features that make this engine interesting. (for example, different implementations of transactions - SQL standard does not describe the SQL transactions precisely enough) So, I do not know is it possible to make a universal interface. And why it may need in real life?
Re: The sorry state of the D stack?
On Saturday, 6 October 2012 at 12:06:07 UTC, Thomas Koch wrote: - I looked for a PostgreSQL client library. I found small personal hacks and dead projects. https://github.com/denizzzka/dpq2 This is my personal project but it is not dead, and I am determined to see it through. At the moment, it is quite suitable to be used in simple situations. Compiles without warnings by dmd 2.060, also it can be used with rdmd. I really need users, comments, suggestions, bug reports and commits.
