Re: Funny coverage of the recent reddit/hackernews chatter
Am 15.10.2013 23:17, schrieb Iain Buclaw: 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. This one seems to be more interesting: http://www.google.com/trends/explore?q=dlang#q=dlangcmpt=q
Re: Funny coverage of the recent reddit/hackernews chatter
On Wednesday, 16 October 2013 at 07:52:06 UTC, Sönke Ludwig wrote: Am 15.10.2013 23:17, schrieb Iain Buclaw: 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. This one seems to be more interesting: http://www.google.com/trends/explore?q=dlang#q=dlangcmpt=q Another funny thing: I couldn't get the page to work in Chromium and had to use FF :)
Re: Funny coverage of the recent reddit/hackernews chatter
On 2013-10-16 10:01, simendsjo wrote: Another funny thing: I couldn't get the page to work in Chromium and had to use FF :) Did you try Chrome :) -- /Jacob Carlborg
Re: Pragmatic D Tutorial
On Sunday, 13 October 2013 at 08:23:16 UTC, Tourist wrote: On Saturday, 12 October 2013 at 23:34:11 UTC, qznc wrote: On Monday, 7 October 2013 at 22:39:26 UTC, qznc wrote: On Monday, 7 October 2013 at 20:36:46 UTC, Andrei Alexandrescu OP: any chance to adjust that page? Then we'll announce to reddit. Too early for more publicity, I think. Now every chapter has some text. Feel free to publicize it. A small issue: http://qznc.github.io/d-tut/meta.html The width of the code in String Mixins overflows under the menu. Also, I liked the previous design more, with some orange. Same here: http://qznc.github.io/d-tut/optimization.html
Re: Unstandard, a general purpose library
On Saturday, 12 October 2013 at 14:21:12 UTC, Denis Shelomovskij wrote: *Unstandard* is a library for general purpose usage aimed to be an addition to the *D* standard runtime library *Phobos*. The author would like to pull as much functionality as possible to Phobos but it's a rather difficult and slow work. Good luck. It will be great to see additional functions in Phobos.
Re: Mono-D 0.5.4.1 - Build, completion other fixes + Unittests via rdmd
On 08/10/2013 14:18, Alexander Bothe wrote: Are there any plans/tricks/hacks on how to get programs built with dmd debuggable with gdb? Then we also could release the addin for Windows as well! (Afaik I asked the same question some time ago, but well, perhaps something did change over the time :-)) I was wondering the same as well... But from the lack of answers I think not much can be done? :/ -- Bruno Medeiros - Software Engineer
Re: Mono-D 0.5.4.1 - Build, completion other fixes + Unittests via rdmd
On Wednesday, 16 October 2013 at 12:38:40 UTC, Bruno Medeiros wrote: On 08/10/2013 14:18, Alexander Bothe wrote: Are there any plans/tricks/hacks on how to get programs built with dmd debuggable with gdb? Then we also could release the addin for Windows as well! (Afaik I asked the same question some time ago, but well, perhaps something did change over the time :-)) I was wondering the same as well... But from the lack of answers I think not much can be done? :/ Well I do debug `dmd -gc` programs with gdb relatively frequently. What exactly is of interest?
Re: Start of dmd 2.064 beta program
On 10/16/13, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: What are you protesting against? Walter.
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 Hum I have several regression is SDC's test suite. I have to investigate more to fix the code or submit bug report. It looks related to AA. What are the changes that affect AA in this new release ?
Re: Start of dmd 2.064 beta program
On Wednesday, 16 October 2013 at 13:34:04 UTC, Andrej Mitrovic wrote: On 10/16/13, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: What are you protesting against? Walter. The last change log was awesome. I vote to get rid of Walter. :)
code.dlang.org now supports categories and search
The DUB package registry [1] has finally gained support for the text and category based search of packages. There is also a category for D standard library candidate modules, as has been suggested recently. If you already have any registered packages, please log in and add the proper categories to each of them (My packages - click on package name). Should there be no exact category match, and that specific category is likely to have multiple entries in the future, please make a corresponding pull request against the category file [2] on GitHub. It's still all a little rough around the edges. Any bugs can be reported on the issue tracker [3] or discussed in the forum [4]. [1]: http://code.dlang.org [2]: https://github.com/rejectedsoftware/dub-registry/blob/master/categories.json [3]: https://github.com/rejectedsoftware/dub-registry/issues [4]: http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/
Re: Facebook is using D in production starting today
On Friday, 11 October 2013 at 00:36:12 UTC, Andrei Alexandrescu wrote: Today I committed the first 5112 lines of D code to Facebook's repository. The project is in heavy daily use at Facebook. Compared to the original version (written in C++) we've measured massive wins in all of source code size, build speed, and running speed. In all likelihood we'll follow up with a blog post describing the process. Andrei This is nice to know. Any estimate on when is that blog post coming out?
Re: code.dlang.org now supports categories and search
On Wednesday, 16 October 2013 at 19:01:45 UTC, Sönke Ludwig wrote: If you already have any registered packages, please log in and add the proper categories to each of them (My packages - click on package name). Should there be no exact category match, and that specific category is likely to have multiple entries in the future, please make a corresponding pull request against the category file [2] on GitHub. It's still all a little rough around the edges. Any bugs can be reported on the issue tracker [3] or discussed in the forum [4]. Great! But I think the eloty categories must go until needed.
Re: code.dlang.org now supports categories and search
On Wednesday, 16 October 2013 at 19:23:54 UTC, ponce wrote: Great! But I think the eloty categories must go until needed. I meant empty.
Re: code.dlang.org now supports categories and search
Am 16.10.2013 21:24, schrieb ponce: On Wednesday, 16 October 2013 at 19:23:54 UTC, ponce wrote: Great! But I think the eloty categories must go until needed. I meant empty. https://github.com/rejectedsoftware/dub-registry/issues/21
Re: code.dlang.org now supports categories and search
On 10/16/13, Sönke Ludwig slud...@outerproduct.org wrote: It's still all a little rough around the edges. Any bugs can be reported on the issue tracker [3] or discussed in the forum [4]. [1]: http://code.dlang.org [2]: https://github.com/rejectedsoftware/dub-registry/blob/master/categories.json [3]: https://github.com/rejectedsoftware/dub-registry/issues [4]: http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/ Not necessarily a bug, but when you search for dlib, you only get one result, dlib (dlibgit is missing). I've tried using dlib* but that didn't work either. I think the search engine should try to be a little more lax and show partial matches too.
Re: Start of dmd 2.064 beta program
On 10/16/13 6:33 AM, Andrej Mitrovic wrote: On 10/16/13, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: What are you protesting against? Walter. That's not a what, that's a who. Would you please elaborate on the what and why? I haven't seen any obstructionism coming from anyone in terms of repeating the previous style for this releases notes.
Re: Start of dmd 2.064 beta program
On Wednesday, 16 October 2013 at 20:19:17 UTC, Brad Roberts wrote: That's not a what, that's a who. Would you please elaborate on the what and why? I haven't seen any obstructionism coming from anyone in terms of repeating the previous style for this releases notes. Originally Walter thought it was enough to just list the bugzilla issues. -- /Jacob Carlborg
Re: Funny coverage of the recent reddit/hackernews chatter
On Tuesday, October 15, 2013 10:48:12 Andrei Alexandrescu wrote: http://www.fastcolabs.com/3019948/more-about-d-language-and-why-facebook-is- experimenting-with-it I was not expecting to be quoted from there. Well, it's sometimes surprising where stuff pops up. At least I didn't get quoted for saying something stupid. :) - Jonathan M Davis
Re: Start of dmd 2.064 beta program
On Wednesday, October 16, 2013 22:28:41 Jacob Carlborg wrote: On Wednesday, 16 October 2013 at 20:19:17 UTC, Brad Roberts wrote: That's not a what, that's a who. Would you please elaborate on the what and why? I haven't seen any obstructionism coming from anyone in terms of repeating the previous style for this releases notes. Originally Walter thought it was enough to just list the bugzilla issues. Yes, but after Andej did the great changelog for 2.063, Walter publicly admitted that he had been wrong about the changelog. Andrej showed Walter that it _is_ worth doing something more than just a list of bugzilla issues. So, I would assume that whatever Andrej is unhappy with Walter for is something else. - Jonathan M Davis
Re: Start of dmd 2.064 beta program
On Wednesday, 16 October 2013 at 20:28:42 UTC, Jacob Carlborg wrote: On Wednesday, 16 October 2013 at 20:19:17 UTC, Brad Roberts wrote: That's not a what, that's a who. Would you please elaborate on the what and why? I haven't seen any obstructionism coming from anyone in terms of repeating the previous style for this releases notes. Originally Walter thought it was enough to just list the bugzilla issues. -- /Jacob Carlborg He was proved wrong and IIRC correctly quite graciously admitted defeat.
Re: Facebook is using D in production starting today
On 10/16/13 12:12 PM, Pedro Rodrigues wrote: On Friday, 11 October 2013 at 00:36:12 UTC, Andrei Alexandrescu wrote: Today I committed the first 5112 lines of D code to Facebook's repository. The project is in heavy daily use at Facebook. Compared to the original version (written in C++) we've measured massive wins in all of source code size, build speed, and running speed. In all likelihood we'll follow up with a blog post describing the process. Andrei This is nice to know. Any estimate on when is that blog post coming out? Not yet. I'm scrambling to hit the proverbial iron while it's hot, and blogging had to give priority to that. I estimate a couple more weeks before I have something out. Thanks for the interest. Andrei
Re: Mono-D 0.5.4.1 - Build, completion other fixes + Unittests via rdmd
On 10/16/13 5:38 AM, Bruno Medeiros wrote: On 08/10/2013 14:18, Alexander Bothe wrote: Are there any plans/tricks/hacks on how to get programs built with dmd debuggable with gdb? Then we also could release the addin for Windows as well! (Afaik I asked the same question some time ago, but well, perhaps something did change over the time :-)) I was wondering the same as well... But from the lack of answers I think not much can be done? :/ What are the matters involved? I did get basic debugging sessions working, but I forgot whether it was dmd or gdc. Andrei
Re: Start of dmd 2.064 beta program
On 10/16/13 2:16 PM, Jonathan M Davis wrote: On Wednesday, October 16, 2013 22:28:41 Jacob Carlborg wrote: On Wednesday, 16 October 2013 at 20:19:17 UTC, Brad Roberts wrote: That's not a what, that's a who. Would you please elaborate on the what and why? I haven't seen any obstructionism coming from anyone in terms of repeating the previous style for this releases notes. Originally Walter thought it was enough to just list the bugzilla issues. Yes, but after Andej did the great changelog for 2.063, Walter publicly admitted that he had been wrong about the changelog. Andrej showed Walter that it _is_ worth doing something more than just a list of bugzilla issues. So, I would assume that whatever Andrej is unhappy with Walter for is something else. Oh that was it? I recall Walter and I discussing two unrelated issue (null pointers and VMs) where I sort of reversed my view and admitted I considered my previous opinions wrong. He mentioned the changelog, and said boy was I wrong about that! So Andrej consider yourself vindicated, in public and in private. Andrei
Re: Start of dmd 2.064 beta program
On Wednesday, 16 October 2013 at 20:28:42 UTC, Jacob Carlborg wrote: On Wednesday, 16 October 2013 at 20:19:17 UTC, Brad Roberts wrote: That's not a what, that's a who. Would you please elaborate on the what and why? I haven't seen any obstructionism coming from anyone in terms of repeating the previous style for this releases notes. Originally Walter thought it was enough to just list the bugzilla issues. -- /Jacob Carlborg http://forum.dlang.org/thread/ko84eb$1kfo$1...@digitalmars.com
Re: Start of dmd 2.064 beta program
On 10/16/2013 6:33 AM, Andrej Mitrovic wrote: On 10/16/13, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: What are you protesting against? Walter. I'll go have myself flogged, then.
Re: Start of dmd 2.064 beta program
Walter Bright: I'll go have myself flogged, then. But please be gentle and use something soft, like a fake snow leopard tail: http://img.photobucket.com/albums/v310/musta.surma/Hpim4850.jpg Bye, bearophile
NWCPP tonight!
Date: Wednesday October 16, 2013 Time: 7:00 PM Location: Microsoft Eastside Campus, Bldg. 41, Room 1511 / Townsend (see our website www.nwcpp.org for directions). Title: New Adventures in C++ with Cinder and More Be there or be square.
Re: code.dlang.org now supports categories and search
Am 16.10.2013 21:58, schrieb Andrej Mitrovic: On 10/16/13, Sönke Ludwig slud...@outerproduct.org wrote: It's still all a little rough around the edges. Any bugs can be reported on the issue tracker [3] or discussed in the forum [4]. [1]: http://code.dlang.org [2]: https://github.com/rejectedsoftware/dub-registry/blob/master/categories.json [3]: https://github.com/rejectedsoftware/dub-registry/issues [4]: http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/ Not necessarily a bug, but when you search for dlib, you only get one result, dlib (dlibgit is missing). I've tried using dlib* but that didn't work either. I think the search engine should try to be a little more lax and show partial matches too. I agree, that should probably count as one of the rough edges ;) Currently it uses a crude old way of doing text search for old versions of MongoDB, but in the latest versions they have much better means. I'll look into it.
Git disaster recovery
http://sethrobertson.github.io/GitFixUm/fixup.html I need to tape this to the wall!
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
On Tuesday, 15 October 2013 at 22:31:06 UTC, Paulo Pinto wrote: Am 16.10.2013 00:15, schrieb Walter Bright: http://www.reddit.com/r/programming/comments/1oi8wd/ruby_is_a_dying_language/ccs8yr8 Agree. While I do like dynamic languages for prototyping and small applications, I came to the conclusion they don't scale in the enterprise. (...) Haven't tried Ruby, but I switched from Python to D because of static typing and speed back in 2007. Why on earth should someVariable = 1 # And then in some seldom-executed branch.. somevariable = 2 give me hard to track bugs? Even lua requires you to say I'm creating a *new* variable now. And a compiler that doesn't do simple optimizations? for x in range(0,10): i = x*x # do something with i ^ - might be painfully slow. You should of course code like a compiler and create i outside the loop! And no types means I have to read the source for every method to see what types it actually expects. Dynamic typing does not mean you don't have types to care about, it just means the types are hidden from sight and cause bugs at runtime. I will never again code in a dynamic language if I can avoid it. All the advantages of dynamic typing simply doesn't exist for anything other than small/trivial programs in my experience. No.. Give me a language that catches obvious bugs at compile-time, makes code self-documenting and doesn't let me worry about performance. Of course.. It might just be that I don't get dynamic typing :)
Re: Qt bindings for D
On 2013-10-15 17:55, w0rp wrote: 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. In D, using the GC, you can call GC.addRoot to avoid that problem. -- /Jacob Carlborg
Re: Early review of std.logger
On 2013-10-15 16:13, Dicebot wrote: 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 don't see why this couldn't be included in Phobos, if it doesn't have any external dependencies. -- /Jacob Carlborg
Re: Help needed testing automatic win64 configuration
On 16.10.2013 04:45, Manu wrote: I just tried your '-3' version. It has problems. 1: VisualD installer still asks where you installed DMD; it should be able to know this since it's being invoked by the DMD installer.. I think that should be fixed. I have not yet updated the Visual D installer to pick up the setting. Will do. 2: gcstub64.obj and phobos64.lib are still in D/dmd2/windows/lib. They should be moved to lib64/ We are trying to talk Walter into doing this but it seems there are topics that fail to gain traction. 3: sc.ini contains: LIB=%@P%\...\lib64;%@P%\..\lib - why is '../lib/' still present in [Environment64]? That should be removed, it can only lead to erroneous attempts to link the OMF libs. Rather have a can't find lib error, than a weird lib format error that most programmers won't understand. Sure, that should be done when the 64 bit files are moved to their own folder. 4: It fails to find the Microsoft libs. Here is the relevant parts of my sc.ini as installed by the installer: LIB=%@P%\..\lib64;%@P%\..\lib search path for C Runtime libraries ; the following lib path works with VS2008, VS2010, VS2012, VS2013 ; prepending because 32-bit OMF versions can cause link.exe to fail LIB=C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\lib\amd64;%LIB% search path for Platform libraries ; the following lib path works with Windows SDK 6.x and 7.x LIB=C:\Program Files (x86)\Windows Kits\8.0\lib\winv6.3\um\x64;%LIB% ; the following lib path works with Windows SDK 8.0 and 8.1 LIB=%WindowsSdkDir%Lib\win8\um\x64;%LIB% I have VS2010 and VS2012 installed on a Win8 machine. I have libs in these locations: C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Lib\x64 - this one seems to be unknown to the installer. These libs should be used in conjunction with VS2010. C:\Program Files (x86)\Windows Kits\8.0\Lib\win8\um\x64 - the installer refers to %WindowsSdkDir%, which is not present on my system. Use the absolute path instead? These libs are to use used in conjunction with VS2012. C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\lib\amd64 - runtime libs, how to pick which version? Prompt during installation? C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\lib\amd64 - runtime libs, how to pick which version? Prompt during installation? I should note that I think VisualD needs to do some work here too. VisualD should override the linker and lib paths, since it has more information. Ie, how does cmdline DMD choose which linker/runtime libs to use? Perhaps a prompt during installation? Choose the newest (appears to be the current behaviour). Whereas VisualD will be running inside of an instance of either VS2010 or VS2012 (I use both, this is very common practise) on my machine, and it should configure the linker and lib paths appropriately for the version of VisualStudio currently in use when building, otherwise there will be link troubles against C/C++ libraries also being built in the same solution (yes, it's common to have C/C++ and D in the same solution). The installer tries to pick the latest version of both VS and SDK installations. I see there is a problem when selecting a different C runtime than what your C/C++ code is assuming. Is the Windows-SDK a problem, too? The files used are just import libraries, so the latest should be fine as long as you don't need linker errors when you build an application to be run on XP but are calling Win8 only functions. For clarity, on my system, when using the VS2010 compiler, it should use these lib paths: runtime libs: C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\lib\amd64 windows libs: C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Lib\x64- AFAIK, Microsoft SDKs is the old location, installed with VS2010 and earlier. When using the VS2012 compiler, it should use these paths: runtime libs: C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\lib\amd64 windows libs: C:\Program Files (x86)\Windows Kits\8.0\Lib\win8\um\x64 - Windows Kits is the new location, by versions VS2010 (AFAIK). The default installation of DMD using your new installer fails to link on my machine because %WindowsSdkDir% is not defined on my system, and since the 32bit dmd lib path is still present, it tries to link the OMF libs, and complains a lot. It seems the installer failed to replace two occurences of %WindowsSdkDir%. WindowsSdkDir is set by batch files vsvars32.bat and friends. I see conflicting goals here: 1. the installer expands variables WindowsSdkDir and VCINSTALLDIR in sc.ini to work without running vsvars32.bat. It has to make decisions on what versions to pick up. 2. when running dmd by Visual D you want to select settings according to the current Visual Studio, which means it needs the unexpanded variables. The current option to allow both is to not run the linker through dmd, but invoke it manually. Elsewhere in the file, you detect
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: 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 Disagree. We need a log rotation support. As I can see, available options could be: * rotating conditions - by date (rotate every hour, day (default), week, month, year) - by file size (rotate if file size more than ... Mb) - by count log lines (rotate if log contains more than ... log lines) - combination of previous conditions (for example, rotate every day or rotate if file size more than 100 Mb) * file names after rotation - by numbers (my.log, my.log.0, my.log.1, ...) - by ISO date and time (my-2013-10-16-00-00-00.log) * ability to use system log rotation utility
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
On 2013-10-16 02:45, Adam Wilson wrote: +1 This is why I claw my eyes out every time I have to work with JavaScript. This is why I find statically typed languages to so much more powerful for the work I do One big difference between Ruby and JavaScript is that when something fails in Ruby you'll get an exception. But with JavaScript it just silently fails and all your scripts on the site dies. -- /Jacob Carlborg
Re: Qt bindings for D
On Wednesday, 16 October 2013 at 06:53:24 UTC, Jacob Carlborg wrote: In D, using the GC, you can call GC.addRoot to avoid that problem. Yes, I was thinking of using core.memory stuff to stop things from being collected, or perhaps scan inside Qt memory. For instance, you could store a class pointer inside of a QObject with setProperty. One option is to have QObject in D hold an array of pointers for keeping references to children, etc. There are some tricky parts. --- // Okay, this is a root object, when do we collect this? auto widget = new QWidget(); // This is just a free object, not attached to anything. // Clearly we can collect this. auto label = new QLabel(Hello!); auto layout = new QHBoxLayout; layout.addWidget(label); // Wait, now label implicitly becomes a child object of widget. // its memory is now managed by that, so when do we collect it? widget.setLayout(layout); // Does this work? assert(label.parent is widget); --- So in other words, I haven't yet reached a point where I think, Yes, I have covered every case and I'm happy.
Re: Early review of std.logger
On 10/16/2013 01:34 AM, Jeremy Powers wrote: On Tue, Oct 15, 2013 at 8:17 AM, Andrei Alexandrescu seewebsiteforem...@erdani.org mailto:seewebsiteforem...@erdani.org wrote: 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. It also gave rise to slf4j, to tie the various (java) logging solutions together. From a core library standpoint, the slf4j model might be a good one to emulate - provide a basic logging abstraction that can then be plumbed to whichever logging implementation is needed. Logback is essentially the logging framework written by the slf4j guys, which is why I used it as an example. And though I am not Eric, I do have a short list. These are things that log4j/slf4j/etc provide that I'd consider required of any log framework before I use it in a production* environment: Multiple log destinations (sinks/appenders), configurable. - required for logging to file, syslog, etc as appropriate - different running instances of same code may need different log names/locations/appenders MultiLogger is planed. Hierarchical logs, with inheritance of levels, configure at runtime. Turn on/off log level for part of hierarchy. - for debugging own code without being overwhelmed with log statements from elsewhere - turn off extraneous logging in dependencies, or turn it on for deep diving no hierarchical logs, KISS just create a logger with different destination. new FileLogger(myDevLog); $ tail -f myDevLog Configurable log ouput with custom fields (time, thread, etc). - required for making log output match predefined formats - include needed metadata in the log line I think this has been discussed twice already, no configuration can anticipate all possible needs and will fail fast and hard. So why try, I rather write 7 lines, than wait for a patch to the configuration parser to appear in my production env. Allow 'lazy' evaluation/formatting of log output (parameterized logging equivalent). - no performance excuse not to log Log rotation - if this isn't there out of the box, guarantee will be first customization see above argument * where 'production' is biased towards high availability services
Re: Inconsitency
On Tuesday, 15 October 2013 at 14:11:37 UTC, Kagamin wrote: 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. Most code might be buggy then. An issue the often comes up is file names. A file called bär will be normalized differently depending on the operating system. In both cases it is one grapheme. However, on Linux it is one code point, but on OS X it is two code points.
Re: Git disaster recovery
On Wednesday, 16 October 2013 at 06:47:52 UTC, Walter Bright wrote: http://sethrobertson.github.io/GitFixUm/fixup.html I need to tape this to the wall! Just remember, there is always reflog. ;) Git does not garbage collect anything, which is not at least 30 days old.
Re: Inconsitency
On Wednesday, 16 October 2013 at 08:03:26 UTC, qznc wrote: On Tuesday, 15 October 2013 at 14:11:37 UTC, Kagamin wrote: 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. Most code might be buggy then. An issue the often comes up is file names. A file called bär will be normalized differently depending on the operating system. In both cases it is one grapheme. However, on Linux it is one code point, but on OS X it is two code points. Now that you mention it, I had a program that would send strings to a socket written in D. Before I could process the strings on OS X, I had to normalize the decomposed OS X version of the strings to the composed form that D could handle, else it wouldn't work. I used libutf8proc for it (only one tiny little function). It was no problem to interface to the C library, however, I thought it would have been nice, if D could've handled this on its own without depending on third party libraries.
Re: Inconsitency
On Wednesday, 16 October 2013 at 08:48:30 UTC, Chris wrote: On Wednesday, 16 October 2013 at 08:03:26 UTC, qznc wrote: On Tuesday, 15 October 2013 at 14:11:37 UTC, Kagamin wrote: 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. Most code might be buggy then. An issue the often comes up is file names. A file called bär will be normalized differently depending on the operating system. In both cases it is one grapheme. However, on Linux it is one code point, but on OS X it is two code points. Now that you mention it, I had a program that would send strings to a socket written in D. Before I could process the strings on OS X, I had to normalize the decomposed OS X version of the strings to the composed form that D could handle, else it wouldn't work. I used libutf8proc for it (only one tiny little function). It was no problem to interface to the C library, however, I thought it would have been nice, if D could've handled this on its own without depending on third party libraries. I'm not sure this is a D issue though: It's a fact of unicode that there are two different ways to write ä.
Re: D bindings for OpenCV
On Tuesday, 15 October 2013 at 21:51:06 UTC, Timothee Cour wrote: I've done it using swig, and using C++ api (not C api), as well as for other libs (sfml etc). it requires a bit of tweaking the '.i' file but is doable. Much better than hand maintaining c wrappers. Link? Or at least a how-to? This would be a really valuable asset, the C++ api is a LOT nicer to work with than the C one. Plus IIRC new features are no longer always available via the C API.
Re: Inconsitency
On Wednesday, 16 October 2013 at 09:00:01 UTC, monarch_dodra wrote: On Wednesday, 16 October 2013 at 08:48:30 UTC, Chris wrote: On Wednesday, 16 October 2013 at 08:03:26 UTC, qznc wrote: On Tuesday, 15 October 2013 at 14:11:37 UTC, Kagamin wrote: 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. Most code might be buggy then. An issue the often comes up is file names. A file called bär will be normalized differently depending on the operating system. In both cases it is one grapheme. However, on Linux it is one code point, but on OS X it is two code points. Now that you mention it, I had a program that would send strings to a socket written in D. Before I could process the strings on OS X, I had to normalize the decomposed OS X version of the strings to the composed form that D could handle, else it wouldn't work. I used libutf8proc for it (only one tiny little function). It was no problem to interface to the C library, however, I thought it would have been nice, if D could've handled this on its own without depending on third party libraries. I'm not sure this is a D issue though: It's a fact of unicode that there are two different ways to write ä. My point was it would have been nice to have a native D function that can convert between the two types, especially because this is a well known issue. NSString (Cocoa / Objective-C) for example has things like precomposedStringWithCompatibilityMapping etc.
Re: Inconsitency
On Wednesday, 16 October 2013 at 09:00:01 UTC, monarch_dodra wrote: On Wednesday, 16 October 2013 at 08:48:30 UTC, Chris wrote: On Wednesday, 16 October 2013 at 08:03:26 UTC, qznc wrote: On Tuesday, 15 October 2013 at 14:11:37 UTC, Kagamin wrote: 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. Most code might be buggy then. An issue the often comes up is file names. A file called bär will be normalized differently depending on the operating system. In both cases it is one grapheme. However, on Linux it is one code point, but on OS X it is two code points. Now that you mention it, I had a program that would send strings to a socket written in D. Before I could process the strings on OS X, I had to normalize the decomposed OS X version of the strings to the composed form that D could handle, else it wouldn't work. I used libutf8proc for it (only one tiny little function). It was no problem to interface to the C library, however, I thought it would have been nice, if D could've handled this on its own without depending on third party libraries. I'm not sure this is a D issue though: It's a fact of unicode that there are two different ways to write ä. As I argued previously, it is implementation issue which treats bär is sequence of objects which are not capable of representing values (like int[] = [3.14]). By the way, it is a rare case of type system hole. Usually in D you need cast or union to reinterpret some value, with bär[X] you need not.
Re: Qt bindings for D
On Wednesday, 16 October 2013 at 07:25:08 UTC, w0rp wrote: On Wednesday, 16 October 2013 at 06:53:24 UTC, Jacob Carlborg wrote: In D, using the GC, you can call GC.addRoot to avoid that problem. Yes, I was thinking of using core.memory stuff to stop things from being collected, or perhaps scan inside Qt memory. For instance, you could store a class pointer inside of a QObject with setProperty. One option is to have QObject in D hold an array of pointers for keeping references to children, etc. There are some tricky parts. --- // Okay, this is a root object, when do we collect this? auto widget = new QWidget(); // This is just a free object, not attached to anything. // Clearly we can collect this. auto label = new QLabel(Hello!); auto layout = new QHBoxLayout; layout.addWidget(label); // Wait, now label implicitly becomes a child object of widget. // its memory is now managed by that, so when do we collect it? widget.setLayout(layout); // Does this work? assert(label.parent is widget); --- So in other words, I haven't yet reached a point where I think, Yes, I have covered every case and I'm happy. I've ended up with a system that would not allocate Qt objects on the GC heap at all: // This would be destroyed at the end of the scope, auto widget = scoped!QWidget; // Or, if we allocate the object on heap, we should care // to destroy it unless Qt takes ownership at some point after // construction. auto widget = make!QWidget; ... dispose(widget); auto widget = make!QLabel(Hello!); auto layout = make!QHBoxLayout; // Safe to pass ownership to parent because no GC is involved. layout.addWidget(label); // ditto widget.setLayout(layout); // This would work because references to polymorphic Qt objects are // implemented as tagged pointers, and in this case // both references would point to the same C++ object. assert(label.parent is widget); In other words, you manage memory the same way you do in Qt. Advantages: - Noticeable simplification of the generator and bindings. - Performance - no redundant copies, hash lookups, etc. - Fewer problems with multithreading. Disadvantages: - You have to be as careful about memory management as you are in Qt. - Implementation requires a debugged D compiler, which does not exist yet. :) An interesting endeavor would be to figure out whether things could be simplified with interface(C++).
Re: [Proposal] Weak reference implementation for D
16.10.2013 3:20, Sean Kelly пишет: On Tuesday, 15 October 2013 at 22:09:17 UTC, Robert wrote: The problem is that destructors and thus the registered hooks for the dispose events are called when threads are already resumed. If this wasn't the case there would actually be no problems. Gotcha. Looking at the code... I think you'll get this to work, but manipulating such user-mode weak references seems really expensive. Why not work on a DIP to get them built in? For example, one option might be to have the GC perform certain types of finalization while the world is stopped. This would have to be limited to very rudimentary stuff, and the easiest way to guarantee that would be to have everything live in Druntime. But someone have to do it. And I can only see it will save one of two GC lock/unlock pairs. -- Денис В. Шеломовский Denis V. Shelomovskij
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
On 10/16/2013 08:46 AM, simendsjo wrote: No.. Give me a language that catches obvious bugs at compile-time, makes code self-documenting and doesn't let me worry about performance. ... Why just obvious bugs?
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
On Wednesday, 16 October 2013 at 10:37:28 UTC, Timon Gehr wrote:
On 10/16/2013 08:46 AM, simendsjo wrote:
No.. Give me a language that catches obvious bugs at
compile-time, makes
code self-documenting and doesn't let me worry about
performance.
...
Why just obvious bugs?
Hehe. Sure - let the compiler catch *all* my bugs!
scope, const, immutable, pure, nothrow, safe, ... D makes it
harder to shoot yourself in the foot, but you are aiming at your
foot by default..
Too bad I have to add a lot of annotations
void f(Class i) {}
to
void f(in Class i) const pure nothrow @safe {}
I would rather have to write
void f(@(mutable, escapes) Class i) @(impure mutable throws
unsafe) {}
If @mutable and @impure existed, I could just add some
annotations at the top of each module, but it wouldn't help on
parameters.
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
On Wednesday, 16 October 2013 at 10:52:47 UTC, simendsjo wrote:
On Wednesday, 16 October 2013 at 10:37:28 UTC, Timon Gehr wrote:
On 10/16/2013 08:46 AM, simendsjo wrote:
No.. Give me a language that catches obvious bugs at
compile-time, makes
code self-documenting and doesn't let me worry about
performance.
...
Why just obvious bugs?
Hehe. Sure - let the compiler catch *all* my bugs!
scope, const, immutable, pure, nothrow, safe, ... D makes it
harder to shoot yourself in the foot, but you are aiming at
your foot by default..
Too bad I have to add a lot of annotations
void f(Class i) {}
to
void f(in Class i) const pure nothrow @safe {}
I would rather have to write
void f(@(mutable, escapes) Class i) @(impure mutable throws
unsafe) {}
If @mutable and @impure existed, I could just add some
annotations at the top of each module, but it wouldn't help on
parameters.
I wonder how easy it would be to write a little pre-processor
using https://github.com/Hackerpilot/Dscanner that would
effectively add those keywords.
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
On Wednesday, 16 October 2013 at 10:52:47 UTC, simendsjo wrote:
On Wednesday, 16 October 2013 at 10:37:28 UTC, Timon Gehr wrote:
On 10/16/2013 08:46 AM, simendsjo wrote:
No.. Give me a language that catches obvious bugs at
compile-time, makes
code self-documenting and doesn't let me worry about
performance.
...
Why just obvious bugs?
Hehe. Sure - let the compiler catch *all* my bugs!
scope, const, immutable, pure, nothrow, safe, ... D makes it
harder to shoot yourself in the foot, but you are aiming at
your foot by default..
Too bad I have to add a lot of annotations
void f(Class i) {}
to
void f(in Class i) const pure nothrow @safe {}
I would rather have to write
void f(@(mutable, escapes) Class i) @(impure mutable throws
unsafe) {}
If @mutable and @impure existed, I could just add some
annotations at the top of each module, but it wouldn't help on
parameters.
The problem, which I know well from other languages with
annotations, is that eventually you reach annotation hell,
specially in the enterprise world.
--
Paulo
Re: Help needed testing automatic win64 configuration
On 16 October 2013 17:16, Rainer Schuetze r.sagita...@gmx.de wrote: On 16.10.2013 04:45, Manu wrote: 2: gcstub64.obj and phobos64.lib are still in D/dmd2/windows/lib. They should be moved to lib64/ We are trying to talk Walter into doing this but it seems there are topics that fail to gain traction. Cool, well if it get's there, I should add that it would be nice to lose the '64' suffix too. No reason for them to have different filenames if they're in lib64/. Just creates extra annoying logic in build scripts. 4: It fails to find the Microsoft libs. Here is the relevant parts of my sc.ini as installed by the installer: LIB=%@P%\..\lib64;%@P%\..\**lib search path for C Runtime libraries ; the following lib path works with VS2008, VS2010, VS2012, VS2013 ; prepending because 32-bit OMF versions can cause link.exe to fail LIB=C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\lib\amd64;%LIB% search path for Platform libraries ; the following lib path works with Windows SDK 6.x and 7.x LIB=C:\Program Files (x86)\Windows Kits\8.0\lib\winv6.3\um\x64;%**LIB% ; the following lib path works with Windows SDK 8.0 and 8.1 LIB=%WindowsSdkDir%Lib\win8\**um\x64;%LIB% I have VS2010 and VS2012 installed on a Win8 machine. I have libs in these locations: C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Lib\x64 - this one seems to be unknown to the installer. These libs should be used in conjunction with VS2010. C:\Program Files (x86)\Windows Kits\8.0\Lib\win8\um\x64 - the installer refers to %WindowsSdkDir%, which is not present on my system. Use the absolute path instead? These libs are to use used in conjunction with VS2012. C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\lib\amd64 - runtime libs, how to pick which version? Prompt during installation? C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\lib\amd64 - runtime libs, how to pick which version? Prompt during installation? I should note that I think VisualD needs to do some work here too. VisualD should override the linker and lib paths, since it has more information. Ie, how does cmdline DMD choose which linker/runtime libs to use? Perhaps a prompt during installation? Choose the newest (appears to be the current behaviour). Whereas VisualD will be running inside of an instance of either VS2010 or VS2012 (I use both, this is very common practise) on my machine, and it should configure the linker and lib paths appropriately for the version of VisualStudio currently in use when building, otherwise there will be link troubles against C/C++ libraries also being built in the same solution (yes, it's common to have C/C++ and D in the same solution). The installer tries to pick the latest version of both VS and SDK installations. I see there is a problem when selecting a different C runtime than what your C/C++ code is assuming. Is the Windows-SDK a problem, too? The files used are just import libraries, so the latest should be fine as long as you don't need linker errors when you build an application to be run on XP but are calling Win8 only functions. You're probably right about the system library path. I haven't had any issues of this sort, but I just tend to be behave conservatively when it comes to this sort of thing. There are so many unexpected ways that linking goes wrong in the windows ecosystem. The runtime libraries are definitely a problem. The 'select most recent' policy is incorrect in my case. VS2010 is the environment I do 99% of my work, and I have experienced issued when C and D projects are together in the same solution. I'm not sure what the best solution is here. My feeling is that a prompt in the installer to offer which version to hook up as the default, and VisualD overriding these variables somehow. There's no way for VisualD to override this variable when invoking the compiler? You mention below that it would only be possible with separate linkage, why is that? For clarity, on my system, when using the VS2010 compiler, it should use these lib paths: runtime libs: C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\lib\amd64 windows libs: C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Lib\x64- AFAIK, Microsoft SDKs is the old location, installed with VS2010 and earlier. When using the VS2012 compiler, it should use these paths: runtime libs: C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\lib\amd64 windows libs: C:\Program Files (x86)\Windows Kits\8.0\Lib\win8\um\x64 - Windows Kits is the new location, by versions VS2010 (AFAIK). The default installation of DMD using your new installer fails to link on my machine because %WindowsSdkDir% is not defined on my system, and since the 32bit dmd lib path is still present, it tries to link the OMF libs, and complains a lot. It seems the installer failed to replace two occurences of %WindowsSdkDir%. WindowsSdkDir is set by batch files
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
On Wednesday, 16 October 2013 at 10:58:04 UTC, John Colvin wrote:
On Wednesday, 16 October 2013 at 10:52:47 UTC, simendsjo wrote:
On Wednesday, 16 October 2013 at 10:37:28 UTC, Timon Gehr
wrote:
On 10/16/2013 08:46 AM, simendsjo wrote:
No.. Give me a language that catches obvious bugs at
compile-time, makes
code self-documenting and doesn't let me worry about
performance.
...
Why just obvious bugs?
Hehe. Sure - let the compiler catch *all* my bugs!
scope, const, immutable, pure, nothrow, safe, ... D makes it
harder to shoot yourself in the foot, but you are aiming at
your foot by default..
Too bad I have to add a lot of annotations
void f(Class i) {}
to
void f(in Class i) const pure nothrow @safe {}
I would rather have to write
void f(@(mutable, escapes) Class i) @(impure mutable throws
unsafe) {}
If @mutable and @impure existed, I could just add some
annotations at the top of each module, but it wouldn't help on
parameters.
I wonder how easy it would be to write a little pre-processor
using https://github.com/Hackerpilot/Dscanner that would
effectively add those keywords.
Even if it were super simple and worked fine, I wouldn't use it.
It would in effect be a custom Safe D compiler that isn't
compatible with regular D.
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
On Wednesday, 16 October 2013 at 11:05:25 UTC, PauloPinto wrote:
On Wednesday, 16 October 2013 at 10:52:47 UTC, simendsjo wrote:
On Wednesday, 16 October 2013 at 10:37:28 UTC, Timon Gehr
wrote:
On 10/16/2013 08:46 AM, simendsjo wrote:
No.. Give me a language that catches obvious bugs at
compile-time, makes
code self-documenting and doesn't let me worry about
performance.
...
Why just obvious bugs?
Hehe. Sure - let the compiler catch *all* my bugs!
scope, const, immutable, pure, nothrow, safe, ... D makes it
harder to shoot yourself in the foot, but you are aiming at
your foot by default..
Too bad I have to add a lot of annotations
void f(Class i) {}
to
void f(in Class i) const pure nothrow @safe {}
I would rather have to write
void f(@(mutable, escapes) Class i) @(impure mutable throws
unsafe) {}
If @mutable and @impure existed, I could just add some
annotations at the top of each module, but it wouldn't help on
parameters.
The problem, which I know well from other languages with
annotations, is that eventually you reach annotation hell,
specially in the enterprise world.
I don't have any enterprise experience, but with UDAs, this can
already happen.
What I think is bad is that I have to add a lot of built-in
annotations to get help from the compiler catching bugs.
But there would be fewer annotations if you were able to negate
some annotations.
If 95% of your functions are pure, why should you have to say
pure for all those rather than impure for 5%?
Re: [Proposal] Weak reference implementation for D
16.10.2013 3:20, Sean Kelly пишет: On Tuesday, 15 October 2013 at 22:09:17 UTC, Robert wrote: The problem is that destructors and thus the registered hooks for the dispose events are called when threads are already resumed. If this wasn't the case there would actually be no problems. Gotcha. Looking at the code... I think you'll get this to work, but manipulating such user-mode weak references seems really expensive. Why not work on a DIP to get them built in? For example, one option might be to have the GC perform certain types of finalization while the world is stopped. This would have to be limited to very rudimentary stuff, and the easiest way to guarantee that would be to have everything live in Druntime. What about this: https://github.com/D-Programming-Language/druntime/pull/639 -- Денис В. Шеломовский Denis V. Shelomovskij
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
PauloPinto: The problem, which I know well from other languages with annotations, is that eventually you reach annotation hell, specially in the enterprise world. There are research papers that explore the algebra of effects, and also contain better syntax and some better inference. With such ideas the control of those effects seems to improve. Bye, bearophile
Re: Qt bindings for D
On Tuesday, 15 October 2013 at 09:38:15 UTC, Max Samukha wrote: 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. OK I see (unfortunately !) 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. I did notice when in the code that it was partially in a transitional state - now I know what you were doing! I have to confess that in the light of this and some of your other posts, the siren call of 'start again' is singing in my ear.
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
On 2013-10-16 12:52, simendsjo wrote: If @mutable and @impure existed, I could just add some annotations at the top of each module, but it wouldn't help on parameters. We need a general way to turn off attributes. This !@attribute has been proposed before. -- /Jacob Carlborg
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
On Wednesday, 16 October 2013 at 11:36:30 UTC, Jacob Carlborg wrote: On 2013-10-16 12:52, simendsjo wrote: If @mutable and @impure existed, I could just add some annotations at the top of each module, but it wouldn't help on parameters. We need a general way to turn off attributes. This !@attribute has been proposed before. How would that relate to non-binary attributes like @system, @trusted, @safe? Seems like it would only work on binary built-in attributes.
Optimizing a raytracer
Hello! I am writing an unbiased raytrace renderer in D. I have good progress, but I want to make it as fast as possible where I can do it without compromises. I use a struct with three doubles for vector and color calculations and I have operator overloading for them. Many vectors and colors are created during the tracing calculations. I thought, using classes may require too much memory, because they are not destructed on scope end, and maybe speed reduction when GC kicks in. Is my assumptions that in this case struct are more wise? To avoid the constructing many vectors and colors, I thought to use ref arguments, but I also heard that ref functions are not inlined. What would generate the fastest code for a cross-product for example? What compiler and compilations flags should I use to generate the fastest code? My main target is sixty-four bit machines, cross-platform. What optimizations can I assume for various compilers? Are only once used local variables inlined? So it secure to extract local variables only to make the code more easy to understand? Thanks is Advance! Róbert László Páli
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
There are research papers that explore the algebra of effects, and also contain better syntax and some better inference. With such ideas the control of those effects seems to improve. An example, from the Koka language: http://research.microsoft.com/en-us/projects/koka/2012-overviewkoka.pdf Bye, bearophile
Re: Inconsitency
On 2013-10-16 10:03, qznc wrote: Most code might be buggy then. An issue the often comes up is file names. A file called bär will be normalized differently depending on the operating system. In both cases it is one grapheme. However, on Linux it is one code point, but on OS X it is two code points. Why would it require two code points? -- /Jacob Carlborg
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
On Wednesday, 16 October 2013 at 11:47:44 UTC, simendsjo wrote: How would that relate to non-binary attributes like @system, @trusted, @safe? Seems like it would only work on binary built-in attributes. Still helpful. Problem with current built-in attribute design is that any attribute is supposed to be special case that catches attention and says something about the function. I D though most of attributes are actually wanted as defaults which creates all the mess. Adding negation for most common ones will make it at least tolerable without any major language changes.
Re: Inconsitency
On Wednesday, 16 October 2013 at 12:18:40 UTC, Jacob Carlborg wrote: On 2013-10-16 10:03, qznc wrote: Most code might be buggy then. An issue the often comes up is file names. A file called bär will be normalized differently depending on the operating system. In both cases it is one grapheme. However, on Linux it is one code point, but on OS X it is two code points. Why would it require two code points? It is either [U+00E4] as one code point or [a,U+0308] for two code points. The second is combining diaeresis [0]. Not required, but possible. Those combining characters [1] provide a nearly infinite number of combinations. You can go crazy with it: http://stackoverflow.com/questions/6579844/how-does-zalgo-text-work [0] http://www.fileformat.info/info/unicode/char/0308/index.htm [1] http://en.wikipedia.org/wiki/Combining_character
Re: Debugging support for D - wiki
On 23/09/2013 20:50, Bruno Medeiros wrote: I'm looking to begin adding integrated debugger support for the DDT IDE pretty soon. With this in mind it would be desirable to have a view of what level of D language debugger support is there for the various combinations of platform+compiler+debugger. This information would be quite beneficial to regular D users as well, as Manu's recent thread on the importance of a debugger is any indication of. Yet there doesn't seem to be any info about this in the wiki. The debuggers wiki page ( http://wiki.dlang.org/Debuggers ) doesn't even list the main players in this scene (VisualD/Mago, GDB, WinDebugger?) I might get started with this, but I would need to enlist the help of other people for the other platforms/debuggers I don't have proper acess to. The only combinations I tried so far was DMD+Windows+GDB, which seems like it's not supported at all. And GDC+Windows32+GDB which does seem to be well supported (GDB understands D name mangling, breakpoints in source, D data structures layout, etc.). I'm guessing GDC+GDB on Linux works just as well. (what about Mac though?) Several questions remain: Is debugger support with DMD+Linux+GDB as good as it is with GDC? For DMD+Windows, is there only good debugger support with VisualD? :-( And how well does that work with 32/64 bit platform variations? It would be great to have these answered, and going forward, keeping track of this info in the wiki. I've updated the Debuggers wiki page with the info gathered so far: http://wiki.dlang.org/Debuggers (I've also added Mono-D and Eclipse CDT to the list of frontends) Feel free to add/modify the information in that page. In particular, a few key missing points: * Is the level of support for DMD-Linux as good as GDC? * What is the level of support for LDC/LLVM? (haven't tried it yet at all) * How complete is the debugging info for DMD-Win64? Is it fully implemented, and/or are there any issues or limitations? (Rainer you are likely the best to answer this one) -- Bruno Medeiros - Software Engineer
Re: Debugging support for D - wiki
On Wednesday, 16 October 2013 at 12:33:07 UTC, Bruno Medeiros wrote: Feel free to add/modify the information in that page. I've added details for the DDD frontend and the WinDbg debugger supplied in the D compiler zip file.
Re: Optimizing a raytracer
On 2013-10-16 14:02, Róbert László Páli wrote: Hello! I am writing an unbiased raytrace renderer in D. I have good progress, but I want to make it as fast as possible where I can do it without compromises. I use a struct with three doubles for vector and color calculations and I have operator overloading for them. Many vectors and colors are created during the tracing calculations. I thought, using classes may require too much memory, because they are not destructed on scope end, and maybe speed reduction when GC kicks in. Is my assumptions that in this case struct are more wise? To avoid the constructing many vectors and colors, I thought to use ref arguments, but I also heard that ref functions are not inlined. What would generate the fastest code for a cross-product for example? What compiler and compilations flags should I use to generate the fastest code? My main target is sixty-four bit machines, cross-platform. What optimizations can I assume for various compilers? Are only once used local variables inlined? So it secure to extract local variables only to make the code more easy to understand? I would say use structs. For compiler I would go with LDC or GDC. Both of these are faster for floating point calculations than DMD. You can always benchmark. -- /Jacob Carlborg
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
On 2013-10-16 13:47, simendsjo wrote: How would that relate to non-binary attributes like @system, @trusted, @safe? Seems like it would only work on binary built-in attributes. No, !@safe would be mean the exact same thing as if you hadn't applied @safe. In this case, @system. -- /Jacob Carlborg
Re: Optimizing a raytracer
I find it critical to ensure all loops are unrolled in basic vector ops (copy/arithmathc/dot etc.) On Wednesday, 16 October 2013 at 12:02:15 UTC, Róbert László Páli wrote: Hello! I am writing an unbiased raytrace renderer in D. I have good progress, but I want to make it as fast as possible where I can do it without compromises.
Re: Qt bindings for D
On 10/16/13, w0rp devw...@gmail.com wrote: or perhaps scan inside Qt memory. I've never managed to make this work in some C++ libs I've tried to wrap. I think it's because the D GC probably knows which memory it allocated and will not scan pointers to memory it did not allocate. That's just a guess though.
Re: Inconsitency
On 2013-10-16 14:33, qznc wrote: It is either [U+00E4] as one code point or [a,U+0308] for two code points. The second is combining diaeresis [0]. Not required, but possible. Those combining characters [1] provide a nearly infinite number of combinations. You can go crazy with it: http://stackoverflow.com/questions/6579844/how-does-zalgo-text-work [0] http://www.fileformat.info/info/unicode/char/0308/index.htm [1] http://en.wikipedia.org/wiki/Combining_character Aha, now I see. -- /Jacob Carlborg
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
Dicebot: Adding negation for most common ones will make it at least tolerable without any major language changes. I suggest to stop applying patches over patches over problems, and instead adopt a more principled approach to solve problems. The ideas of the Koka language could show a principled way to face the problem. Bye, bearophile
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
On Wednesday, 16 October 2013 at 14:59:19 UTC, bearophile wrote: I suggest to stop applying patches over patches over problems, and instead adopt a more principled approach to solve problems. The ideas of the Koka language could show a principled way to face the problem. tl; dr: we can't Right now D is in similar state as C++ in that regard and not much can be done without revamping the spec. It is not like people lack the ideas to improve the design, quite the contrary.
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
On Oct 15, 2013, at 5:30 PM, Nick Sabalausky seewebsitetocontac...@semitwist.com wrote: On Tue, 15 Oct 2013 15:15:45 -0700 Walter Bright newshou...@digitalmars.com wrote: http://www.reddit.com/r/programming/comments/1oi8wd/ruby_is_a_dying_language/ccs8yr8 Totally agree. 90+% of the argument for dynamic languages is getting shit done, and yet they ultimately *create* work: More unittests, more roadblocks optimizing for memory/speed, and (the biggest IMO) much more debugging due to statically-checkable errors being silently converted into hidden bugs. I'm reasonably okay with dynamic languages so long as you can require a variable to be declared before it's used. Those that implicitly declare on first assignment are a nightmare however. I once spent an entire day debugging a Lua app that turned out to be broken because of a typo in an assignment. Never again.
Re: Help needed testing automatic win64 configuration
On Tuesday, 15 October 2013 at 02:17:39 UTC, Brad Anderson wrote: This installer also includes support for automatically downloading the Visual D installer and running it (another yet to be merged pull request[3]). with sc-2 config it is almost useless with VisualD, hope next version will be more usable :) also, does anyone knows why it fails to start debugger on x64 binary using VisualD?
Re: Help needed testing automatic win64 configuration
On Wednesday, 16 October 2013 at 01:15:20 UTC, Brad Anderson wrote: On Tuesday, 15 October 2013 at 06:38:30 UTC, dnewbie wrote: 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 I believe you need the 7.1 SDK. 7.0 does not come with the 64-bit toolset. I'm not certain about the paths in an Express/7.1 setup. If you can give me the paths to: 1. 64-bit link.exe 2. 64-bit C Runtime libraries (in MSVC this is %VCINSTALLDIR%lib\amd64 but I'm not sure if that comes with Express or with the 7.1 SDK and is located somewhere in SDK's directory structure instead). I might be able to this working. 1. 64-bit link.exe: C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\Bin\amd64\link.exe 2. 64-bit C Runtime libraries: C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\lib\amd64 3. 64-bit Windows import libraries: C:\Program Files\Microsoft SDKs\Windows\v7.0\Lib\x64
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
On Wed, Oct 16, 2013 at 09:19:56AM +0200, Jacob Carlborg wrote: On 2013-10-16 02:45, Adam Wilson wrote: +1 This is why I claw my eyes out every time I have to work with JavaScript. This is why I find statically typed languages to so much more powerful for the work I do One big difference between Ruby and JavaScript is that when something fails in Ruby you'll get an exception. But with JavaScript it just silently fails and all your scripts on the site dies. [...] Yeah, this is exactly what makes Javascript a royal pain in the neck to work with. I have the dubious pleasure of having to work on a large non-trivial JS codebase at work, and it has a reputation of simply displaying a blank page when something goes wrong. Worse yet, there is some default error handler somewhere that swallows all JS errors, so no errors get logged to the browser's JS console at all -- you have to debug the entire 50k or so lines of JS with a blank page as your only clue as to what blew up. (And don't get me started on IE6, which used to be the de facto standard demanded by every customer some years ago, which doesn't even *have* an error console. Fortunately, the world has moved on since.) Other times, when it doesn't show a blank page, the same ingenious default error handler makes it so that scripts *continue* running after something has gone wrong. So when you screw up and some part of the code crashes, the rest of the page continues running as if nothing happened, except that some buttons mysteriously do nothing, or the widget starts acting funny. T -- Bare foot: (n.) A device for locating thumb tacks on the floor.
Re: draft proposal for ref counting in D
Yes and no. You obviously need to scan TL heaps at some point. When doing so you'll have a set of root that allow you to scan shared/immutable heap. What is going on in the TL heap become irrelevant once you have the root. And getting the roots from the TL heap is another problem altogether (any kind of GC can be used for that, stop the world, where the world is thread local, or another concurrent GC, the important point being that it is an independent problem).
Re: Inconsitency
On Wednesday, 16 October 2013 at 13:57:01 UTC, Jacob Carlborg wrote: On 2013-10-16 14:33, qznc wrote: It is either [U+00E4] as one code point or [a,U+0308] for two code points. The second is combining diaeresis [0]. Not required, but possible. Those combining characters [1] provide a nearly infinite number of combinations. You can go crazy with it: http://stackoverflow.com/questions/6579844/how-does-zalgo-text-work [0] http://www.fileformat.info/info/unicode/char/0308/index.htm [1] http://en.wikipedia.org/wiki/Combining_character Aha, now I see. One of the interesting points, is with ba\u00E4r vs baa\u0308r, you can run a replace to replace 'a' with 'o'. Then, you'll get: boär vs boör Which is the correct behavior? There is no correct answer. So while a grapheme should never be separated from it's letter (eg, sorting oäa should *not* generate aaö. What it *should* generate is up to debate), you can't entirely consider that a letter+grapheme is a single entity. Long story short: unicode is f***ing complicated. And I think D does a *damn* fine job of supporting it. In particular, it does an awesome job of *teaching* the coder *what* unicode is. Virtually everyone here has solid knowledge of unicode (I feel). They understand, and can explain it, and can work with. On the other hand, I don't know many C++ coders that understand unicode.
Re: Early review of std.logger
Short version of below: I want a powerful logging system. Maybe std.logging should provide the interface with some basic functionality, allow other solutions to fill in gaps. Should be able to always code against std.logging, complications added as needed w/o code calling log() caring or changing. On Wed, Oct 16, 2013 at 12:30 AM, Robert Schadek realbur...@gmx.de wrote: no hierarchical logs, KISS just create a logger with different destination. new FileLogger(myDevLog); $ tail -f myDevLog Without this provided out of the box, I'd have to create my own framework for such on top for any serious use. This is arguably the most important feature of a logging framework for a large product. Once you get multiple people/teams/companies/monkeys contributing to a system, you _need_ a way to distinguish and filter logging from each part. Spitting to different log files is not a solution in most cases, the 'create my own' would have each module logger spitting to the same place as the root, with the root logger controlling what actually made it to the log. Simple logging framework should be simple. But it should also be powerful, without requiring custom boilerplate for more complex usage... Earlier was mention of getting a module's log via import, this seems a good solution interface wise - basic implementation would just return basic logger, but would allow for a hierarchical solution to be plumbed in without the logging code knowing/caring. Configurable log ouput with custom fields (time, thread, etc). - required for making log output match predefined formats - include needed metadata in the log line I think this has been discussed twice already, no configuration can anticipate all possible needs and will fail fast and hard. So why try, I rather write 7 lines, than wait for a patch to the configuration parser to appear in my production env. There are two parts to this: making sure the log output conforms to some format, and making sure required information is included. You can never anticipate what everyone needs for either, but you can provide the tools to enable them. Conceptually, this means separating the information being logged from the actual output - the basic logging framework doesn't need to even try to cover every case, so long as it provides hook points. Once the output is separated from the information, custom output is as simple as a format string. Important bit is that this is decided by the logger (or whoever configured it) not the code where it is logged. Can provide basic information by default, or not, so long as there is a mechanism to include custom information. MDC in slf4j/logback is one approach to the 'information included' problem: http://logback.qos.ch/manual/mdc.html Not suggesting std.logging needs the same thing, but illustrates one way to solve. Personal experience has shown this is useful.
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
On 10/16/13 4:47 AM, simendsjo wrote: On Wednesday, 16 October 2013 at 11:36:30 UTC, Jacob Carlborg wrote: On 2013-10-16 12:52, simendsjo wrote: If @mutable and @impure existed, I could just add some annotations at the top of each module, but it wouldn't help on parameters. We need a general way to turn off attributes. This !@attribute has been proposed before. How would that relate to non-binary attributes like @system, @trusted, @safe? Those would be turned off by choosing another one. The point is they are surjective (cover the entire domain). The binary attributes are not surjective - the absence of one indicates its opposite, but there is no way to name the opposite. Seems like it would only work on binary built-in attributes. Yah. Andrei
Re: Optimizing a raytracer
On Wednesday, 16 October 2013 at 12:02:15 UTC, Róbert László Páli wrote: I thought, using classes may require too much memory, because they are not destructed on scope end, and maybe speed reduction when GC kicks in. Is my assumptions that in this case struct are more wise? Yes, by all means use struct. What would generate the fastest code for a cross-product for example? If you are on x86, SSE 4.1 introduced an instruction called DPPS which performs a dot product. Maybe you can force it into doing a cross-product with clever swizzles and masks.
Re: draft proposal for ref counting in D
Am 14.10.2013 22:59, schrieb Paulo Pinto: Well, if real time concurrent GC for Java systems is good enough for systems that control militar missile systems, maybe it is good enough for real-time audio as well. -- Paulo The problem is not that there are no GCs around in other languages which satisfy certain requirements. The problem is actually implementing them in D. I suggest that you read The Garbage Collection Handbook which explains this in deep detail. I'm currently reading it, and I might write an article about the entire D GC issue once I'm done with it.
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
On 2013-10-16 20:38, Andrei Alexandrescu wrote: Seems like it would only work on binary built-in attributes. Yah. Why? enum foo; @foo: !@foo void bar (); Just as if @foo wasn't attached to bar. Although I don't know that to do with multiple attributes of the same type: @(foo, foo) void bar (); Remove all? -- /Jacob Carlborg
Re: draft proposal for ref counting in D
On Oct 16, 2013, at 11:54 AM, Benjamin Thaut c...@benjamin-thaut.de wrote: The problem is not that there are no GCs around in other languages which satisfy certain requirements. The problem is actually implementing them in D. I suggest that you read The Garbage Collection Handbook which explains this in deep detail. I'm currently reading it, and I might write an article about the entire D GC issue once I'm done with it. I think the short version is that D being able to directly call C code is a huge problem here. Incremental GCs all rely on the GC being notified when pointers are changed. We might be able to manage it for SafeD, but then SafeD would basically be its own language.
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
On 2013-10-16 17:37, Sean Kelly wrote: I'm reasonably okay with dynamic languages so long as you can require a variable to be declared before it's used. Those that implicitly declare on first assignment are a nightmare however. I once spent an entire day debugging a Lua app that turned out to be broken because of a typo in an assignment. Never again. That can be quite annoying in Ruby sometimes: class Bar attr_accessor :foo def bar puts foo # calls the getter foo = asd # declares a local variable self.foo = foobar # calls the setter @foo = barfoo # bypasses the setter and set the instance variable directory puts foo # prints the local variable end end Bar.new.bar Although I like that instance variables are not required to be declared. -- /Jacob Carlborg
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
On Wednesday, 16 October 2013 at 19:00:07 UTC, Jacob Carlborg wrote: On 2013-10-16 20:38, Andrei Alexandrescu wrote: Seems like it would only work on binary built-in attributes. Yah. Why? enum foo; @foo: !@foo void bar (); You're right. That would be nice for generic code for instance to mark that it's done processing an attribute. Just as if @foo wasn't attached to bar. Although I don't know that to do with multiple attributes of the same type: @(foo, foo) void bar (); Remove all? Remove all would probably be more in sync with getAttributes that returns all attributes, but removing only the first would allow greater flexibility. It's easy to remove all if you have a way to remove one, but the other way around isn't as easy :)
Re: draft proposal for ref counting in D
Am 16.10.2013 20:54, schrieb Benjamin Thaut: Am 14.10.2013 22:59, schrieb Paulo Pinto: Well, if real time concurrent GC for Java systems is good enough for systems that control militar missile systems, maybe it is good enough for real-time audio as well. -- Paulo The problem is not that there are no GCs around in other languages which satisfy certain requirements. The problem is actually implementing them in D. I suggest that you read The Garbage Collection Handbook which explains this in deep detail. I'm currently reading it, and I might write an article about the entire D GC issue once I'm done with it. I have read it when it came out in the late 90's. My main focus areas in the university were compiler design, distributed systems and graphics programming. Although, like many, I tend to do plain boring enterprise applications nowadays. -- Paulo
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
On 2013-10-16 19:26, H. S. Teoh wrote: Yeah, this is exactly what makes Javascript a royal pain in the neck to work with. I have the dubious pleasure of having to work on a large non-trivial JS codebase at work, and it has a reputation of simply displaying a blank page when something goes wrong. Worse yet, there is some default error handler somewhere that swallows all JS errors, so no errors get logged to the browser's JS console at all -- you have to debug the entire 50k or so lines of JS with a blank page as your only clue as to what blew up. Yeah, you really need to use the browser's developer tools to have any chance when working with JavaScript. (And don't get me started on IE6, which used to be the de facto standard demanded by every customer some years ago, which doesn't even *have* an error console. Fortunately, the world has moved on since.) Actually, just a couple of weeks ago I found Firebug Lite. It's like Firebug but it's a booklet in pure JavaScript (ironically). That means you can use it in any browser, include IE6 (yes it works in IE6), iOS and other browsers missing developer tools. I have also used remote debugging when I debugged a site in the iPhone simulator. It uses web sockets (I think) to send the data to another browser where the actual developer tools are. -- /Jacob Carlborg
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
On 2013-10-16 21:08, simendsjo wrote: Remove all would probably be more in sync with getAttributes that returns all attributes, but removing only the first would allow greater flexibility. It's easy to remove all if you have a way to remove one, but the other way around isn't as easy :) How would you remove all? I guess something like this: !@(foo, foo) But how can that be generalized? Unless we get a trait for removing attributes. -- /Jacob Carlborg
Re: draft proposal for ref counting in D
On 2013-10-16 21:05, Sean Kelly wrote: I think the short version is that D being able to directly call C code is a huge problem here. Incremental GCs all rely on the GC being notified when pointers are changed. We might be able to manage it for SafeD, but then SafeD would basically be its own language. One need to be very careful with the memory when interfacing with C code today. What about having a function that notifies the GC that a pointer has been updated? -- /Jacob Carlborg
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
On Wednesday, 16 October 2013 at 19:19:26 UTC, Jacob Carlborg wrote: On 2013-10-16 21:08, simendsjo wrote: Remove all would probably be more in sync with getAttributes that returns all attributes, but removing only the first would allow greater flexibility. It's easy to remove all if you have a way to remove one, but the other way around isn't as easy :) How would you remove all? I guess something like this: !@(foo, foo) But how can that be generalized? Unless we get a trait for removing attributes. Yes, sorry. I was thinking about a new __trait and running a loop. Is this when we should be dreaming of the all-powerful AST macros again?
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
On 2013-10-16 21:23, simendsjo wrote: Yes, sorry. I was thinking about a new __trait and running a loop. Is this when we should be dreaming of the all-powerful AST macros again? Yes, AST macros will solve everything :) -- /Jacob Carlborg
Re: Early review of std.logger
On 10/16/2013 08:18 PM, Jeremy Powers wrote: Short version of below: I want a powerful logging system. Maybe std.logging should provide the interface with some basic functionality, allow other solutions to fill in gaps. Should be able to always code against std.logging, complications added as needed w/o code calling log() caring or changing. On Wed, Oct 16, 2013 at 12:30 AM, Robert Schadek realbur...@gmx.de mailto:realbur...@gmx.de wrote: no hierarchical logs, KISS just create a logger with different destination. new FileLogger(myDevLog); $ tail -f myDevLog Without this provided out of the box, I'd have to create my own framework for such on top for any serious use. This is arguably the most important feature of a logging framework for a large product. Once you get multiple people/teams/companies/monkeys contributing to a system, you _need_ a way to distinguish and filter logging from each part. Spitting to different log files is not a solution in most cases, the 'create my own' would have each module logger spitting to the same place as the root, with the root logger controlling what actually made it to the log. Simple logging framework should be simple. But it should also be powerful, without requiring custom boilerplate for more complex usage... Earlier was mention of getting a module's log via import, this seems a good solution interface wise - basic implementation would just return basic logger, but would allow for a hierarchical solution to be plumbed in without the logging code knowing/caring. I still don't feel that hierarchy building should be part of std.logger, as it is way to heavyweight. But thinking about MultiLogger made me realize, that I need a way to identifier Logger to remove them. So currently, I think MultiLogger will have an AA and Logger will have names (string). You do the math Configurable log ouput with custom fields (time, thread, etc). - required for making log output match predefined formats - include needed metadata in the log line I think this has been discussed twice already, no configuration can anticipate all possible needs and will fail fast and hard. So why try, I rather write 7 lines, than wait for a patch to the configuration parser to appear in my production env. There are two parts to this: making sure the log output conforms to some format, and making sure required information is included. You can never anticipate what everyone needs for either, but you can provide the tools to enable them. Conceptually, this means separating the information being logged from the actual output - the basic logging framework doesn't need to even try to cover every case, so long as it provides hook points. logMessage(LoggerPayload); is your all powerful hookpoint.
Re: Inconsitency
On Wednesday, 16 October 2013 at 18:13:37 UTC, monarch_dodra wrote: On Wednesday, 16 October 2013 at 13:57:01 UTC, Jacob Carlborg wrote: On 2013-10-16 14:33, qznc wrote: It is either [U+00E4] as one code point or [a,U+0308] for two code points. The second is combining diaeresis [0]. Not required, but possible. Those combining characters [1] provide a nearly infinite number of combinations. You can go crazy with it: http://stackoverflow.com/questions/6579844/how-does-zalgo-text-work [0] http://www.fileformat.info/info/unicode/char/0308/index.htm [1] http://en.wikipedia.org/wiki/Combining_character Aha, now I see. One of the interesting points, is with ba\u00E4r vs baa\u0308r, you can run a replace to replace 'a' with 'o'. Then, you'll get: boär vs boör Which is the correct behavior? There is no correct answer. So while a grapheme should never be separated from it's letter (eg, sorting oäa should *not* generate aaö. What it *should* generate is up to debate), you can't entirely consider that a letter+grapheme is a single entity. Long story short: unicode is f***ing complicated. And I think D does a *damn* fine job of supporting it. In particular, it does an awesome job of *teaching* the coder *what* unicode is. Virtually everyone here has solid knowledge of unicode (I feel). They understand, and can explain it, and can work with. On the other hand, I don't know many C++ coders that understand unicode. I agree with your point. Nevertheless you understanding of grapheme is off. U+0308 is not a grapheme. a\u0308 is one grapheme. U+00e4 is the same grapheme as a\u0308. http://en.wikipedia.org/wiki/Grapheme
Re: Inconsitency
16-Oct-2013 23:42, qznc пишет: On Wednesday, 16 October 2013 at 18:13:37 UTC, monarch_dodra wrote: On Wednesday, 16 October 2013 at 13:57:01 UTC, Jacob Carlborg wrote: On 2013-10-16 14:33, qznc wrote: It is either [U+00E4] as one code point or [a,U+0308] for two code points. The second is combining diaeresis [0]. Not required, but possible. Those combining characters [1] provide a nearly infinite number of combinations. You can go crazy with it: http://stackoverflow.com/questions/6579844/how-does-zalgo-text-work [0] http://www.fileformat.info/info/unicode/char/0308/index.htm [1] http://en.wikipedia.org/wiki/Combining_character Aha, now I see. One of the interesting points, is with ba\u00E4r vs baa\u0308r, you can run a replace to replace 'a' with 'o'. Then, you'll get: boär vs boör Which is the correct behavior? There is no correct answer. So while a grapheme should never be separated from it's letter (eg, sorting oäa should *not* generate aaö. What it *should* generate is up to debate), you can't entirely consider that a letter+grapheme is a single entity. Long story short: unicode is f***ing complicated. And I think D does a *damn* fine job of supporting it. In particular, it does an awesome job of *teaching* the coder *what* unicode is. Virtually everyone here has solid knowledge of unicode (I feel). They understand, and can explain it, and can work with. On the other hand, I don't know many C++ coders that understand unicode. I agree with your point. Nevertheless you understanding of grapheme is off. U+0308 is not a grapheme. a\u0308 is one grapheme. U+00e4 is the same grapheme as a\u0308. s/the same/canonically equivalent/ :) http://en.wikipedia.org/wiki/Grapheme -- Dmitry Olshansky
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
On 10/16/2013 8:37 AM, Sean Kelly wrote: I'm reasonably okay with dynamic languages so long as you can require a variable to be declared before it's used. Those that implicitly declare on first assignment are a nightmare however. I once spent an entire day debugging a Lua app that turned out to be broken because of a typo in an assignment. Never again. Implicit declaration is such a bad idea; I wonder why it keeps reappearing in every new dynamic language du jour.
Re: draft proposal for ref counting in D
Am 16.10.2013 21:05, schrieb Sean Kelly: On Oct 16, 2013, at 11:54 AM, Benjamin Thaut c...@benjamin-thaut.de wrote: The problem is not that there are no GCs around in other languages which satisfy certain requirements. The problem is actually implementing them in D. I suggest that you read The Garbage Collection Handbook which explains this in deep detail. I'm currently reading it, and I might write an article about the entire D GC issue once I'm done with it. I think the short version is that D being able to directly call C code is a huge problem here. Incremental GCs all rely on the GC being notified when pointers are changed. We might be able to manage it for SafeD, but then SafeD would basically be its own language. I think a even bigger problem are structs. Because if you need write barriers for pointers on the heap you are going to have a problem with structs. Because you will never know if they are located on the heap or the stack. Additionally making the stack percisely scannable and adding GC-Points will require a lot of compiler support. And even if this is doable in respect to DMD its going to be a big problem for GDC or LDC to change the codegen.
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
On Wed, 16 Oct 2013 10:26:37 -0700 H. S. Teoh hst...@quickfur.ath.cx wrote: (And don't get me started on IE6, which used to be the de facto standard demanded by every customer some years ago, which doesn't even *have* an error console. Fortunately, the world has moved on since.) I remember going through the same hell with Safari. (I assume that's been fixed by now, though.)
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
On Wednesday, 16 October 2013 at 20:20:18 UTC, Nick Sabalausky wrote: I remember going through the same hell with Safari. (I assume that's been fixed by now, though.) It has similar developer tools like Chrome has. -- /Jacob Carlborg
