I too would be interested.
+1
On Mon, Jun 22, 2015 at 8:39 PM, philippecp via Digitalmars-d
digitalmars-d@puremagic.com wrote:
I think the best approach is the following:
* Throw exceptions on debug (usability)
* Leave undefined on release (performance)
Please no.
Different behavior between release and non is not
On Tue, Jun 23, 2015 at 12:31 PM, Jonathan M Davis via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Tuesday, 23 June 2015 at 19:13:43 UTC, Jeremy Powers wrote:
Different behavior between release and non is not something to be desired.
It's perfectly normal if we're talking about
On Tue, Jun 23, 2015 at 4:27 PM, Tofu Ninja via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Tuesday, 23 June 2015 at 23:17:54 UTC, Meta wrote:
On Tuesday, 23 June 2015 at 22:58:32 UTC, Vladimir Panteleev wrote:
Proposed new name: lowerCased / upperCased
I really hate this naming
On Tue, Jun 23, 2015 at 4:49 PM, Vladimir Panteleev via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Tuesday, 23 June 2015 at 23:17:54 UTC, Meta wrote:
I really hate this naming scheme for functions that take lazy parameters.
I still don't see why we don't do the (IMO) simplest and
On Tue, Jun 23, 2015 at 4:33 PM, Mike via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Tuesday, 23 June 2015 at 22:45:10 UTC, Vladimir Panteleev wrote:
Sounds good?
Yes, please note that although I suggested a `Lazy` suffix, I don't want
it to be a convention. It should only be
On Thu, Jun 11, 2015 at 11:09 PM, Andrei Alexandrescu via Digitalmars-d
digitalmars-d@puremagic.com wrote:
Just ran into this with Phobos:
https://github.com/D-Programming-Language/phobos/pull/3403
If unittest-only artifacts are not constrained to just unittest builds,
does this not make
The bikeshed looks fine the way it is, thanks. But it should be green.
Seriously though, updating the website is probably a good idea. My
thoughts comparing:
* New font is smaller, harder to read than existing. Have to bump it up
one in my browser.
* Bold doesn't look bold. Did the bold
On Thu, Apr 30, 2015 at 8:08 AM, Andrei Alexandrescu via Digitalmars-d
digitalmars-d@puremagic.com wrote:
This trickle of teeny-bit breaking changes for the sake of touted benefits
must stop.
This is how you improve the language. You can disagree with the touted
benefits, but without
On Thu, Apr 2, 2015 at 12:04 PM, Andrei Alexandrescu via Digitalmars-d
digitalmars-d@puremagic.com wrote:
...
The way I see it, the notion of having one build with strippable unittests
is a nice idea but technically challenging. It's also low impact - today
concurrent CPU is cheap so
On Wed, Apr 1, 2015 at 7:31 AM, Johannes Totz via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 31/03/2015 19:24, Andrei Alexandrescu wrote:
Probably not; we're looking at two different builds. The build to be
deployed has no unittest code at all.
I'm starting to see this
On Thu, Mar 19, 2015 at 3:03 PM, Walter Bright via Digitalmars-d
digitalmars-d@puremagic.com wrote:
Accessor functions that merely return a field variable are bull anyway.
I would recommend against opening up this debate. Suffice it to say that
this is a well established pattern that many
What is best shortcut for it?
Ideally key shortcuts would match existing IDEs, so don't have to relearn.
I'm used to these:
https://www.jetbrains.com/idea/help/keyboard-shortcuts-and-mouse-reference.html
(un/comment is ctrl+/ or cmd+/ on mac, ctrl+shift+/ for block comments)
On Thu, Feb 5, 2015 at 2:10 PM, Israel via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Thursday, 5 February 2015 at 05:51:18 UTC, tcak wrote:
On Thursday, 5 February 2015 at 04:37:21 UTC, Tofu Ninja wrote:
What could be great is if DMD supported something like JAR packages, and
Snipped a bit, tl;dr is you should use dub.
How could you be sure that after long lonely work the proposal is worth
inclusion?
No need to be lonely. You can (and should) have community projects on
dub. The dub repository is a distribution mechanism, if you want community
contribution to a
On Wed, Jan 14, 2015 at 3:16 AM, Paulo Pinto via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Wednesday, 14 January 2015 at 10:37:31 UTC, Atila Neves wrote:
That post, to me, only reinforces how much better using exceptions is.
Atila
They posted recently a blog post about error
On Tue, Jan 13, 2015 at 8:26 PM, deadalnix via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Wednesday, 14 January 2015 at 02:40:20 UTC, Jeremy Powers via
Digitalmars-d wrote:
http://www.artima.com/intv/handcuffs.html
The best sum up of checked exception you'll find.
False
On Fri, Dec 19, 2014 at 2:47 AM, Sergei Nosov via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Friday, 19 December 2014 at 08:57:56 UTC, Walter Bright wrote:
I've actually not found debuggers to be of much use other than telling me
where the seg fault was and giving a stack trace.
On Thu, Nov 6, 2014 at 1:17 AM, Jonathan Marler via Digitalmars-d
digitalmars-d@puremagic.com wrote:
One thing I like about your suggestion is you can specify if a function's
error code should be verified to be handled at compile time. It would be
nice as a library writer if you could
This looks eerily familiar...
I took a stab at an Intellij plugin a long time ago, and happened to pick
the same name:
https://github.com/elendel-/intelliD
Been meaning to pick back up again, but haven't had the chance... was
waiting for the Eclipse plugin code to mature, then got distracted.
There are links to my projects in that thread. https://github.com/
Hackerpilot/libdparse should help. The doc comments for the parser tell
you the grammar that they implement. (The DGrammar project is based on
these ddoc comments. This reminds me that I need to update it.) The
official
Glad to see you turned up here.
I'm usually lurking around...
I agree, but integrating something external with IntelliJ's platform seems
like kind of a PITA. It looks like a lot of stuff makes heavy use of PSI
trees (see: https://confluence.jetbrains.com/display/IDEADEV/
On Wed, Oct 8, 2014 at 12:00 PM, Jonathan via Digitalmars-d
digitalmars-d@puremagic.com wrote:
...
3) Taking a hint from the early success of Flash, add Derelict3 (or some
basic OpenGL library) directly into Phobos. Despite some of the negatives
(slower update cycle versus external lib), it
On Mon, Oct 6, 2014 at 6:19 PM, Andrei Alexandrescu via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 10/6/14, 4:46 PM, Jeremy Powers via Digitalmars-d wrote:
On Mon, Oct 6, 2014 at 7:50 AM, Andrei Alexandrescu via Digitalmars-d
I'm thinking a simple key-value store Variant[string
On Mon, Oct 6, 2014 at 6:19 PM, Andrei Alexandrescu via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 10/6/14, 4:46 PM, Jeremy Powers via Digitalmars-d wrote:
On Mon, Oct 6, 2014 at 7:50 AM, Andrei Alexandrescu via Digitalmars-d
I'm thinking a simple key-value store Variant[string
On Tue, Oct 7, 2014 at 3:44 PM, H. S. Teoh via Digitalmars-d
digitalmars-d@puremagic.com wrote:
[snip a bunch of stuff where we totally agree with each other]
Having said all that, though, an idea occurred to me. While it's
certainly true that the catch block must catch a *specific* type of
On Mon, Oct 6, 2014 at 7:50 AM, Andrei Alexandrescu via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 10/6/14, 7:01 AM, H. S. Teoh via Digitalmars-d wrote:
On Mon, Oct 06, 2014 at 06:46:31AM -0700, Andrei Alexandrescu via
Digitalmars-d wrote:
On 10/5/14, 11:39 PM, Dmitry Olshansky
On Wed, Oct 1, 2014 at 7:24 AM, Bruno Medeiros via Digitalmars-d
digitalmars-d@puremagic.com wrote:
What has failed is not the concept of checked exceptions per se, but
mostly, the failure of Java programmers to use checked exceptions
effectively, and properly design their code around this
On Tue, Sep 30, 2014 at 5:43 AM, Steven Schveighoffer via Digitalmars-d
digitalmars-d@puremagic.com wrote:
...
Well, the failure comes from the effort to effect a certain behavior.
Sun was looking to make programmers more diligent about handling errors.
However, humans are lazy worthless
On Mon, Sep 29, 2014 at 8:13 AM, Steven Schveighoffer via Digitalmars-d
digitalmars-d@puremagic.com wrote:
My entire point is, it doesn't matter what is expected or what is treated
as correct. what matters is where the input CAME from. To a library
function, it has no idea. There is no extra
On Mon, Sep 29, 2014 at 8:13 AM, Steven Schveighoffer via Digitalmars-d
digitalmars-d@puremagic.com wrote:
The largest issue I see with this whole scheme is that exceptions can be
turned into errors, but not the reverse. Once an error is thrown, it's
pretty much game over. So defensive coding
On Mon, Sep 29, 2014 at 11:58 AM, Steven Schveighoffer via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 9/29/14 2:43 PM, Jeremy Powers via Digitalmars-d wrote:
On Mon, Sep 29, 2014 at 8:13 AM, Steven Schveighoffer via Digitalmars-d
digitalmars-d@puremagic.com mailto:digitalmars-d
On Mon, Sep 29, 2014 at 12:28 PM, Sean Kelly via Digitalmars-d
digitalmars-d@puremagic.com wrote:
Checked exceptions are good in theory but they failed utterly in
Java. I'm not interested in seeing them in D.
I've heard this before, but have not seen a reasonable argument as to why
they are
On Sun, Sep 14, 2014 at 10:30 AM, Cliff via Digitalmars-d
digitalmars-d@puremagic.com wrote:
Loggers are not *necessarily* also debuggers. When used for post-mortem
analysis (the typical case), it is not generally important that log data
has been written by the time any given log method has
On Mon, Sep 8, 2014 at 12:51 PM, Dragos Carp via Digitalmars-d
digitalmars-d@puremagic.com wrote:
It may sound a bit radical, but I think the release process can
be simplified a lot, if the 3 github repositories (dmd, druntime,
and phobos) would be merged.
...
Destroy!
These are
On Wed, Aug 27, 2014 at 12:30 PM, Nick Sabalausky via Digitalmars-d
digitalmars-d@puremagic.com wrote:
Therefore, I think the main critera we should be looking at here, for any
of the possibilities, isn't Does this language have flaws? but rather Is
this language *good enough* to be supported
I agree. Those would be the points with most impacts. However, the
outcome would be quite far away from standard JSON, so we would really be
talking about something like ASON or SDL already.
There are some beginnings like this one:
http://json5.org/
Here's another, that supports
If your users are having to install things then the problem is your
deployment mechanism not the JVM dependency hell system. Java
deployments are actually really quite easy. Either you package a total
system with all dependencies and provide entry scripts, or you use Maven
Central (or
On Mon, Aug 25, 2014 at 4:08 PM, Jonathan Marler via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Monday, 25 August 2014 at 22:21:49 UTC, Weaseldog wrote:
On Monday, 25 At 2014 at 16:40:10 UTC, Jonathan Marler wrote:
Hello everyone,
I've been working on SDL support for DUB and
The main argument seems to revolve around whether this is actually a
change
or not. In my (and others') view, the treatment of assert as 'assume' is
not a change at all. It was in there all along, we just needed the wizard
to tell us.
How can there be any question? This is a change in
I feel that, at this stage, is only about how a compiler glag,
specifically -release works. For other configurations, there is no
problem: event if the optimizer optimizes based on asserts, the asserts
themselves are part of the code: code is there and the assertion will fail
before
This has already been stated by others, but I just wanted to pile on - I
agree with Walter's definition of assert.
2. Semantic change.
The proposal changes the meaning of assert(), which will result in
breaking existing code. Regardless of philosophizing about whether or not
the code was
And there will be no injection of undefined behaviour - the undefined
behaviour is already there if the asserted constraints are not valid.
Well, no. http://en.wikipedia.org/wiki/Undefined_behavior
Well, yes: Undefined behaviour in the sense the writer of the program has
not defined it.
A
Well, yes: Undefined behaviour in the sense
And there will be no injection of undefined behaviour
^~~
conventional sense
- the undefined behaviour is already there if the asserted constraints
You're using a nonstandard definition of undefined behavior. Undefined
behavior has a precise meaning, that's why Timon linked the wiki article
for you.
The regular definition of assert does not involve any undefined behavior,
only the newly proposed one.
But the 'newly proposed one' is
That's in the past. This is all about the pros and cons of changing it now
and for the future.
The main argument seems to revolve around whether this is actually a change
or not. In my (and others') view, the treatment of assert as 'assume' is
not a change at all. It was in there all along,
Is there a[n] irrefutable requirement to have a log function without
explicit
level?
As I understand, it's a defensive feature. There are things one wants in
the log unconditionally, like OS version and program version. They can be
logged at fatal level, but that's a workaround and looks
As I understand, it's a defensive feature. There are things one wants in
the log unconditionally, like OS version and program version. They can be
logged at fatal level, but that's a workaround and looks confusing, and
still can be filtered.
Believe that's what the 'off' level is for,
Can you tell, what `log(1)` does?
Is there a irrefutable requirement to have a log function without explicit
level?
Do we lose anything if we just force every log call to have a level, and
dump the plain 'log' method? Point people to use info if they don't care
about the level, and you can
In fact you may want to define an extra logging level e.g. verbose or
yap which is by default disabled and can be enabled explicitly. It would
be hierarchically below normal logging.
Isn't this what 'trace' level is for?
Will you then be able to get fully inlined low overhead ringbuffer logging
throughout the application and used frameworks? E.g. do low level logging
to a ringbuffer that is only saved/mailed upon fatal crashes. This is
useful for online services.
Yes, apart from the inlined part, I'm not
There is still a problem: the analogy, that log/logf is similar
to write/writef, is not right anymore. Please correct me if I'm
wrong... but AFAIK write converts every argument to string and
the output device has no mean to choose a preferred
representation of the arguments.
It will be a
The point is that the most crucial aspect of logging is being able to
filter or put triggers on the logs in pre-existing external
logging-solutions without having to modify the frameworks you use.
Important, but I'd hesitate to call it the most crucial aspect... that
honour probably goes to
Not everyone will ever get satisfied.
Indeed. I can only compromise so much, until it becomes compromised.
Naming is one of the two hard problems (along with cache invalidation and
off-by-one errors).
We can argue about these things forever, but ultimately all that really
matters is: does
D unit of encapsulation is module. Any other namespace solutions must
die after proper torture.
Just use this in the next release!
extern(C++, log)
{
extern(D):
... functions ...
}
Not helping :grumpy:
Is this where I talk about hierarchical logging?
There was some talk in the
Getting things changed is more difficult than getting it right from the
start.
Very true. The logging API needs to be right before it goes into std and
has to be locked down. But then, no API is ever right the first time,
needs banging on to expose the weaknesses so they can be fixed.
... I'd almost always prefer a non-string-mixin solution.
... actually writing out the different signatures ...
+1
From a maintenance/sanity standpoint, I'd much rather have a little bit of
duplication over one large if/else'd string mixin. It is much easier to
figure out exactly what is
If we get rid of the write style variant, then you need to
remember just one name with 4 overloads:
log(string message);
log(string format, Args...);
log(bool condition, string message);
log(bool condition, string format, Args...);
But you would also have to remember that log(...)
Could you provide an example?
If you decouple the things being logged from the actual logged string, you
can do stuff like have different log sinks format things differently, or
even filter what appears in the log line as needed.
For example, you could have a setup with logging going to two
Haven't had a chance to look closely at the new version yet, but looks
pretty good. Couple initial comments:
* Definite vote for std.experimental. Should get a bunch of folks to bang
on it before the API has to be locked down. Having it as a dub package
first has made it much easier to pick up
Is it too late for an integration in std.expirimental with dmd 2.66?
ask Andrew, but I'm 99.9% sure it is to late
Thanks to dub, the need for std.experimental is significantly reduced. You
can just pull in the package and use it right now:
http://code.dlang.org/packages/logger
On Mon, Jun 9, 2014 at 2:15 PM, Dejan Lekic via Digitalmars-d
digitalmars-d@puremagic.com wrote:
I am more for stdx, which is what some developers already use as package
name for experimental stuff.
Please no. See: javax
Spelling out 'experimental' is probably the best, for all those
On Fri, May 23, 2014 at 7:39 AM, Dicebot via Digitalmars-d
digitalmars-d@puremagic.com wrote:
Original thread : http://forum.rejectedsoftware.
com/groups/rejectedsoftware.dub/thread/2/
Summary by Sonke: https://github.com/rejectedsoftware/dub/wiki/Sdl-
based-package-format-draft
Thanks.
On Sat, May 24, 2014 at 10:30 AM, Nick Sabalausky via Digitalmars-d
digitalmars-d@puremagic.com wrote:
Nobody has said anything about removing JSON support. It's been stated
that JSON support is *staying* as an option. SDL will merely be the
recommended format.
Yes - my point is that moving
On Sat, May 24, 2014 at 2:57 AM, David Osborne via Digitalmars-d
digitalmars-d@puremagic.com wrote:
Destroy :)
Overall, this approach seems good.
Not sure I like forcing one format for all sinks though - it is often
desired/necessary to have different sinks (aka appenders) format the log
On 23/05/14 08:33, Suliman wrote:
what it the reason to change json to SDL?
Less verbose.
Can you elaborate? I find JSON to be precisely the right verbosity -
enough to be human readable, not too much.
Is the decision to switch documented/discussed somewhere? It seems
unnecessary to
Dub (code.dlang.org) has emerged as the standard build tool for D. Yet
there doesn't look to be any mention of it on the D site proper...
Would it be reasonable to include dub with the DMD installer? Or failing
that, at least feature it prominently (or at all) on the tools page of
dlang.org?
Excellent. I need a lift if possible? Of so please tell me when I should
be in the aloft lobby?
This seems to still be an open question - what time to gather?
I will be staying at Aloft, and will not have a car.
If anyone has a car and extra room, I'd be happy to bum a ride.
If there are no
Last but not least, virtually nobody I know runs unittests and then
main. This is quickly becoming an idiom:
version(unittest) void main() {}
else void main()
{
...
}
I think it's time to change that.
The current system of running unit tests prior to main is, in my opinion,
On Wed, Nov 13, 2013 at 11:13 AM, Dicebot pub...@dicebot.lv wrote:
What about connecting it to date of
Using a date is the wrong approach for deprecation. When you are
deprecating something, you are stating that in a future release it will no
longer work - it just happens that releases
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
On Tue, Oct 15, 2013 at 8:17 AM, Andrei Alexandrescu
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
Some comments from the peanut gallery:
* Mentioned already: configurable log output. Configure style/contents of
log output based on output location. More options for included info
(thread id, etc). Allow custom info to be inserted based on logger context.
* Also mentioned: Configurable log
Also:
* Asynchronous logging. Log something and continue, not blocking on actual
message getting written. Can write a custom logger that works this way,
but would be nice if this was supported at the base level.
On Mon, Oct 14, 2013 at 10:01 AM, Jeremy Powers jpow...@wyrdtech.comwrote:
Some
Orthogonal to log levels one idea could be to define a namespace for a
logger instance.
Take a look at the way log4j does it, with logger hierarchy:
http://logging.apache.org/log4j/1.2/manual.html
This is incredibly useful.
It is useful but it's also a pain to configure. I used logback (
http://logback.qos.ch/ ) which is a bit nicer but still... We should
definitely step away from XML's configuration mess.
Yeah, there's a reason I linked to the old docs and not the newer
xml-centric stuff. The important bit is
Comments on comments. And to be clear, this is just me wanting everything
to be amazing - I'm incredibly glad to have any logging framework at all,
and will use what I can get.
Allow custom info to be inserted based on logger context.
don't think that this is a good way to good, complexity
On Mon, Oct 14, 2013 at 2:27 PM, Dicebot pub...@dicebot.lv wrote:
I'd like to have module-specific logging _without_ creating local module
instance. And without referring to specific logger at all. As I have
mentioned, something like:
```
import log = std.logger;
log.local.info(...); //
You're already registered for the conference, since you let me know you're
coming.
Is there an 'official' way for kickstarter backers to let you know, or
simply an informal email?
I'm concerned that folks like me who backed on kickstarter, but don't
regularly check the lists, may not know if
I had it mostly working, but haven't had a chance to work on it for a
long time. Will see if I can steal some time to look at it again.
What is the current recommended repository to use?
On Thu, Oct 21, 2010 at 1:11 PM, Jacob Carlborg d...@me.com wrote:
On 2010-10-21 11:54, Sam Hu wrote:
80 matches
Mail list logo
