Re: Start of dmd 2.064 beta program
On Saturday, 12 October 2013 at 22:16:13 UTC, Walter Bright wrote: http://ftp.digitalmars.com/dmd2beta.zip Current list of regressions: http://d.puremagic.com/issues/buglist.cgi?query_format=advancedbug_severity=regressionbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENED This isn't a release candidate, in particular the documentation needs work, but we need to shake the tree for any undetected regressions. Further beta announcements go in the dmd-beta mailing list. Note that this release contains: 29 enhancements 307 dmd bugs fixed 14 druntime bugs fixed 73 phobos bugs fixed I want to thank you and also especially Kenji who has been crazy fast at fixing the regressions I have encoutered. Now everything work, and several bug I was hitting in 2.063 are fixed. Good job !
Re: Start of dmd 2.064 beta program
On 2013-10-15 07:16, deadalnix wrote: This is for that very reason that I prefers to work with timestamps UTC as much as possible. No timzone hell, no format hell, no nothing. Just convert from user input directly, and convert back to text just before output. Agree. Always work with universal standards internally in your applications. Be it time, date, encodings or whatever. Then convert to and from local formats, as early as possible on input and as late as possible for output. -- /Jacob Carlborg
Re: Start of dmd 2.064 beta program
On Mon, 14 Oct 2013 23:13:25 +0200 monarch_dodra monarchdo...@gmail.com wrote: On Monday, 14 October 2013 at 13:25:23 UTC, Benjamin Thaut wrote: I'm also getting random missing symbol linker errors with both dmd 2.063.2 and dmd 2.064. But only on 32-bit windows. On 64-bit windows it works fine. This is really frustrating... I've encountered this too. I'll try to reduce, but the test case isn't easy. I've been bit by a similar (same?) issue. What I didn't realize is that DMD *doesn't* pass the LIB directories (from sc.ini) into optlink. Optlink *itself* reads sc.ini. So if the optlink being run isn't in the same directory as dmd.exe, then optlink may end up grabbing the wrong sc.ini and therefore the wrong Phobos as well. Hence, weird linker errors for Win32. Relevant issue: http://d.puremagic.com/issues/show_bug.cgi?id=10729
Re: Start of dmd 2.064 beta program
On 2013-10-13 00:16, Walter Bright wrote: http://ftp.digitalmars.com/dmd2beta.zip Current list of regressions: Another one: http://d.puremagic.com/issues/show_bug.cgi?id=11268 -- /Jacob Carlborg
Re: Start of dmd 2.064 beta program
Am 14.10.2013 23:19, schrieb Walter Bright: On 10/14/2013 6:25 AM, Benjamin Thaut wrote: I'm also getting random missing symbol linker errors with both dmd 2.063.2 and dmd 2.064. But only on 32-bit windows. On 64-bit windows it works fine. This is really frustrating... Is it possible you are linking together code compiled with different command line -version or -debug switches? I dind't change anything on the build setup. And it worked with dmd 2.062. Is there now different mangeling depending on the -version and -debug statements?
Re: Start of dmd 2.064 beta program
On 10/15/2013 1:50 AM, Benjamin Thaut wrote: Am 14.10.2013 23:19, schrieb Walter Bright: On 10/14/2013 6:25 AM, Benjamin Thaut wrote: I'm also getting random missing symbol linker errors with both dmd 2.063.2 and dmd 2.064. But only on 32-bit windows. On 64-bit windows it works fine. This is really frustrating... Is it possible you are linking together code compiled with different command line -version or -debug switches? I dind't change anything on the build setup. And it worked with dmd 2.062. Is there now different mangeling depending on the -version and -debug statements? dmd now assumes that templates instantiated by a library module are actually in the library. But if code is turned on and off with -version or -debug command line switches, and different switches are used to compile the library than the importer, then the templates instantiations may not be in the library.
Re: Start of dmd 2.064 beta program
Am 15.10.2013 11:25, schrieb Walter Bright: On 10/15/2013 1:50 AM, Benjamin Thaut wrote: Am 14.10.2013 23:19, schrieb Walter Bright: On 10/14/2013 6:25 AM, Benjamin Thaut wrote: I'm also getting random missing symbol linker errors with both dmd 2.063.2 and dmd 2.064. But only on 32-bit windows. On 64-bit windows it works fine. This is really frustrating... Is it possible you are linking together code compiled with different command line -version or -debug switches? I dind't change anything on the build setup. And it worked with dmd 2.062. Is there now different mangeling depending on the -version and -debug statements? dmd now assumes that templates instantiated by a library module are actually in the library. But if code is turned on and off with -version or -debug command line switches, and different switches are used to compile the library than the importer, then the templates instantiations may not be in the library. The funny thing is, its not a template. Nothing fancy at all. Just a struct with two members. And the linker complains that the __init member of that struct is missing. Error 42: Symbol Undefined _D6thBase6plugin8ScanPair6__initZ Also the library and importer are compiled with exactly the same -debug and -version switches. I did setup a dustmite reduce process but its going to take a few hours for that to complete. Kind Regards Benjamin Thaut
Funny coverage of the recent reddit/hackernews chatter
http://www.fastcolabs.com/3019948/more-about-d-language-and-why-facebook-is-experimenting-with-it Andrei
LDC 0.12.0 beta 1 released, please help test!
As always, please see the announcement over at digitalmars.D.ldc for more information and the download links: http://forum.dlang.org/post/mailman.2211.1381859316.1719.digitalmars-d-...@puremagic.com Cheers, David
Re: Funny coverage of the recent reddit/hackernews chatter
On Tuesday, 15 October 2013 at 17:47:54 UTC, Andrei Alexandrescu wrote: http://www.fastcolabs.com/3019948/more-about-d-language-and-why-facebook-is-experimenting-with-it Andrei Google shows a rise in interest as well: http://www.google.com/trends/explore?q=d+language#q=d%20languagecmpt=q
Re: Funny coverage of the recent reddit/hackernews chatter
On 10/15/2013 10:48 AM, Andrei Alexandrescu wrote: http://www.fastcolabs.com/3019948/more-about-d-language-and-why-facebook-is-experimenting-with-it geeky optimism (!) And a companion article: http://www.fastcolabs.com/3019887/facebook-adds-5000-lines-of-d-language-code-whats-that-mean
Re: Funny coverage of the recent reddit/hackernews chatter
On Tuesday, 15 October 2013 at 17:59:38 UTC, Tourist wrote: On Tuesday, 15 October 2013 at 17:47:54 UTC, Andrei Alexandrescu wrote: http://www.fastcolabs.com/3019948/more-about-d-language-and-why-facebook-is-experimenting-with-it Andrei Google shows a rise in interest as well: http://www.google.com/trends/explore?q=d+language#q=d%20languagecmpt=q A steady stream of news which hits Reddit and Hacker News front pages every few days certainly helps. We had the Facebook announcement and my tutorial. Who is responsible for tomorrow? ;)
Re: Funny coverage of the recent reddit/hackernews chatter
On 15 October 2013 18:59, Tourist grava...@gravatar.com wrote: On Tuesday, 15 October 2013 at 17:47:54 UTC, Andrei Alexandrescu wrote: http://www.fastcolabs.com/3019948/more-about-d-language-and-why-facebook-is-experimenting-with-it Andrei Google shows a rise in interest as well: http://www.google.com/trends/explore?q=d+language#q=d%20languagecmpt=q Google shows a rise of interest... from Nigeria. -- Iain Buclaw *(p e ? p++ : p) = (c 0x0f) + '0';
Re: Funny coverage of the recent reddit/hackernews chatter
On 10/15/13 2:08 PM, qznc wrote: On Tuesday, 15 October 2013 at 17:59:38 UTC, Tourist wrote: On Tuesday, 15 October 2013 at 17:47:54 UTC, Andrei Alexandrescu wrote: http://www.fastcolabs.com/3019948/more-about-d-language-and-why-facebook-is-experimenting-with-it Andrei Google shows a rise in interest as well: http://www.google.com/trends/explore?q=d+language#q=d%20languagecmpt=q A steady stream of news which hits Reddit and Hacker News front pages every few days certainly helps. We had the Facebook announcement and my tutorial. Who is responsible for tomorrow? ;) Oh, could you please make a pull request to add a link to the tutorial on the front page? Probably right under Documentation before Book. And, Ali, Ali, Ali, when's your book going to be ready? Andrei
Re: Funny coverage of the recent reddit/hackernews chatter
On 10/15/13 2:08 PM, qznc wrote: On Tuesday, 15 October 2013 at 17:59:38 UTC, Tourist wrote: On Tuesday, 15 October 2013 at 17:47:54 UTC, Andrei Alexandrescu wrote: http://www.fastcolabs.com/3019948/more-about-d-language-and-why-facebook-is-experimenting-with-it Andrei Google shows a rise in interest as well: http://www.google.com/trends/explore?q=d+language#q=d%20languagecmpt=q A steady stream of news which hits Reddit and Hacker News front pages every few days certainly helps. We had the Facebook announcement and my tutorial. Who is responsible for tomorrow? ;) Thanks again for the tutorial. People love it and the timing couldn't be better! Andrei
Re: Funny coverage of the recent reddit/hackernews chatter
On Tuesday, 15 October 2013 at 21:17:15 UTC, Andrei Alexandrescu wrote: On 10/15/13 2:08 PM, qznc wrote: On Tuesday, 15 October 2013 at 17:59:38 UTC, Tourist wrote: On Tuesday, 15 October 2013 at 17:47:54 UTC, Andrei Alexandrescu wrote: http://www.fastcolabs.com/3019948/more-about-d-language-and-why-facebook-is-experimenting-with-it Andrei Google shows a rise in interest as well: http://www.google.com/trends/explore?q=d+language#q=d%20languagecmpt=q A steady stream of news which hits Reddit and Hacker News front pages every few days certainly helps. We had the Facebook announcement and my tutorial. Who is responsible for tomorrow? ;) Thanks again for the tutorial. People love it and the timing couldn't be better! Andrei Can't wait for the blog post on Facebook Engineering. Any hints? :)
Re: Funny coverage of the recent reddit/hackernews chatter
On Tuesday, 15 October 2013 at 21:18:27 UTC, Andrei Alexandrescu wrote: Oh, could you please make a pull request to add a link to the tutorial on the front page? Probably right under Documentation before Book. Requested a pull. Further discussion over there: https://github.com/D-Programming-Language/dlang.org/pull/394
Re: Funny coverage of the recent reddit/hackernews chatter
On Tuesday, 15 October 2013 at 17:59:38 UTC, Tourist wrote: On Tuesday, 15 October 2013 at 17:47:54 UTC, Andrei Alexandrescu wrote: http://www.fastcolabs.com/3019948/more-about-d-language-and-why-facebook-is-experimenting-with-it Andrei Google shows a rise in interest as well: http://www.google.com/trends/explore?q=d+language#q=d%20languagecmpt=q And the dlang search: http://www.google.com/trends/explore?q=d+language#q=dlangcmpt=q Great article!
Re: Funny coverage of the recent reddit/hackernews chatter
On 10/15/2013 02:18 PM, Andrei Alexandrescu wrote: And, Ali, Ali, Ali, when's your book going to be ready? I am guessing another two months. (I have valid excuses. :-/) Ali
Re: Start of dmd 2.064 beta program
On 10/15/13 7:15 PM, Andrej Mitrovic wrote: On 10/13/13, Tourist grava...@gravatar.com wrote: I'm wondering whether there will be the nifty changelog like it was for 2.063? Andrej? :D We'll see if someone else volunteers to do it. I'm not doing it out of protest. What are you protesting against? Andrei
Re: Help needed testing automatic win64 configuration
On Tuesday, 15 October 2013 at 05:48:07 UTC, evilrat wrote: On Tuesday, 15 October 2013 at 05:31:51 UTC, Brad Anderson wrote: On Tuesday, 15 October 2013 at 05:07:19 UTC, evilrat wrote: On Tuesday, 15 October 2013 at 04:42:27 UTC, Brad Anderson wrote: This version should fix that. http://gnuk.net/dmd-2.064-beta-new-sc.ini-2.exe ugh, no now it messed up lib and linker path in sc.ini, lib path was correct, only linker wrong, swap them. I don't know what to make of mspdb11.dll. Anyone have any advice? i guess this is due running it without visual studio command prompt, but this can be fixed either by running it or utility script at VC/bin/x86_amd64/vcvarsx86_amd64.bat from console before using dmd. What's the path to mspdb11.dll? Microsoft Visual Studio 11.0\Common7\IDE\mspdb110.dll but don't add it manually, it should be added with VS prompt or that cvars script. I'm at a loss for how I would anyway. My only option might be to add execution of vcvars to the D2 Command Prompt shortcut I make. I'm going to sleep on this and think about it some more.
Re: Help needed testing automatic win64 configuration
VS 2010 Express/Windows SDK 7.0: dmd -m64 hello.d Can't run 'c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\amd64\link.exe', check PATH with dmd-2.064-beta-new-sc.ini-2.exe
Re: Help needed testing automatic win64 configuration
On Tuesday, 15 October 2013 at 06:24:28 UTC, Brad Anderson wrote: I'm at a loss for how I would anyway. My only option might be to add execution of vcvars to the D2 Command Prompt shortcut I make. I'm going to sleep on this and think about it some more. ah ok, i've never used dmd prompt myself anyway, so i would prefer if there will be script at dmd path which calls that cvars, because i really only use win+r cmd, with or without dub, or visuald.
Re: dmd 2.063 generated code a lot slower then dmd 2.062
On Mon, 14 Oct 2013 16:19:23 +0200 Andrej Mitrovic andrej.mitrov...@gmail.com wrote: On 10/14/13, Nick Sabalausky seewebsitetocontac...@semitwist.com wrote: And any sane editor There's your problem right there. I'd say a sane diff view would make it obvious that CRLF or tabs were injected, and yet github's diff view is a piece of ass. Github's entire web frontend is horrible. They don't even know how to write a freaking web page: http://semitwist.com/articles/article/view/making-a-link-or-what-the-fuck-is-wrong-with-github-s-developers (BUt really, I'm not sure there's an ajaxy site in the world that isn't garbage. Ex: http://forum.dlang.org/post/mailman.1442.1379388733.1719.digitalmar...@puremagic.com ie For reference, that's considerably less than the chrome process that hosts gmail (200mb!))
Re: Help needed testing automatic win64 configuration
On Tuesday, 15 October 2013 at 06:37:52 UTC, evilrat wrote: On Tuesday, 15 October 2013 at 06:24:28 UTC, Brad Anderson wrote: I'm at a loss for how I would anyway. My only option might be to add execution of vcvars to the D2 Command Prompt shortcut I make. I'm going to sleep on this and think about it some more. ah ok, i've never used dmd prompt myself anyway, so i would prefer if there will be script at dmd path which calls that cvars, because i really only use win+r cmd, with or without dub, or visuald. Looks like I can probably just stick a: PATH=%PATH%;%VCINSTALLDIR%\bin\x86_amd64;%VCINSTALLDIR%\..\Common7\IDE in there according to an sc.ini Rainer posted. I'll check this all out tomorrow.
Re: draft proposal for ref counting in D
On 14.10.2013 21:42, Michel Fortin wrote: Indeed. The current garbage collector makes it easy to have shared pointers to shared objects. But the GC can also interrupt real-time threads for an unpredictable duration, how do you cope with that in a real-time thread? The work I was talking about uses C++, not D, so there is no GC involved. The options I see for real-time threads in D is either a concurrent GC (which means read/write barriers for pointer accesses) or just excluding the real time thread from suspension by the GC. This forces the programmer to ensure that references in the real time thread are also found elsewhere. I'm not sure if this eliminates the benefits regarding locking, though. I know ARC isn't the ideal solution for all use cases. But neither is the GC, especially for real-time applications. So, which one would you recommend for a project having a real-time audio thread? ARC doesn't work for real time threads anyway, because you are not allowed to deallocate if it can cause locks. It can only work if you defer reference counting into another thread through some buffering. Realistically I would currently recommend the approach above: exclude the thread from suspension, and keep a reference to used object elsewhere. This is probably about as difficult as avoiding allocations/deallocations in C++, but harder to debug.
Re: Early review of std.logger
On 2013-10-14 23:22, Dicebot wrote: If we need to care about that, D module system is a failure. But I don't think it is a valid concern. People already complain about conflict function names in Phobos. -- /Jacob Carlborg
Re: draft proposal for ref counting in D
On 2013-10-15 05:11, Michel Fortin wrote: mprotect isn't available at all with the iOS SDK. So making this collector work on iOS (and the iOS Simulator) would require a different codegen. I haven't tried compiling anything and I don't know if I'm looking in the correct file but this file: /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.0.sdk/usr/include/sys/mman.h Does contain mprotect. -- /Jacob Carlborg
Re: Early review of std.logger
Am 15.10.2013 09:08, schrieb Jacob Carlborg: On 2013-10-14 23:22, Dicebot wrote: If we need to care about that, D module system is a failure. But I don't think it is a valid concern. People already complain about conflict function names in Phobos. And I'd agree with them. At least inside of a library, care IMO should be taken to minimize overlap (of course functionally equivalent ones in different overload sets are fine, though). But in case of logXXX this seems to be very unlikely, much in contrast to log (std.math.log).
Re: Early review of std.logger
Am 14.10.2013 20:24, schrieb Robert Schadek: On 10/14/2013 04:44 PM, Sönke Ludwig wrote: Am 14.10.2013 15:12, schrieb Robert Schadek: On 10/14/2013 02:39 PM, Sönke Ludwig wrote: - The static methods in LogManager should be made global and the class be removed. It's not for objects so it shouldn't be a class. LogManager also stores the global log level. Sure I can make another static global function storing this log level, but I would like to keep them together as they belong together IMO. The same could be said about the global log functions, which are tightly coupled to that state. I think this is already nicely grouped together by the logger module itself, since there is not much else in it. Basically, I just wouldn't consider this style to be particularly idiomatic D code, but of course that's just personal perception/preference (there is also some precedence using struct instead of class in Druntime). However, if it ends up like this in the final version, it should get a @disable this(); to prevent misuse. It is for ment for phobos not druntime. Anyway structs would mean all templates and people will scream template bloat. And this would break the design, which I find to be a valid use of classes and polymorphisms. The StdIOLogger can have its default constructor called IMO. No no, I was talking about the JobManager, not the Logger classes. No templates involved. - For me this logger is completely worthless without any debug log levels. The last std.log entry had at least anonymous verbosity levels, but I'd prefer something like I did in vibe.d [1], where each level has a defined role. This should especially improve the situation when multiple libraries are involved. Logger.log(LogLevel.(d|D)ebug, Your message); That would be my idea. Having at least two (diagnostic output for the user and debug output for the developer), but better all four debug levels can be very useful, though. Maybe I miscommunicated what I want to show by that example. The (d|D) part is the rename to enum lower case. The debug log level is given through the LogLevel.Debug, which will be renamed to LogLevel.debug. I would call the developer the user of the logger. Maybe log messages can be communicated to the user of the applicaiton and the developer of the application through a MultiLogger class. But the statement of mine that you quoted was about debug levels (the case issue is clear)... Also right now there is no (D|d)ebug level, so I'm actually not sure about the statement that you want to make. But my example of having different levels for the application user and the developer is mostly important when the application user enables verbose log output to see where things go wrong. In that case things like system error codes and the like would make sense, but a repeated printout of some kind of internal buffer state would hardly help the user - it could, however, help the developer. Thanks for bringing this forward! To whom is this directed? To you for attempting to revive the logger topic.
Re: Early review of std.logger
On Monday, 14 October 2013 at 12:48:14 UTC, Martin Drasar wrote: 1) MultiLogger class that takes references to other loggers and just forwards the call to the log function. +1 Also, we should support a few loggers whith same type. For example, I can use 2 file loggers: the 1-st only for debug messages and the 2-nd for all other messages. It can help for message sorting. Also, we should support a reserve loggers. For example, I can use a file logger as a default and a syslog as a reserve logger (it will be used if the file logger fails). It increases logger reliability. Also, it will be perfect to have logger failed notifications. For example, the file logger failed can indicate that we haven't got free disc space, a file system problems or hard disk problems. So, we should inform admin about this problems. We can do it via stderr (for local computer only), via syslog network logger or via e-mail logger.
Re: Early review of std.logger
On 10/15/2013 04:06 AM, Eric Anderton wrote: On Monday, 14 October 2013 at 11:39:52 UTC, Dicebot wrote: Lets unleash the forces of constructive destruction. So, not to be too heavy-handed with criticism on this library, but I think this should come up to par with solutions like log4j, log4cpp, or log4cxx, with respect to features and capabilities. Libraries like these have enjoyed a lot of very serious use, and once you have something like that in your project, it's hard to not use most of what they have to offer. There's really not a lot of fluff in those solutions. IMO these libraries are to heavy. Especially with phobos inclusion in mind. Here's what I think is missing: - System log support (as others have mentioned). This would be syslog or WEL, depending on environment. This is sort of the idea of the design, I can't anticipate your needs therefor I should not try. I should try to give you guidelines or a framework to work against. - Guarantees or options for working with log rotation (logrotate.d). It's nice to either know that you must restart your daemon once logs are rotated, or can configure logging to re-open handles automatically or when it detects rotation has occurred. See previous point - Guarantees about threading and thread safety, with concessions to help keep log event streams coherent from thread to thread. Log formatting in particular could enjoy the ability to emit a thread id, so logs can be analyzed without confusing which thread is responsible for which chain of events. Passing a thread id with a log message, ok! shared!? Here's what I think would make this an amazing library: - Nested Diagnostic Context (NDC) support. This isn't heavily used in all projects, but it does a fantastic job of cutting down on the tendency to put tons of redundant information into every call to log(). In practice, this helps tremendously for debugging, as engineers stop pulling punches as adding rich contextual data to log lines becomes painless. See previous point - Log category support. Just some way to add an axis for filtering, so you can configure logging to block all log messages from one library, or just errors from another, at the same time. Under log4j, this is simply the module where the log event originates from - other libs let you use an arbitrary string. at one point the logger had names, but I thought on how to get the correct names to them. This lead to some config file and I don't want that. - Filtering log events on another axis. Loggers can already be configured with a log level. But it would be nice to be able to set a global log level to dial in how much information comes out of the system across all logger instances. there already is a global log level That said, I do appreciate the compactness of this library. It provides some very straightforward logging support and covers all the basic and important use cases. But after using more feature-rich solutions, I can't help but think of all the places that I would feel inclined to go with a stronger solution, or extend this to do more of the kinds of things I'm used to doing elsewhere. I think D has a chance to make an implementation of something on par with log4j or log4cxx, easy to do, without needing anywhere near as much code. - Eric
Re: GDC vs dmd speed
On Monday, 14 October 2013 at 19:24:27 UTC, Spacen Jasset wrote:
Hello,
Whilst porting some C++ code I have discovered that the
compiled output from the gdc compiler seems to be 47% quicker
than the dmd compiler.
Here is a few more data points for microbenchmarks of simple
functions (Project Euler), which supports an observation
(disclaimer: my microbenchmark is not a guarantee of your code
performance, etc.) that the fastest code is produced by LDC, then
GDC and DMD is the slowest one.
Tested on Xubuntu 13.04 64-bit Core i5 3450S 2.8GHz.
Test 1:
// 454ns LDC 0.11.0: ldmd2 -m64 -O -noboundscheck -inline
-release
// 830ns GDC 4.8.1: gdc -m64 -march=native -fno-bounds-check
-frename-registers -frelease -O3
// 1115ns DMD64 2.063.2: dmd -O -noboundscheck -inline -release
int e28_0(int N = 1002) {
int diagNumber = 1;
int sum= diagNumber;
for (int width = 2; width N; width += 2)
for (int j = 0; j 4; ++j) {
diagNumber += width;
sum+= diagNumber;
}
return sum;
}
Test 2:
// 118ms LDC 0.11.0: ldmd2 -m64 -O -noboundscheck -inline
-release
// 125ms GDC 4.8.1: gdc -m64 -march=native -fno-bounds-check
-frename-registers -frelease -O3
// 161ms DMD64 2.063.2: dmd -O -noboundscheck -inline -release
bool isPalindrome(string s) {return equal(s, s.retro);}
int e4(int N = 1000) {
int nMax = 0;
foreach (uint i; 1..N)
foreach (uint j; i..N)
if (isPalindrome(to!string(i*j))i*j nMax)
nMax = i*j;
return nMax;
}
Test 3:
// 585us LDC 0.11.0: ldmd2 -m64 -O -noboundscheck -inline
-release
// 667us GDC 4.8.1: gdc -m64 -march=native -fno-bounds-check
-frename-registers -frelease -O3
// 853us DMD64 2.063.2: dmd -O -noboundscheck -inline -release
int e67_0(string fileName = rC:\Euler\data\e67.txt) {
// Read triangle numbers from file.
int[][] cell;
foreach (line; splitLines(cast(char[]) read(fileName))) {
int[] row;
foreach (token; std.array.splitter(line))
row ~= [to!int(token)];
cell ~= row;
}
// Compute maximum value partial paths ending at each cell.
foreach (y; 1..cell.length) {
cell[y][0] += cell[y-1][0];
foreach (x; 1..y)
cell[y][x] += max(cell[y-1][x-1], cell[y-1][x]);
cell[y][y] += cell[y-1][y-1];
}
// Return the maximum value terminal path.
return cell[$-1].reduce!max;
}
Here is the relative to LDC code speed averaged over these three
test (larger number is slower):
LDC 1.00
GDC 1.34
DMD 1.76
Re: GDC vs dmd speed
On Monday, 14 October 2013 at 19:24:27 UTC, Spacen Jasset wrote: gdc 4.6 (0.29.1-4.6.4-1ubuntu4) Which I assume might be v2.020? with flags: [-O2] That's a really old gdc. If you can, upgrade to ubuntu 13.10 and you'll get a more up-to-date version. Alternatively, build from source: http://gdcproject.org/wiki/Installation/GeneralIt'll take an age to run the compilation, but it's not hard to do.
Re: Early review of std.logger
On 10/15/2013 02:44 AM, Kapps wrote: A few concerns: There doesn't seem to be a debug or trace log level. This is quite a useful thing to have once your program is deployed. there is a LogLevel.debug and a LogLevel.info I don't like the returning by ref for log methods. For example, it seems like you can do: log(5 4, This is a test log) = new StdIOLogger(); It could potentially be useful to return the Logger so you can chain calls and such, but it should not be possible to set the logger by assigning the result of a log call. I saw this, but this comes from the way you get the default logger. I don't think that this is that bad, but I bet somebody will disagree. The simple act of logging a message is very verbose right now: log(LogLevel.trace, Creating new pool) is a lot of boiler plate. I'd prefer something like log.trace(Creating new pool) and log(Creating new pool) where the latter would use opCall to forward to the default log level. If it's intentional that you can assign the result of log, this also helps that because log = new StdIOLogger would be possible (log being a property that returns a Logger, and so a setter could be made), but log(Creating new pool) = new StdIOLogger() would not be. The LogLevel is optional. And always writing log.trace might become more typing work and assigning a LogLevel and than calling log(...). Both have pros and cons There's a lot of suggestions for things like network logging, but I think this is far beyond the scope of the module, and the sheer amount of different ways of doing it means people will likely write their own anyways. For example, synchronous vs asynchronous, what protocol to use, authentication, client data, encryption, etc. my point exactly
Re: dmd 2.063 generated code a lot slower then dmd 2.062
On Tuesday, 15 October 2013 at 06:38:22 UTC, Nick Sabalausky wrote: On Mon, 14 Oct 2013 16:19:23 +0200 Andrej Mitrovic andrej.mitrov...@gmail.com wrote: On 10/14/13, Nick Sabalausky seewebsitetocontac...@semitwist.com wrote: And any sane editor There's your problem right there. I'd say a sane diff view would make it obvious that CRLF or tabs were injected, and yet github's diff view is a piece of ass. Github's entire web frontend is horrible. They don't even know how to write a freaking web page: http://semitwist.com/articles/article/view/making-a-link-or-what-the-fuck-is-wrong-with-github-s-developers (BUt really, I'm not sure there's an ajaxy site in the world that isn't garbage. Ex: http://forum.dlang.org/post/mailman.1442.1379388733.1719.digitalmar...@puremagic.com ie For reference, that's considerably less than the chrome process that hosts gmail (200mb!)) Sadly that is the future. :( I am looking forward that native mobile applications kill these web applications trend, but I am in the minority. And I do write web applications as well, so I do know both sides of the fence. -- Paulo
Re: Early review of std.logger
On 10/15/2013 09:32 AM, Sönke Ludwig wrote: Am 15.10.2013 09:08, schrieb Jacob Carlborg: On 2013-10-14 23:22, Dicebot wrote: If we need to care about that, D module system is a failure. But I don't think it is a valid concern. People already complain about conflict function names in Phobos. And I'd agree with them. At least inside of a library, care IMO should be taken to minimize overlap (of course functionally equivalent ones in different overload sets are fine, though). But in case of logXXX this seems to be very unlikely, much in contrast to log (std.math.log). yes and no. Of course does logXXX create less conflict, but I like to simply write log and don't care about the LogLevel. So again pros and cons
Re: Early review of std.logger
What are the philosophy behind errors vs fatal errors vs critical errors? When should we use each of these?
Re: Early review of std.logger
On Monday, 14 October 2013 at 18:29:09 UTC, ilya-stromberg wrote: On Monday, 14 October 2013 at 18:00:12 UTC, Robert Schadek wrote: If you disagree, please tell why. If you want a logger with a particular feature, this module will allow to create a custom logger. It would be a mistake to include something that specific. eg: - we can create new RNG on top of std.random, which follow the same interface - we can use any such std.random-compatible RNG to feed random distributions algorithms
Re: Early review of std.logger
On 10/15/2013 09:40 AM, Sönke Ludwig wrote: Am 14.10.2013 20:24, schrieb Robert Schadek: On 10/14/2013 04:44 PM, Sönke Ludwig wrote: The same could be said about the global log functions, which are tightly coupled to that state. I think this is already nicely grouped together by the logger module itself, since there is not much else in it. Basically, I just wouldn't consider this style to be particularly idiomatic D code, but of course that's just personal perception/preference (there is also some precedence using struct instead of class in Druntime). However, if it ends up like this in the final version, it should get a @disable this(); to prevent misuse. It is for ment for phobos not druntime. Anyway structs would mean all templates and people will scream template bloat. And this would break the design, which I find to be a valid use of classes and polymorphisms. The StdIOLogger can have its default constructor called IMO. No no, I was talking about the JobManager, not the Logger classes. No templates involved. Than I'm not sure what you're referring to. Maybe I miscommunicated what I want to show by that example. The (d|D) part is the rename to enum lower case. The debug log level is given through the LogLevel.Debug, which will be renamed to LogLevel.debug. I would call the developer the user of the logger. Maybe log messages can be communicated to the user of the applicaiton and the developer of the application through a MultiLogger class. But the statement of mine that you quoted was about debug levels (the case issue is clear)... Also right now there is no (D|d)ebug level, so I'm actually not sure about the statement that you want to make. But my example of having different levels for the application user and the developer is mostly important when the application user enables verbose log output to see where things go wrong. In that case things like system error codes and the like would make sense, but a repeated printout of some kind of internal buffer state would hardly help the user - it could, however, help the developer. maybe something like: auto devLogger = new StdIOLogger(LogLevel.info); auto appLogger = new FencySelfWrittenGuiLogger(LogLevel.Warning); auto multiLogger = new MultiLogger(devLogger, appLogger); multiLogger.log(...); otherwise, I think I don't follow you
Re: Early review of std.logger
On 10/15/2013 09:44 AM, ilya-stromberg wrote: On Monday, 14 October 2013 at 12:48:14 UTC, Martin Drasar wrote: 1) MultiLogger class that takes references to other loggers and just forwards the call to the log function. +1 Also, we should support a few loggers whith same type. For example, I can use 2 file loggers: the 1-st only for debug messages and the 2-nd for all other messages. It can help for message sorting. Also, we should support a reserve loggers. For example, I can use a file logger as a default and a syslog as a reserve logger (it will be used if the file logger fails). It increases logger reliability. Also, it will be perfect to have logger failed notifications. For example, the file logger failed can indicate that we haven't got free disc space, a file system problems or hard disk problems. So, we should inform admin about this problems. We can do it via stderr (for local computer only), via syslog network logger or via e-mail logger. I think File will throw anyway. What if stderr is piped to file? Again, I don't think you can please everybody's needs. So we should not try, but rather provide the tools to help yourself.
Re: Early review of std.logger
On 10/15/2013 10:49 AM, ponce wrote: What are the philosophy behind errors vs fatal errors vs critical errors? When should we use each of these? fatal = the application is going down, I'm just letting you know critical = the application is maybe going down, I'm not sure yet, but this is a problem error = something went wrong, I'm sure if this is problem
Re: Qt bindings for D
On Monday, 14 October 2013 at 09:45:18 UTC, Abdulhaq wrote: I recommend to dump it and start from scratch. A clang-based generator would be an interesting option to explore. Or, if you want to preserve your sanity, just write Qt applications in C++/QML. Hi Max, so why dump it? I can see a few reasons why you might propose that: 1) You think it's a dead end because QtJambi is dead, so it would be problematic to move it forward with new versions of Qt That is one reason. Also, QtJambi is based on a limited and outdated C++ parser, and we had problems getting necessary information from it. When Qt moves to C++11, the situation will get worse. So I think it is reasonable to switch to clang soon. 2) There are some problems with the architecture of the binding that you're aware of that would prevent it from working reliably For (1), I think even only having 4.8 is still a real asset. I don't know the code base really well (but spent a fair amount of time with it, and know the PyQt technology fairly well too) so can't speak to (2) but if you had specific concerns it would be very interesting to know what they were. From my testing it seems to me that a lot is working, enough to write useful GUIs in it - tell me what I'm missing (a lot, I know, but is anything really fatally flawed)? Well, you can use the bindings for simple short-living utilities if you don't mind occasional memory leaks and crashes. Long story short, D allows for two approaches to bindings like QtD: 1. The traditional one is to allocate shells on GC heap and have a set of manually specified rules for ownership transfers and reference count adjustments. 2. The other is more interesting - abandon the idea of reference/ownership annotations and go with semi-automatic memory management as it is in Qt, with no reliance on the GC. At some point I wanted to switch to 2 completely, so QtD is somewhere between 1 and 2, quite a mess.
Re: Qt bindings for D
On Monday, 14 October 2013 at 11:35:05 UTC, Jacob Carlborg wrote: On 2013-10-14 11:03, Max Samukha wrote: I recommend to dump it and start from scratch. A clang-based generator would be an interesting option to explore. Or, if you want to preserve your sanity, just write Qt applications in C++/QML. I already have a Clang based tool, DStep, but that's only for C and Objective-C. It could be extended to support C++ as well. https://github.com/jacob-carlborg/dstep Nice! That may come in handy some day.
Re: Early review of std.logger
On Tuesday, 15 October 2013 at 07:33:15 UTC, Sönke Ludwig wrote: Am 15.10.2013 09:08, schrieb Jacob Carlborg: On 2013-10-14 23:22, Dicebot wrote: If we need to care about that, D module system is a failure. But I don't think it is a valid concern. People already complain about conflict function names in Phobos. And I'd agree with them. At least inside of a library, care IMO should be taken to minimize overlap (of course functionally equivalent ones in different overload sets are fine, though). But in case of logXXX this seems to be very unlikely, much in contrast to log (std.math.log). I disagree. People complain because they try to use imports in a straightforward way, similar to includes. That should be discouraged as a bad style in D. Imports should always be either with explicit mention of exported symbol or aliased static imports. And global module imports should be discouraged too.
Re: [Proposal] Weak reference implementation for D
14.10.2013 17:42, robert пишет: Damn it, you are right I did not think this through, somehow thought the use in addrOf is enough, which is of course crap. Thank's a lot for your time, I'll fix this ASAP. So, here are your revised version: https://github.com/phobos-x/phobosx/blob/1f0016c84c2043da0b9d2dafe65f54fcf6b6b8fa/source/phobosx/signal.d Sorry, but you are making the same mistake again. Lets start from the hardware. Just like a compiler CPU is free to do whatever it wants with passed instructions but guarantee result state will be the same as if it is executed sequentially. And it doesn't assume access from other threads by default (see e.g. out-of-order execution). So memory barriers (memory fences) are needed to ensure loads/stores before the barrier are performed and no loads/stores after the barrier are executing. This is what `core.atomic.atomicFence` does and it can be used in e.g. in mutex implementations. As your operations with `_obj` are already atomic no `atomicFence` call is needed. Now let's assume without loss of generality `InvisibleAddress.address` returns `cast(void*) ~_addr`, inline the `address` call, and remove redundant `atomicFence` call: ``` auto tmp = atomicLoad(_obj); auto o = cast(void*) ~tmp._addr; if(o is null) return null; GC.addrOf(o); auto tmp1 = atomicLoad(_obj); if(o is cast(void*) ~tmp1._addr) return cast(Object) o; assert(cast(void*) ~tmp1._addr is null); return null; ``` As I mentioned above you are making the same incorrect assumption that you know what machine instructions a compiler will generate. Never make such assumptions. Here is an example of how your code can be rewritten by a compiler: ``` auto tmp = atomicLoad(_obj); if(tmp._addr == -1) return null; GC.addrOf(cast(void*) ~tmp._addr); auto tmp1 = atomicLoad(_obj); if(tmp._addr == tmp1._addr) return cast(Object) cast(void*) ~tmp._addr; assert(tmp1._addr == -1); return null; ``` -- Денис В. Шеломовский Denis V. Shelomovskij
Re: draft proposal for ref counting in D
On 2013-10-15 02:20:49 +, deadalnix deadal...@gmail.com said: It will indeed cause trouble for code that mutate a large amount of shared pointers. I'd say that such code is probably asking for trouble in the first place, but as always, no silver bullet. I still think solution is the one that fit D the best. I think there's a small mistake in your phrasing, but it makes a difference. When the collector is running, it needs to know about any mutation for pointers to its shared memory pool, including pointers that are themselves thread-local but point to shared memory. So COW will be trouble for code that mutate a large amount of **pages containing pointers to shared memory**. And this which includes **pointers to immutable data** because immutable is implicitly shared. And this includes **pointers to const data** since those pointers might point to immutable (thus shared) memory. So any memory page susceptible of containing pointers to shared memory would need to use COW during collection. Which means all the thread's stacks, and also all objects with a pointer to shared, immutable, and const data. At this point I think it is fair to approximate this to almost all memory that could contain pointers. -- Michel Fortin michel.for...@michelf.ca http://michelf.ca
Re: draft proposal for ref counting in D
On 2013-10-15 07:28:16 +, Jacob Carlborg d...@me.com said: On 2013-10-15 05:11, Michel Fortin wrote: mprotect isn't available at all with the iOS SDK. So making this collector work on iOS (and the iOS Simulator) would require a different codegen. I haven't tried compiling anything and I don't know if I'm looking in the correct file but this file: /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.0.sdk/usr/include/sys/mman.h Does contain mprotect. You're right. Yes it does exist. I was confused. Not only it does exist, but it lets you set the executable bit. I find that depressing, since I'm pretty sure App Store apps are prevented from setting the executable bit, and I'd tend to think now that they're blocking it by checking for references to mprotect it in the executable when submitting to the App Store. And by doing it this way they probably wouldn't be able to distinguish between setting the executable bit or making a page read-only. Also, someone would need to check that Windows Phone apps and Windows 8-style (Metro) apps can access mprotect (or equivalent) too. They're sandboxed just as heavily and statically checked upon submission the same way. Could some game consoles out there block it too? -- Michel Fortin michel.for...@michelf.ca http://michelf.ca
Re: Early review of std.logger
Am 15.10.2013 10:54, schrieb Robert Schadek:
On 10/15/2013 09:40 AM, Sönke Ludwig wrote:
Am 14.10.2013 20:24, schrieb Robert Schadek:
On 10/14/2013 04:44 PM, Sönke Ludwig wrote:
The same could be said about the global log functions, which are
tightly coupled to that state. I think this is already nicely grouped
together by the logger module itself, since there is not much else
in it.
Basically, I just wouldn't consider this style to be particularly
idiomatic D code, but of course that's just personal
perception/preference (there is also some precedence using struct
instead of class in Druntime). However, if it ends up like this in
the
final version, it should get a @disable this(); to prevent misuse.
It is for ment for phobos not druntime. Anyway structs would mean all
templates and people will scream template bloat. And this would break
the design, which I find to be a valid use of classes and
polymorphisms. The StdIOLogger can have its default constructor
called IMO.
No no, I was talking about the JobManager, not the Logger classes. No
templates involved.
Than I'm not sure what you're referring to.
What I meant is just that in Druntime there is something like this:
struct LogManager {
static void somefunc();
}
instead of
class LogManager {
static void someFunc();
}
In any case, such a struct/class should also have a member @disable
this(); so that it cannot be uselessly instantiated.
Maybe I miscommunicated what I want to show by that example. The (d|D)
part is the rename to enum lower case.
The debug log level is given through the LogLevel.Debug, which will be
renamed to LogLevel.debug. I would call the developer the user of the
logger. Maybe log messages can be communicated to the user of the
applicaiton and the developer of the application through a MultiLogger
class.
But the statement of mine that you quoted was about debug levels (the
case issue is clear)... Also right now there is no (D|d)ebug level,
so I'm actually not sure about the statement that you want to make.
But my example of having different levels for the application user and
the developer is mostly important when the application user enables
verbose log output to see where things go wrong. In that case things
like system error codes and the like would make sense, but a repeated
printout of some kind of internal buffer state would hardly help the
user - it could, however, help the developer.
maybe something like:
auto devLogger = new StdIOLogger(LogLevel.info);
auto appLogger = new FencySelfWrittenGuiLogger(LogLevel.Warning);
auto multiLogger = new MultiLogger(devLogger, appLogger);
multiLogger.log(...);
otherwise, I think I don't follow you
The log messages are supposed to go to the same destination, just
filtered by log level. A totally artificial example:
---
void main(string[] args)
{
logDiagnostic(Application called as %s, args[0]);
ubyte[] contents;
try {
logTrace(Going to read file);
contents = read(somefile.dat);
logTrace(Done reading file);
} catch (Exception e) {
logError(Failed to read input file.);
logDiagnostic(Reported error: %s, e.msg);
logDebug(Full exception: %s, e.toString());
return 1;
}
logInfo(Input file is %d bytes, contents.length);
logTrace(Computing sum);
auto sum = sum(contents);
logTrace(Removing file);
remove(somefile.dat);
}
ulong sum(ubyte[] arr)
{
ulong ret = 0;
foreach (b; arr) {
logDebugV(Adding %d, b);
ret += b;
}
logDebugV(Sum result: %d, b);
return ret;
}
---
A typical mode in my projects now is to output any level starting with
info to the console by default, but allow to log diagnostic messages
using -v (useful to the end user) and lower levels using other
switches (useful for me to diagnose bugs).
At the same time there may be a log file or a network based remote
logger that captures all levels regardless of command line switches, but
needs to be able to filter based on the actual log level later in a GUI.
Having multiple loggers for the different diagnostic/debug/trace levels
would not really help there (except with some extensive hacking).
BTW you stated that there is a debug level in your implementation, but
neither the docs, nor the pull request have it.
Re: Early review of std.logger
On 10/15/2013 02:54 PM, Sönke Ludwig wrote:
What I meant is just that in Druntime there is something like this:
struct LogManager {
static void somefunc();
}
instead of
class LogManager {
static void someFunc();
}
In any case, such a struct/class should also have a member @disable
this(); so that it cannot be uselessly instantiated.
I see what you mean, good point.
The log messages are supposed to go to the same destination, just
filtered by log level. A totally artificial example:
---
void main(string[] args)
{
logDiagnostic(Application called as %s, args[0]);
ubyte[] contents;
try {
logTrace(Going to read file);
contents = read(somefile.dat);
logTrace(Done reading file);
} catch (Exception e) {
logError(Failed to read input file.);
logDiagnostic(Reported error: %s, e.msg);
logDebug(Full exception: %s, e.toString());
return 1;
}
logInfo(Input file is %d bytes, contents.length);
logTrace(Computing sum);
auto sum = sum(contents);
logTrace(Removing file);
remove(somefile.dat);
}
ulong sum(ubyte[] arr)
{
ulong ret = 0;
foreach (b; arr) {
logDebugV(Adding %d, b);
ret += b;
}
logDebugV(Sum result: %d, b);
return ret;
}
---
Ok, you can achieve this by assigning a LogLevel to the defaultLogger.
Than all message with a LogLevel = to the assigned LogLevel will be
logged. Or do you want to, for example, filter all message with critical
and debug LogLevel, but don't display the messages with LogLevels in
between?
BTW you stated that there is a debug level in your implementation,
but neither the docs, nor the pull request have it.
You're right I was reading Debug and thought Info, my bad!
Re: Early review of std.logger
Am 15.10.2013 10:41, schrieb Robert Schadek:
On 10/15/2013 02:44 AM, Kapps wrote:
The simple act of logging a message is very verbose right now:
log(LogLevel.trace, Creating new pool) is a lot of boiler plate. I'd
prefer something like log.trace(Creating new pool) and log(Creating
new pool) where the latter would use opCall to forward to the default
log level. If it's intentional that you can assign the result of log,
this also helps that because log = new StdIOLogger would be possible
(log being a property that returns a Logger, and so a setter could be
made), but log(Creating new pool) = new StdIOLogger() would not be.
The LogLevel is optional. And always writing log.trace might become more
typing work and assigning a LogLevel and than calling log(...). Both
have pros and cons
What happens when a called function alters the default log level?
---
void func1() {
log.logLevel = LogLevel.debug;
log(This is a debug message);
func2();
log(This is supposed to be a debug message);
}
void func2() {
log.logLevel = LogLevel.warning;
log(This is a warning);
}
---
I don't think it's a good idea to use such kind of global state,
especially for a logging framework that is supposed to be shared between
libraries, so that it is difficult to predict what a particular function
does. With a logger that is shared between threads, things get worse of
course.
A related question: It seems like Logger.logLevel at the same time means
the minimum log level that is output and the default log level, is that
right?
Re: Early review of std.logger
On Tuesday, 15 October 2013 at 07:52:28 UTC, Robert Schadek wrote: On 10/15/2013 04:06 AM, Eric Anderton wrote: On Monday, 14 October 2013 at 11:39:52 UTC, Dicebot wrote: Here's what I think is missing: - System log support (as others have mentioned). This would be syslog or WEL, depending on environment. This is sort of the idea of the design, I can't anticipate your needs therefor I should not try. I should try to give you guidelines or a framework to work against. Totally disagree. We need a powerful logger, not only file logger. I can implement a file logger myself for a few hours, and it will cover 90% of my needs. For other 10% I would like to have a standart logger with advanced features like speed and reliability. If you need help, please tell us. For example, jkm already implemented syslog for Vibe.d with support files (via file streams) and the network (via TCP or SSL streams): https://github.com/rejectedsoftware/vibe.d/pull/294 It's under the MIT license, that similar to the Boost license. Sönke Ludwig, can you allow to use syslog code for `std.logger` under the Boost license? Robert Schadek can use it as initial point.
Re: Early review of std.logger
On 10/15/2013 03:21 PM, Sönke Ludwig wrote:
Am 15.10.2013 10:41, schrieb Robert Schadek:
On 10/15/2013 02:44 AM, Kapps wrote:
The simple act of logging a message is very verbose right now:
log(LogLevel.trace, Creating new pool) is a lot of boiler plate. I'd
prefer something like log.trace(Creating new pool) and log(Creating
new pool) where the latter would use opCall to forward to the default
log level. If it's intentional that you can assign the result of log,
this also helps that because log = new StdIOLogger would be possible
(log being a property that returns a Logger, and so a setter could be
made), but log(Creating new pool) = new StdIOLogger() would not be.
The LogLevel is optional. And always writing log.trace might become more
typing work and assigning a LogLevel and than calling log(...). Both
have pros and cons
What happens when a called function alters the default log level?
The default log level is altered.
---
void func1() {
log.logLevel = LogLevel.debug;
log(This is a debug message);
func2();
log(This is supposed to be a debug message);
}
void func2() {
log.logLevel = LogLevel.warning;
log(This is a warning);
}
---
If you don't specify a logger nor a LogLevel the currently set default
logger will log the message with its currently set LogLevel.
I don't think it's a good idea to use such kind of global state,
especially for a logging framework that is supposed to be shared
between libraries, so that it is difficult to predict what a
particular function does. With a logger that is shared between
threads, things get worse of course.
I think this is good, as it gives you a way to quite libraries down. The
idea behind the free standing log function is to provide an ultra easy
way to log. It is not meant to be used for the 231 line program. In
that case you will properly have very specific needs on how to log.
Hence implement the abstract Logger class to your needs.
A related question: It seems like Logger.logLevel at the same time
means the minimum log level that is output and the default log level,
is that right?
Yes. The LogLevel of each logger is the LogLevel used if non is
specified and only messages are logged by this logger if their LogLevel
is greater equal to that Level. Additionally the LogLevel must be = to
the global LogLevel.
Re: Early review of std.logger
On Tuesday, 15 October 2013 at 13:31:40 UTC, ilya-stromberg wrote: ... I think such stuff should go as an extra module in same package with various useful out-of-the box logger implementations at the very best. Probably even dub package built on top of std.logger; Phobos has very specific general design I like a lot - self-contained modules/packages with zero external dependencies (please kill std.net.curl!), which do work by simply importing certain modules. No extra configuration, no creation of weird useless classes - just reasonable defaults that work as-is in most cases. In that sense what is 100% needed is enhancing current API so that it may allow more fine grained tweaking of loggers (addition of module info, providing built-in multiplexing logger). There should be no temptation to build own stuff with own API because you can't write own logger that fits standard one. But actual batteries - no, this does belong to Phobos.
Re: Early review of std.logger
On 10/15/2013 03:31 PM, ilya-stromberg wrote: On Tuesday, 15 October 2013 at 07:52:28 UTC, Robert Schadek wrote: On 10/15/2013 04:06 AM, Eric Anderton wrote: On Monday, 14 October 2013 at 11:39:52 UTC, Dicebot wrote: Here's what I think is missing: - System log support (as others have mentioned). This would be syslog or WEL, depending on environment. This is sort of the idea of the design, I can't anticipate your needs therefor I should not try. I should try to give you guidelines or a framework to work against. Totally disagree. We need a powerful logger, not only file logger. I can implement a file logger myself for a few hours, and it will cover 90% of my needs. For other 10% I would like to have a standart logger with advanced features like speed and reliability. I bet your 10% and mine 10% do not overlap. And than either you or I will complain about it. If you need help, please tell us. For example, jkm already implemented syslog for Vibe.d with support files (via file streams) and the network (via TCP or SSL streams): https://github.com/rejectedsoftware/vibe.d/pull/294 It's under the MIT license, that similar to the Boost license. Sönke Ludwig, can you allow to use syslog code for `std.logger` under the Boost license? Robert Schadek can use it as initial point. Before any time is spent to implement x number of logger the design must be done.
Re: Early review of std.logger
But actual batteries - no, this does belong to Phobos. * does not belong
Re: Early review of std.logger
On Tuesday, 15 October 2013 at 13:52:17 UTC, Robert Schadek wrote: I think this is good, as it gives you a way to quite libraries down. The idea behind the free standing log function is to provide an ultra easy way to log. It is not meant to be used for the 231 line program. In that case you will properly have very specific needs on how to log. Hence implement the abstract Logger class to your needs. I'll consider any logging library that forces me to use logger instance explicitly for typical tasks a failure. Once the system is configured upon program startup, using free functions and/or system-wide defaults should be enough.
Re: Early review of std.logger
On 10/15/2013 03:54 PM, Dicebot wrote: On Tuesday, 15 October 2013 at 13:31:40 UTC, ilya-stromberg wrote: ... I think such stuff should go as an extra module in same package with various useful out-of-the box logger implementations at the very best. Probably even dub package built on top of std.logger; Phobos has very specific general design I like a lot - self-contained modules/packages with zero external dependencies (please kill std.net.curl!), which do work by simply importing certain modules. No extra configuration, no creation of weird useless classes - just reasonable defaults that work as-is in most cases. In that sense what is 100% needed is enhancing current API so that it may allow more fine grained tweaking of loggers (addition of module info, providing built-in multiplexing logger). There should be no temptation to build own stuff with own API because you can't write own logger that fits standard one. But actual batteries - no, this does belong to Phobos. +1
Re: Early review of std.logger
On 10/15/2013 03:57 PM, Dicebot wrote: On Tuesday, 15 October 2013 at 13:52:17 UTC, Robert Schadek wrote: I think this is good, as it gives you a way to quite libraries down. The idea behind the free standing log function is to provide an ultra easy way to log. It is not meant to be used for the 231 line program. In that case you will properly have very specific needs on how to log. Hence implement the abstract Logger class to your needs. I'll consider any logging library that forces me to use logger instance explicitly for typical tasks a failure. Once the system is configured upon program startup, using free functions and/or system-wide defaults should be enough. I don't think that there are enough compiler generated marked that you can pass as default parameter to a free standing function in a way that you can create a logger that fulfills this need. At some point you properly have to write a string of and identifier to specify a logger.
Re: Early review of std.logger
On Tuesday, 15 October 2013 at 13:54:12 UTC, Dicebot wrote: On Tuesday, 15 October 2013 at 13:31:40 UTC, ilya-stromberg wrote: ... I think such stuff should go as an extra module in same package with various useful out-of-the box logger implementations at the very best. Probably even dub package built on top of std.logger; Phobos has very specific general design I like a lot - self-contained modules/packages with zero external dependencies (please kill std.net.curl!), which do work by simply importing certain modules. No extra configuration, no creation of weird useless classes - just reasonable defaults that work as-is in most cases. In that sense what is 100% needed is enhancing current API so that it may allow more fine grained tweaking of loggers (addition of module info, providing built-in multiplexing logger). There should be no temptation to build own stuff with own API because you can't write own logger that fits standard one. But actual batteries - no, this does belong to Phobos. I did not talk about additional external libraries. As I know, Vibe.d use OpenSSL to provide SSL streams. Since we haven't got encryption support in Phobos, we can provide only TCP streams.
Re: Inconsitency
On Sunday, 13 October 2013 at 17:01:15 UTC, Dicebot wrote: If single element access is needed, str.front yields decoded `dchar`. Or simple `foreach (dchar d; str)` - it won't hide the fact it is O(n) operation at least. As `str.front` yields dchar, most `std.algorithm` and `std.range` utilities will also work correctly on default UTF-8 strings. No, he needs graphemes, so `std.algorithm` won't work correctly for him as Peter has shown: grapheme doesn't fit in dchar.
Re: Early review of std.logger
Am 15.10.2013 15:52, schrieb Robert Schadek:
On 10/15/2013 03:21 PM, Sönke Ludwig wrote:
Am 15.10.2013 10:41, schrieb Robert Schadek:
On 10/15/2013 02:44 AM, Kapps wrote:
The simple act of logging a message is very verbose right now:
log(LogLevel.trace, Creating new pool) is a lot of boiler plate. I'd
prefer something like log.trace(Creating new pool) and log(Creating
new pool) where the latter would use opCall to forward to the default
log level. If it's intentional that you can assign the result of log,
this also helps that because log = new StdIOLogger would be possible
(log being a property that returns a Logger, and so a setter could be
made), but log(Creating new pool) = new StdIOLogger() would not be.
The LogLevel is optional. And always writing log.trace might become more
typing work and assigning a LogLevel and than calling log(...). Both
have pros and cons
What happens when a called function alters the default log level?
The default log level is altered.
Believe it or not, for some reason I suspected as much.
---
void func1() {
log.logLevel = LogLevel.debug;
log(This is a debug message);
func2();
log(This is supposed to be a debug message);
}
void func2() {
log.logLevel = LogLevel.warning;
log(This is a warning);
}
---
If you don't specify a logger nor a LogLevel the currently set default
logger will log the message with its currently set LogLevel.
Yes, but the point is that when looking only at func1, you might expect
that all messages are logged as debug messages, but the last one will be
logged as a warning instead. func2 may be hidden in library where the
function body is not readily available.
I don't think it's a good idea to use such kind of global state,
especially for a logging framework that is supposed to be shared
between libraries, so that it is difficult to predict what a
particular function does. With a logger that is shared between
threads, things get worse of course.
I think this is good, as it gives you a way to quite libraries down. The
idea behind the free standing log function is to provide an ultra easy
way to log. It is not meant to be used for the 231 line program. In
that case you will properly have very specific needs on how to log.
Hence implement the abstract Logger class to your needs.
But if it's available people _will_ use it in complex contexts. Also if
the writer of a 28 loc library uses it and the library is used by a
large piece of software, that will also be affected. The point is that
it is unhygienic and requires non-trivial extra work when using a logger
in a multi-threaded environment. Some kind of scoped stack of default
log levels would get around this issue, but that smells like over
engineering.
A related question: It seems like Logger.logLevel at the same time
means the minimum log level that is output and the default log level,
is that right?
Yes. The LogLevel of each logger is the LogLevel used if non is
specified and only messages are logged by this logger if their LogLevel
is greater equal to that Level. Additionally the LogLevel must be = to
the global LogLevel.
But these are two different concepts and it's hard for me to imagine why
they should be conflated. But I guess it's time to stop complaining
about the whole log(message) complex.
Re: Inconsitency
On Sunday, 13 October 2013 at 14:14:14 UTC, nickles wrote: Also, I understand, that there is the std.utf.count() function which returns the length that I was searching for. However, why - if D is so UTF-8-centric - isn't this function implemented in the core like .length? Most code doesn't need to count graphemes and lives happily with just strings, that's why it's not in the core.
Re: Early review of std.logger
On Tuesday, 15 October 2013 at 14:09:36 UTC, ilya-stromberg wrote: I did not talk about additional external libraries. As I know, Vibe.d use OpenSSL to provide SSL streams. Since we haven't got encryption support in Phobos, we can provide only TCP streams. For example, sending mail is clearly relying on external stuff and should never be in Phobos (again, std.net.curl was a terrible mistake)
Re: Early review of std.logger
On 10/15/2013 04:12 PM, Sönke Ludwig wrote: Believe it or not, for some reason I suspected as much. Yes, but the point is that when looking only at func1, you might expect that all messages are logged as debug messages, but the last one will be logged as a warning instead. func2 may be hidden in library where the function body is not readily available. Logging is the most unpure functionality I can think of. It is side effect heaven. But if it's available people _will_ use it in complex contexts. Also if the writer of a 28 loc library uses it and the library is used by a large piece of software, that will also be affected. The point is that it is unhygienic and requires non-trivial extra work when using a logger in a multi-threaded environment. Some kind of scoped stack of default log levels would get around this issue, but that smells like over engineering. But these are two different concepts and it's hard for me to imagine why they should be conflated. But I guess it's time to stop complaining about the whole log(message) complex. ...
Re: Early review of std.logger
On Tuesday, 15 October 2013 at 14:12:38 UTC, Sönke Ludwig wrote:
Am 15.10.2013 15:52, schrieb Robert Schadek:
On 10/15/2013 03:21 PM, Sönke Ludwig wrote:
Am 15.10.2013 10:41, schrieb Robert Schadek:
On 10/15/2013 02:44 AM, Kapps wrote:
The simple act of logging a message is very verbose right
now:
log(LogLevel.trace, Creating new pool) is a lot of boiler
plate. I'd
prefer something like log.trace(Creating new pool) and
log(Creating
new pool) where the latter would use opCall to forward to
the default
log level. If it's intentional that you can assign the
result of log,
this also helps that because log = new StdIOLogger would be
possible
(log being a property that returns a Logger, and so a
setter could be
made), but log(Creating new pool) = new StdIOLogger()
would not be.
The LogLevel is optional. And always writing log.trace might
become more
typing work and assigning a LogLevel and than calling
log(...). Both
have pros and cons
What happens when a called function alters the default log
level?
The default log level is altered.
Believe it or not, for some reason I suspected as much.
---
void func1() {
log.logLevel = LogLevel.debug;
log(This is a debug message);
func2();
log(This is supposed to be a debug message);
}
void func2() {
log.logLevel = LogLevel.warning;
log(This is a warning);
}
---
If you don't specify a logger nor a LogLevel the currently set
default
logger will log the message with its currently set LogLevel.
Yes, but the point is that when looking only at func1, you
might expect that all messages are logged as debug messages,
but the last one will be logged as a warning instead. func2 may
be hidden in library where the function body is not readily
available.
I don't think it's a good idea to use such kind of global
state,
especially for a logging framework that is supposed to be
shared
between libraries, so that it is difficult to predict what a
particular function does. With a logger that is shared between
threads, things get worse of course.
I think this is good, as it gives you a way to quite libraries
down. The
idea behind the free standing log function is to provide an
ultra easy
way to log. It is not meant to be used for the 231 line
program. In
that case you will properly have very specific needs on how to
log.
Hence implement the abstract Logger class to your needs.
But if it's available people _will_ use it in complex contexts.
Also if the writer of a 28 loc library uses it and the
library is used by a large piece of software, that will also be
affected. The point is that it is unhygienic and requires
non-trivial extra work when using a logger in a multi-threaded
environment. Some kind of scoped stack of default log levels
would get around this issue, but that smells like over
engineering.
+1
I dislike syntax:
log.logLevel = LogLevel.warning;
log(This is a warning);
Much better:
log.warning(This is a warning);
Re: Early review of std.logger
On Tuesday, 15 October 2013 at 14:20:15 UTC, Robert Schadek wrote: On 10/15/2013 04:12 PM, Sönke Ludwig wrote: Believe it or not, for some reason I suspected as much. Yes, but the point is that when looking only at func1, you might expect that all messages are logged as debug messages, but the last one will be logged as a warning instead. func2 may be hidden in library where the function body is not readily available. Logging is the most unpure functionality I can think of. It is side effect heaven. Yes, but we should minimise possible side effects.
Re: Early review of std.logger
Am 15.10.2013 15:31, schrieb ilya-stromberg: On Tuesday, 15 October 2013 at 07:52:28 UTC, Robert Schadek wrote: On 10/15/2013 04:06 AM, Eric Anderton wrote: On Monday, 14 October 2013 at 11:39:52 UTC, Dicebot wrote: Here's what I think is missing: - System log support (as others have mentioned). This would be syslog or WEL, depending on environment. This is sort of the idea of the design, I can't anticipate your needs therefor I should not try. I should try to give you guidelines or a framework to work against. Totally disagree. We need a powerful logger, not only file logger. I can implement a file logger myself for a few hours, and it will cover 90% of my needs. For other 10% I would like to have a standart logger with advanced features like speed and reliability. In this case I do agree with Robert that it will be better to keep the std.log module basic and as dependency free as possible. The main advantage of it is to enhance interoperability of different libraries that use logging, but any advanced features can be implemented by external libraries just as well (at least at the beginning). But of course the general design allow for all complex use cases. And then over time it may well show that it makes sense to include more standard loggers. /IMHO If you need help, please tell us. For example, jkm already implemented syslog for Vibe.d with support files (via file streams) and the network (via TCP or SSL streams): https://github.com/rejectedsoftware/vibe.d/pull/294 It's under the MIT license, that similar to the Boost license. Sönke Ludwig, can you allow to use syslog code for `std.logger` under the Boost license? Robert Schadek can use it as initial point. Should this be needed, it would be absolutely no problem. MIT - Boost works automatically and I would also happily transfer the code ownership if needed.
Re: Early review of std.logger
On Tuesday, 15 October 2013 at 14:13:53 UTC, Dicebot wrote: On Tuesday, 15 October 2013 at 14:09:36 UTC, ilya-stromberg wrote: I did not talk about additional external libraries. As I know, Vibe.d use OpenSSL to provide SSL streams. Since we haven't got encryption support in Phobos, we can provide only TCP streams. For example, sending mail is clearly relying on external stuff and should never be in Phobos (again, std.net.curl was a terrible mistake) I didn't know about it, sorry.
Re: Early review of std.logger
On 10/15/2013 04:17 PM, ilya-stromberg wrote: On Tuesday, 15 October 2013 at 14:12:38 UTC, Sönke Ludwig wrote: But if it's available people _will_ use it in complex contexts. Also if the writer of a 28 loc library uses it and the library is used by a large piece of software, that will also be affected. The point is that it is unhygienic and requires non-trivial extra work when using a logger in a multi-threaded environment. Some kind of scoped stack of default log levels would get around this issue, but that smells like over engineering. +1 I dislike syntax: log.logLevel = LogLevel.warning; log(This is a warning); Much better: log.warning(This is a warning); You can also write log(LogLevel.warning, This is a warning); And that also allows you to treat the LogLevel as a variable. log(myComputedLogLevel, ...); Anyway, functions should be verbs.
Re: Early review of std.logger
On 10/15/2013 04:23 PM, ilya-stromberg wrote: On Tuesday, 15 October 2013 at 14:20:15 UTC, Robert Schadek wrote: Logging is the most unpure functionality I can think of. It is side effect heaven. Yes, but we should minimise possible side effects. Of course, but having global state aka. a global default logger and no side effect are opposing design goals.
Re: Early review of std.logger
Am 15.10.2013 16:33, schrieb Robert Schadek: On 10/15/2013 04:23 PM, ilya-stromberg wrote: On Tuesday, 15 October 2013 at 14:20:15 UTC, Robert Schadek wrote: Logging is the most unpure functionality I can think of. It is side effect heaven. Yes, but we should minimise possible side effects. Of course, but having global state aka. a global default logger and no side effect are opposing design goals. minimise != eliminate The global default logger will usually be a set-once thing, so it's far less problematic.
Re: Early review of std.logger
On Tuesday, 15 October 2013 at 14:25:55 UTC, Robert Schadek wrote: On 10/15/2013 04:17 PM, ilya-stromberg wrote: On Tuesday, 15 October 2013 at 14:12:38 UTC, Sönke Ludwig wrote: But if it's available people _will_ use it in complex contexts. Also if the writer of a 28 loc library uses it and the library is used by a large piece of software, that will also be affected. The point is that it is unhygienic and requires non-trivial extra work when using a logger in a multi-threaded environment. Some kind of scoped stack of default log levels would get around this issue, but that smells like over engineering. +1 I dislike syntax: log.logLevel = LogLevel.warning; log(This is a warning); Much better: log.warning(This is a warning); You can also write log(LogLevel.warning, This is a warning); And that also allows you to treat the LogLevel as a variable. log(myComputedLogLevel, ...); Anyway, functions should be verbs. Yes, I know. Idea: let all as is and just add `log.xxx(...);` functions. It looks like that solves all problems: - we can log with configurable default log level (setup for all programm): log(This is a warning); - we can specify local log level (setup for class or function): log(myComputedLogLevel, ...); - and we can call log with specific log level: log.warning(...); or maybe log.logWarning(...); //yes, it is a verb
Re: Early review of std.logger
On 10/15/13 12:52 AM, Robert Schadek wrote: On 10/15/2013 04:06 AM, Eric Anderton wrote: On Monday, 14 October 2013 at 11:39:52 UTC, Dicebot wrote: Lets unleash the forces of constructive destruction. So, not to be too heavy-handed with criticism on this library, but I think this should come up to par with solutions like log4j, log4cpp, or log4cxx, with respect to features and capabilities. Libraries like these have enjoyed a lot of very serious use, and once you have something like that in your project, it's hard to not use most of what they have to offer. There's really not a lot of fluff in those solutions. IMO these libraries are to heavy. Especially with phobos inclusion in mind. I agree. A bunch of stuff at Facebook is heavily relying on logging for statistics and debugging, yet we're fine with the relatively scarce API of Google log. That said, I'm clearly biased because I've never used log4xxx. One note - log4j, log4cxx, and log4cpp are not part of the respective languages' standards. That doesn't mean much (in fact it may be a competitive advantage to integrating log4d in std) but it is one factor to consider. Eric, could you please enumerate a short list of features of log4j that you think would be really missed if absent? Andrei
Structured logging (was Early review of std.logger)
I think one increasingly important point for std.log is 'structured logging'. Structured logging is basically not simply logging textual messages, but also logging additional KEY/VALUE pairs of data. The idea is that logs should not only be readable by humans but also easy to parse and analyze. Structured logging often also includes UUIDs to simplify finding similar errors/problems in a log file. For example: Instead of logging logf(Couldn't login as %s on server %s : Reason: %s, user, server, errorCode); we'd do: log(LOGIN_FAILED_UUID, Couldn't log in, [User: user, Server: server, ErrorCode: errorCode]); The log can then be queried for all events with 'LOGIN_FAILED_UUID' uuid, Server=... ErrorCode=42, etc. As a nice benefit structured logging can also log the function, module and line of the source file that logged the message, Exceptions can be written to the log in a nice way, etc. SystemDs journal [1] is a structured replacement for syslog and is already being used on some linux distributions (ArchLinux, Fedora). It's likely that the journal will replace syslog on linux so at least for server-side software structured logging support is becoming important. The GNOME guys are also working on a log viewer for systemd's journal [2]. std.log certainly doesn't need to provide a backend for the journal right now. But some questions regarding structured logging need to taken into account: * Will structured logging be integrated with the normal logging at all? * Will the public API somehow collide with the proposed std.log API? * Should the API for log backends already support structured logging or is it possible to add this later on? Most important: * What to do about structured logging calls when logging to a simple text logger? Ignore the additional fields or serialize them? What about the UUID? Even if we don't have a backend implementation it'd be nice to have the public API available. Otherwise new projects cannot use structured logging with std.log right now and the user code needs to be rewritten once std.log does support structured logging. [1] http://0pointer.de/blog/projects/journalctl.html [2] https://mail.gnome.org/archives/gnome-announce-list/2013-September/msg00097.html
Re: Structured logging (was Early review of std.logger)
On 10/15/2013 05:20 PM, Johannes Pfau wrote: I think one increasingly important point for std.log is 'structured logging'. Structured logging is basically not simply logging textual messages, but also logging additional KEY/VALUE pairs of data. The idea is that logs should not only be readable by humans but also easy to parse and analyze. Structured logging often also includes UUIDs to simplify finding similar errors/problems in a log file. For example: Instead of logging logf(Couldn't login as %s on server %s : Reason: %s, user, server, errorCode); we'd do: log(LOGIN_FAILED_UUID, Couldn't log in, [User: user, Server: server, ErrorCode: errorCode]); The log can then be queried for all events with 'LOGIN_FAILED_UUID' uuid, Server=... ErrorCode=42, etc. As a nice benefit structured logging can also log the function, module and line of the source file that logged the message, Exceptions can be written to the log in a nice way, etc. SystemDs journal [1] is a structured replacement for syslog and is already being used on some linux distributions (ArchLinux, Fedora). It's likely that the journal will replace syslog on linux so at least for server-side software structured logging support is becoming important. The GNOME guys are also working on a log viewer for systemd's journal [2]. std.log certainly doesn't need to provide a backend for the journal right now. But some questions regarding structured logging need to taken into account: * Will structured logging be integrated with the normal logging at all? * Will the public API somehow collide with the proposed std.log API? * Should the API for log backends already support structured logging or is it possible to add this later on? Most important: * What to do about structured logging calls when logging to a simple text logger? Ignore the additional fields or serialize them? What about the UUID? Even if we don't have a backend implementation it'd be nice to have the public API available. Otherwise new projects cannot use structured logging with std.log right now and the user code needs to be rewritten once std.log does support structured logging. [1] http://0pointer.de/blog/projects/journalctl.html [2] https://mail.gnome.org/archives/gnome-announce-list/2013-September/msg00097.html Currently there is no structured logging implemented in std.logger. That been said, you can add it. The method Logger.logf is a variadic template. You can simple create your own Logger Class and overwrite that method and implemented your structured logging approach there. The only pitfall is that you need a ref of type WhateverYourLoggerClassIsCalled and call logf on that or you fall back to the default logf implementation provided by the Logger class. Another way would be to parse the message passed to logMessage and go from there. Long story short. Global default Logger means structured logging requires parsing. All other logger require correct reference type of logger.
Re: Structured logging (was Early review of std.logger)
On Tuesday, 15 October 2013 at 15:53:34 UTC, Robert Schadek wrote: That been said, you can add it. The method Logger.logf is a variadic template. You can simple create your own Logger Class and overwrite that method and implemented your structured logging approach there. The only pitfall is that you need a ref of type WhateverYourLoggerClassIsCalled and call logf on that or you fall back to the default logf implementation provided by the Logger class. Another way would be to parse the message passed to logMessage and go from there. Long story short. Global default Logger means structured logging requires parsing. All other logger require correct reference type of logger. I don't think it is a good design to conflate logging mode with output mode in a single logger class. I'd prefer to see log() as variadic structured logger and logf() as it is now (making conditional logger `logIf()`)
Re: Qt bindings for D
On Tuesday, 15 October 2013 at 09:38:15 UTC, Max Samukha wrote: Long story short, D allows for two approaches to bindings like QtD: 1. The traditional one is to allocate shells on GC heap and have a set of manually specified rules for ownership transfers and reference count adjustments. 2. The other is more interesting - abandon the idea of reference/ownership annotations and go with semi-automatic memory management as it is in Qt, with no reliance on the GC. At some point I wanted to switch to 2 completely, so QtD is somewhere between 1 and 2, quite a mess. This is a really interersting point, and the part of desiging the API I found the most difficult. How do you write an interface for Qt in D that is both polymorphic and avoids memory management problems? For instance, in PyQt and PySide, you can have objects vanish because you didn't keep a reference to them, even though some other part of Qt itself might own a reference to the object. I couldn't think of a way to do it myself which was elegant.
Re: Qt bindings for D
On 10/15/13, w0rp devw...@gmail.com wrote: I couldn't think of a way to do it myself which was elegant. Perhaps you can pin the object and hook into the C++ destructor somehow?
Fastest way to learn D?
What is the fastest way for me to learn D? I think what I want is a syntax reference manual and a good tutorial to learn how to find and use libs.
Re: Fastest way to learn D?
On Tuesday, 15 October 2013 at 18:13:46 UTC, ProgrammingGhost wrote: What is the fastest way for me to learn D? I think what I want is a syntax reference manual and a good tutorial to learn how to find and use libs. The best way to learn D is to start by reading the API and code examples in the online Phobos documentation :o) (Inside joke for Johnathan Davis, I wouldn't actually recommend that). Actually, you might start with Ali's book. http://ddili.org/ders/d.en/index.html One you start that order a copy of Andrei's book: http://erdani.com/index.php/books/tdpl/ which will hopefully arrive in the mail about the time you are done with Ali's book. The is also an under construction tutorial: http://beza1e1.tuxen.de/d-tut-0.1/index.html which looks promising, but is far from complete. Finally, D.learn is a great place to ask newbie questions. Very helpful. http://forum.dlang.org/group/digitalmars.D.learn Best of luck.
Re: Fastest way to learn D?
On Tue, 15 Oct 2013 20:13:45 +0200, ProgrammingGhost wrote: What is the fastest way for me to learn D? I think what I want is a syntax reference manual and a good tutorial to learn how to find and use libs. I learned D by doing two things. 1) Downloading the bundled DMD in a ZIP file. 2) Reading the language reference at http://www.dlang.org (back then it was on DigitalMars website...) That is all you really need. Now I would suggest reading the D Wiki as well. ;)
Re: draft proposal for ref counting in D
On Tuesday, 15 October 2013 at 11:03:01 UTC, Michel Fortin wrote: On 2013-10-15 02:20:49 +, deadalnix deadal...@gmail.com said: It will indeed cause trouble for code that mutate a large amount of shared pointers. I'd say that such code is probably asking for trouble in the first place, but as always, no silver bullet. I still think solution is the one that fit D the best. I think there's a small mistake in your phrasing, but it makes a difference. When the collector is running, it needs to know about any mutation for pointers to its shared memory pool, including pointers that are themselves thread-local but point to shared memory. So COW will be trouble for code that mutate a large amount of **pages containing pointers to shared memory**. And this which includes **pointers to immutable data** because immutable is implicitly shared. And this includes **pointers to const data** since those pointers might point to immutable (thus shared) memory. No, that is the beauty of it :D Consider you have pointer from Tl - shared - immutable and TL - immutable. I'm not covering TL collection here (It seem to be obvious that it doesn't require to stop the world). So the starting point is that we have the roots in all TL heaps/stacks, and we want to collect shared/immutable without blocking the worlds. TL heap may get new pointers to the shared heap, but they can only come from the shared heap itself or new allocations. At this point, you consider every new allocations as live. Reading a pointer from the shared heap and copy it to the TL heap isn't problematic in itself, but then we have a problem if this pointer is now updated in the shared heap, as the GC may never scan this pointer. This is why you need to track pointer writes to the shared heap. The write value itself isn't important : it come from either new alloc that are live, or from somewhere else in the shared heap (so it will be scanned as we track writes). So any memory page susceptible of containing pointers to shared memory would need to use COW during collection. Which means all the thread's stacks, and also all objects with a pointer to shared, immutable, and const data. At this point I think it is fair to approximate this to almost all memory that could contain pointers. No, only the shared one, that is the beauty of the technique. Not that I'm not making that up myself, it is how GC used to work in the Caml family for a while, and it has proven itself really efficient (in Caml family, most data are either immutable or thread local, and the shared heap typically small).
Re: Fastest way to learn D?
On Tuesday, 15 October 2013 at 18:25:48 UTC, Dejan Lekic wrote: On Tue, 15 Oct 2013 20:13:45 +0200, ProgrammingGhost wrote: What is the fastest way for me to learn D? I think what I want is a syntax reference manual and a good tutorial to learn how to find and use libs. I learned D by doing two things. 1) Downloading the bundled DMD in a ZIP file. 2) Reading the language reference at http://www.dlang.org (back then it was on DigitalMars website...) That is all you really need. Now I would suggest reading the D Wiki as well. ;) You really learned D from the online language reference? Thats hard core! You must be much smarter than me. I suggested reading the Phobos docs online, but I was just joking.
Re: Fastest way to learn D?
On Tuesday, 15 October 2013 at 18:25:48 UTC, Dejan Lekic wrote: 2) Reading the language reference at http://www.dlang.org (back then it was on DigitalMars website...) If you want a more accurate version of the language grammar, take a look at this: https://github.com/Hackerpilot/DGrammar/blob/master/D.g4 (And if you find any errors, please create a pull request)
Re: Fastest way to learn D?
You really learned D from the online language reference? Thats hard core! You must be much smarter than me. I suggested reading the Phobos docs online, but I was just joking. Well, that was ~10 years ago... Language reference is still pretty much okay, with more examples, plus we also got nice dlang.org website meanwhile. :) DPaste should also be a good resource for new D programmers. But hey, it is all on D Wiki!!
Re: Fastest way to learn D?
On Tuesday, 15 October 2013 at 18:32:59 UTC, Craig Dillabaugh wrote: On Tuesday, 15 October 2013 at 18:25:48 UTC, Dejan Lekic wrote: On Tue, 15 Oct 2013 20:13:45 +0200, ProgrammingGhost wrote: What is the fastest way for me to learn D? I think what I want is a syntax reference manual and a good tutorial to learn how to find and use libs. I learned D by doing two things. 1) Downloading the bundled DMD in a ZIP file. 2) Reading the language reference at http://www.dlang.org (back then it was on DigitalMars website...) That is all you really need. Now I would suggest reading the D Wiki as well. ;) You really learned D from the online language reference? Thats hard core! You must be much smarter than me. I suggested reading the Phobos docs online, but I was just joking. I did too. I don't see it as particularly hard/only-for-smart-people, I just built simple programs and slowly looked up what I needed as I went along. A lot of help from people here and on IRC helped as well of course.
Re: Fastest way to learn D?
On Tuesday, 15 October 2013 at 18:32:59 UTC, Craig Dillabaugh wrote: You really learned D from the online language reference? Thats hard core! You must be much smarter than me. You know, good old times when it was the only information available about D2, before even TDPL came out.. We literally had no choice! ;)
Re: [Proposal] Weak reference implementation for D
Perhaps I missed it from skimming, but why are we using atomic operations here anyway? Has testing revealed that it's necessary?
Re: Fastest way to learn D?
On Tuesday, 15 October 2013 at 18:36:19 UTC, John Colvin wrote: On Tuesday, 15 October 2013 at 18:32:59 UTC, Craig Dillabaugh wrote: On Tuesday, 15 October 2013 at 18:25:48 UTC, Dejan Lekic wrote: On Tue, 15 Oct 2013 20:13:45 +0200, ProgrammingGhost wrote: What is the fastest way for me to learn D? I think what I want is a syntax reference manual and a good tutorial to learn how to find and use libs. I learned D by doing two things. 1) Downloading the bundled DMD in a ZIP file. 2) Reading the language reference at http://www.dlang.org (back then it was on DigitalMars website...) That is all you really need. Now I would suggest reading the D Wiki as well. ;) You really learned D from the online language reference? Thats hard core! You must be much smarter than me. I suggested reading the Phobos docs online, but I was just joking. I did too. I don't see it as particularly hard/only-for-smart-people, I just built simple programs and slowly looked up what I needed as I went along. A lot of help from people here and on IRC helped as well of course. There is a lot of good information in the language reference, but I just remember it didn't feel very welcoming to someone new to the language. It does show how to use the different parts, but it is sort of hard to figure out what a proper D progam should look like from all that. But as Dicebot pointed out, it wasn't all that long ago that there were not many other options.
Re: Fastest way to learn D?
On Tuesday, 15 October 2013 at 18:29:21 UTC, Craig Dillabaugh wrote: The is also an under construction tutorial: http://beza1e1.tuxen.de/d-tut-0.1/index.html which looks promising, but is far from complete. As an addendum, this one is a neat example of how things can come together in real code: http://wiki.dlang.org/Component_programming_with_ranges Shows off ranges and some other nifty features. -Wyatt
D bindings for OpenCV
I know this has been asked a few times before, but that was a few years ago. Are there any reasonably complete and up to date OpenCV bindings for D? If not, are there any reasonably easy ways to generate them? I tried SWIG and it choked on some of the macros they used, though that may have been because I had no idea what I was doing.
Re: D bindings for OpenCV
On Tuesday, 15 October 2013 at 19:20:10 UTC, TJSomething wrote: I know this has been asked a few times before, but that was a few years ago. Are there any reasonably complete and up to date OpenCV bindings for D? If not, are there any reasonably easy ways to generate them? I tried SWIG and it choked on some of the macros they used, though that may have been because I had no idea what I was doing. Dammit, when I saw the title I thought someone was announcing they'd made one. I don't know of anyone.
Re: [Proposal] Weak reference implementation for D
On Tuesday, 15 October 2013 at 18:57:16 UTC, Sean Kelly wrote: Perhaps I missed it from skimming, but why are we using atomic operations here anyway? Has testing revealed that it's necessary? I presume you don't mean running some code and then seeing if it breaks as a test to see if atomic operation are necessary? Synchronisation *must* be done by design.
Re: Fastest way to learn D?
On 10/15/2013 08:13 PM, ProgrammingGhost wrote: What is the fastest way for me to learn D? I think what I want is a syntax reference manual and a good tutorial to learn how to find and use libs. I would suggest to write a compiler for D in D. Helped me alot, but I still learning new stuff. More seriously, learn C than add some java and some c++ templates and than writing D is how you want to be written.
Re: dub repository for a C binding
On Friday, 11 October 2013 at 10:57:38 UTC, Sönke Ludwig wrote: Am 11.10.2013 11:25, schrieb Sebastian Graf: On Thursday, 10 October 2013 at 01:51:09 UTC, Rikki Cattermole wrote: Take a look at copyFiles option. It copies files e.g. dll's into the bin directory when compiled. Although keep an option available in e.g. a subpackage that does not do this. For more information on what dub can do look at http://code.dlang.org/package-format. And how would I go about the import lib? I have to somehow feed it into the compiler, preferably automatically when referencing the (sub-)package. Right now you have to use the sourceFiles field for that. Later it should be possible to set a library search path + library name instead. Example: https://github.com/s-ludwig/dlibgit/blob/master/package.json Thanks, that's what I do now for copying the libraries into the bin directory.
Re: Fastest way to learn D?
On Tuesday, 15 October 2013 at 18:13:46 UTC, ProgrammingGhost wrote: What is the fastest way for me to learn D? I think what I want is a syntax reference manual and a good tutorial to learn how to find and use libs. Ali's book is especially targeted at beginners : http://ddili.org/ders/d.en/index.html It is really good. Also as other suggested, download the compiler/libs use dlang.org website and try to code some stuffs.
Re: dub repository for a C binding
On Friday, 11 October 2013 at 10:57:56 UTC, Sebastian Graf wrote: On Friday, 11 October 2013 at 09:25:58 UTC, Sebastian Graf wrote: On Thursday, 10 October 2013 at 01:51:09 UTC, Rikki Cattermole wrote: Take a look at copyFiles option. It copies files e.g. dll's into the bin directory when compiled. Although keep an option available in e.g. a subpackage that does not do this. For more information on what dub can do look at http://code.dlang.org/package-format. And how would I go about the import lib? I have to somehow feed it into the compiler, preferably automatically when referencing the (sub-)package. Nevermind, I'll see how far I get with dynamically loaded derelict binding. This works surprisingly well. I uploaded my derelict binding on github: https://github.com/sgraf812/DerelictUdis86.git Where else should I announce this?
Re: [Proposal] Weak reference implementation for D
On Tuesday, 15 October 2013 at 19:51:00 UTC, John Colvin wrote: On Tuesday, 15 October 2013 at 18:57:16 UTC, Sean Kelly wrote: Perhaps I missed it from skimming, but why are we using atomic operations here anyway? Has testing revealed that it's necessary? I presume you don't mean running some code and then seeing if it breaks as a test to see if atomic operation are necessary? Synchronisation *must* be done by design. Well sure, but why not use a Mutex? What does trying to sort out a correct lock-free algorithm gain us here?
Re: dub repository for a C binding
Am 15.10.2013 22:11, schrieb Sebastian Graf: On Friday, 11 October 2013 at 10:57:56 UTC, Sebastian Graf wrote: On Friday, 11 October 2013 at 09:25:58 UTC, Sebastian Graf wrote: On Thursday, 10 October 2013 at 01:51:09 UTC, Rikki Cattermole wrote: Take a look at copyFiles option. It copies files e.g. dll's into the bin directory when compiled. Although keep an option available in e.g. a subpackage that does not do this. For more information on what dub can do look at http://code.dlang.org/package-format. And how would I go about the import lib? I have to somehow feed it into the compiler, preferably automatically when referencing the (sub-)package. Nevermind, I'll see how far I get with dynamically loaded derelict binding. This works surprisingly well. I uploaded my derelict binding on github: https://github.com/sgraf812/DerelictUdis86.git Where else should I announce this? Register an account on code.dlang.org and click on Manage my packages below the package list to add your repository (the UI is a bit crude right now but will be improved soon).
