Re: D2 port of Sociomantic CDGC available for early experiments
On Thu, 23 Oct 2014 15:27:50 +0100, Leandro Lucarella l...@llucax.com.ar wrote: Regan Heath, el 22 de October a las 10:41 me escribiste: NO, this is completely false, and why I think you are not entirely familiar with env vars in posix. LD_PRELOAD and LD_LIBRARY_PATH affects ALL, EACH and EVERY program for example. D or not D. Every single dynamically linked program. True. And the reason these behave this way is because we *always* want them to - the same is NOT true of the proposed vars for D. No, not at all, you very rarely want to change LD_PRELOAD and LD_LIBRARY_PATH globaly. Sure, but when you do change them you will want them to propagate, by default, which is why envvars are used for these. The same is not true of many potential D GC/allocation/debug flags, we do not necessarily want them to propagate at all and in fact we may want to target a single exe in a process tree i.e. parent - not this child1 - this one child2 - not this My conclusion is we don't agree mainly on this: I think there are cases where you want runtime configuration to propagate or be set more or less globally. I agree that there are cases we might want it to propagate *from a parent exe downwards* or similar but this is not what I would call more or less globally it's very much less than globally. The scope we want is going to be either a single exe, or that exe and some or all of it's children and possibly only for a single execution. Sure, you *could* wrap a single execution in it's own session and only set the envvar within that session but it's far simpler just to pass a command line arg. Likewise, you could set an envvar in a session and run multiple executions within that session, but again it's simpler just to pass an arg each time. Basically, I don't see what positive benefit you get from an envvar over a command line switch, especially if you assume/agree that the most sensible default these switches is 'off' and that they should be enabled specifically. I think what we disagree about here is the scope it should apply and whether propagation should be the default behaviour. You think no one will ever want some runtime option to propagate. Nope, I never said that. Also, I don't have much of a problem with having command-line options to configure the runtime too, although I think in linux/unix is much less natural. Surely not, unix is the king of command line switches. Runtime configuration will be most of the time some to be done either by the developer (in which case it would be nicer to have a programatic way to configure it) Agreed. or on a system level, by a system administrator / devops (in which case for me environment variables are superior for me). Disagree. It's not something we ever want at a system level, it's somewhere within the range of a single session - single execution. Usually runtime options will be completely meaningless for a regular user. Also, will you document them when you use --help? Or course not, just as you would not document the envvar(s). R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: D2 port of Sociomantic CDGC available for early experiments
On Tue, 21 Oct 2014 23:52:22 +0100, Leandro Lucarella l...@llucax.com.ar wrote: The runtime is not platform independent AT ALL. ^ implementation Why should you provide a platform agnostic way to configure it? Because it makes life easier for developers and cross platform development, not to mention documentation. The benefits far outweigh the costs. I can understand it if it's free, but if you have to sacrifice something just to get a platform agnostic mechanism, for me it's not worth it at all. Reasonable people may disagree. All these fear about how this can obscurely affect programs is totally unfunded. That just does not happen. Not at least commonly enough to ignore all the other advantages of it. Sure, but past/current env vars being used are used *privately* to a single program. NO, this is completely false, and why I think you are not entirely familiar with env vars in posix. LD_PRELOAD and LD_LIBRARY_PATH affects ALL, EACH and EVERY program for example. D or not D. Every single dynamically linked program. True. And the reason these behave this way is because we *always* want them to - the same is NOT true of the proposed vars for D. Which is my point. This is a super common mechanism. I never ever had problems with this. Did you? Did honestly you even know they existed? Yes. But this is beside the point, which I hope I have clarified now? Regan -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: D2 port of Sociomantic CDGC available for early experiments
On Mon, 20 Oct 2014 18:19:33 +0100, Sean Kelly s...@invisibleduck.org wrote: On Monday, 20 October 2014 at 10:39:28 UTC, Regan Heath wrote: Sure, but past/current env vars being used are used *privately* to a single program. What you're suggesting here are env vars which will affect *all* D programs that see them. If D takes over the world as we all hope it will then this will be a significantly different situation to what you are used to. I'm not advocating the approach, but you could create a run_d app that simply set the relevant environment args and then executed the specified app as a child process. The args would be picked up by the app without touching the system environment. This would work on Windows as well as on *nix. Sure, but in this case passing an argument is both simpler and clearer (intent). This is basically trying to shoehorn something in where it was never intended to be used, envvars by design are supposed to affect everything running in the environment and they're the wrong tool for the job if you want to target specific processes, which IMO is a requirement we have. A specific example. Imagine we have the equivalent of the windows CRT debug malloc feature bits, i.e. never free or track all allocations etc. These features are very useful, but they are costly. Turning them on for an entire process tree may be unworkable - it may be too slow or consume too much memory. A more targeted approach is required. There are plenty of options, but a global envvar is not one of them. R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: D2 port of Sociomantic CDGC available for early experiments
On Fri, 17 Oct 2014 17:54:55 +0100, Leandro Lucarella l...@llucax.com.ar wrote: Regan Heath, el 17 de October a las 15:43 me escribiste: I think you've mistook my tone. I am not religious about this. I just think it's a bad idea for a program to alter behaviour based on a largely invisible thing (environment variable). It's far better to have a command line switch staring you in the face. But it's not the same. I don't mean to be rude, but all you (and Walter) are saying about environment is evidence of not knowing how useful they are in POSIX OSs I am aware of how they are used as I have had to deal with them in the past. :) what's the history in those OSs and what people expect from them. D is not simply for these OSs and should be as platform agnostic as possible for core functionality. All these fear about how this can obscurely affect programs is totally unfunded. That just does not happen. Not at least commonly enough to ignore all the other advantages of it. Sure, but past/current env vars being used are used *privately* to a single program. What you're suggesting here are env vars which will affect *all* D programs that see them. If D takes over the world as we all hope it will then this will be a significantly different situation to what you are used to. If you keep denying it usefulness and how they are different from command-line arguments, we'll keep going in circles. I am not denying they are useful. I am denying they are *better* than a command line argument *for this specific use case* Plus as Walter mentioned the environment variable is a bit like a shotgun, it could potentially affect every program executed from that context. We have a product here which uses env vars for trace flags and (without having separate var for each process) you cannot turn on trace for a single process in an execution tree, instead each child inherits the parent environment and starts to trace. So, your example is a D program, that spawns other D programs, so if you set an environment variable to affect the behaviour of the starting program, you affect also the behaviour of the child programs. Yes. How do you control which of these programs is affected by your global-affects-all-D-programs-env-var? This is a good example, and I can argue for environment variables for the same reason. If I want to debug this whole mess, using command-line options there is no way I can affect the whole execution tree to log useful debug information. Sure you can. You can do whatever you like with an argument, including passing a debug argument to sub-processes as required. Or, you could use custom env vars to do the same thing. What you *do not* want is a global env var that indiscriminately affects every program that sees it, this gives you no control. See, you proved my point, environment variables and command-line arguments are different and thus, useful for different situations. Sure, but the point is that a global env var that silently controls *all* D programs is a shotgun blast, and we want a needle. And.. when some of those flags have different meanings in different processes it gets even worse. Why would they? Don't create problems where there are any :) Sadly it exists .. I inherited it (the source is 20+ years old). Especially if one of those flags prints debugging to stdout, and the process is run as a child where input/output are parsed.. it just plain doesn't work. It's a mess. If you write to stdout (without giving the option to write to a log file) then what you did is just broken. Again, there is no point in inventing theoretical situations where you can screw anything up. You can always fabricate those. Let's stay on the domain of reality :) Sadly not theoretical. R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: D2 port of Sociomantic CDGC available for early experiments
On Fri, 17 Oct 2014 00:01:39 +0100, Leandro Lucarella l...@llucax.com.ar
wrote:
Regan Heath, el 14 de October a las 11:11 me escribiste:
I still don't understand why wouldn't we use environment variables for
what they've been created for, it's foolish :-)
As mentioned this is not a very windows friendly/like solution.
As mentioned you don't have to use a unique cross-platform solution, you
can have different solutions for different OSs. No need to lower down to
the worse solution.
You've got it backwards. I'm looking for a *better* solution than
environment variables, which are a truly horrid way to control runtime
behaviour IMHO. Something built into the language or runtime itself.
And, better yet would be something that is more generally useful - not
limited to GC init etc.
Wouldn't it be more generally useful to have another function like
main() called init() which if present (optional) is called
before/during initialisation. It would be passed the command line
arguments. Then a program can chose to implement it, and can use it
to configure the GC in any manner it likes.
Seems like this could be generally useful in addition to solving
this issue.
It is nice, but a) a different issue, this doesn't provide
initialization time configuration.
I don't follow. You want to execute some code A before other code B
occurs. This meets that requirement - assuming init() is called at the
point you need it to be called.
Think of development vs. devops. If
devops needs to debug a problem they could potentially re-run the
application activating GC logging, or GC stomping. No need to recompile,
no need to even have access to the source code.
./application -gclog
./application -gcstomp
..code..
init(string[] args)
{
if ..
}
Not need to recompile.
Some GC options might make sense for all D applications, in that case the
compiler default init() could handle those and custom init() functions
would simply call it, and handle any extra custom options.
Other GC/allocation options might be very application specific i.e.
perhaps the application code cannot support RC for some reason, etc.
And b) where would this init() function live? You'll have to define it
always
Surely not.
, even if you don't want to customize anything, otherwise the
compiler will have to somehow figure out if one is provided or not and
if is not provided, generate a default one. Not a simple solution to
implement.
Sounds pretty trivial to me.
R
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: D2 port of Sociomantic CDGC available for early experiments
On Thu, 16 Oct 2014 09:10:38 +0100, Dylan Knutson tcdknut...@gmail.com wrote: Wouldn't it be more generally useful to have another function like main() called init() which if present (optional) is called before/during initialisation. It would be passed the command line arguments. Then a program can chose to implement it, and can use it to configure the GC in any manner it likes. Seems like this could be generally useful in addition to solving this issue. Isn't this what module constructors are for? As for passed in parameters, I'm sure there's a cross platform way to retrieve them without bring passed them directly, ala how Rust does it. Provided module constructors occur early enough in the process I guess this would work. You would need to ensure the module constructor doing the GC configuration occurred first too I guess. R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: D2 port of Sociomantic CDGC available for early experiments
On Sat, 11 Oct 2014 01:45:48 +0100, Leandro Lucarella l...@llucax.com.ar wrote: Walter Bright, el 9 de October a las 17:28 me escribiste: On 10/9/2014 7:25 AM, Dicebot wrote: At the same time I don't see what real benefit such runtime options brings to the table. This is why in my PR garbage collector is currently chosen during compilation time. Choosing at compile time is probably best. This is not (only) about picking a GC implementation, but also about GC *options/configuration*. The fact that right now to select between concurrent or not would mean using a different GC altogether is just an implementation detail. As I said, if at some point we can merge both, this wouldn't be necessary. Right now GDGC can disable the concurrent scanning, among other cool things (like enabling memory stomping, enabling logging of allocations to a file, enable logging of collections to a file, controlling the initial pools of memory when the program starts, etc.). This is very convenient to turn on/off not exactly at *runtime* but what I call *initialization time* or program startup. Because sometimes recompiling the program with different parameters is quite annoying, and as said before, for stuff that needs to be initialized *before* any actual D code is executed, sometimes is not easy to be done *inside* D code in a way that's not horrible and convoluted. I still don't understand why wouldn't we use environment variables for what they've been created for, it's foolish :-) As mentioned this is not a very windows friendly/like solution. Wouldn't it be more generally useful to have another function like main() called init() which if present (optional) is called before/during initialisation. It would be passed the command line arguments. Then a program can chose to implement it, and can use it to configure the GC in any manner it likes. Seems like this could be generally useful in addition to solving this issue. R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: Scott Meyers' DConf 2014 keynote The Last Thing D Needs
On Tue, 27 May 2014 22:40:00 +0100, Walter Bright newshou...@digitalmars.com wrote: On 5/27/2014 2:22 PM, w0rp wrote: I'm actually a native speaker of 25 years and I didn't get it at first. Natural language communicates ideas approximately. What bugs me is when people say: I could care less. I've always assumed some sort of sentence finishing laziness on their part. As in, I could care less, but it would be pretty hard to do so or something like that. R
Re: Scott Meyers' DConf 2014 keynote The Last Thing D Needs
On Thu, 29 May 2014 20:40:10 +0100, Walter Bright newshou...@digitalmars.com wrote: On 5/29/2014 11:25 AM, Dmitry Olshansky wrote: Agreed. The simple dream of automatically decoding UTF and staying Unicode correct is a failure. Yes. Attempting to hide the fact that strings are UTF-8 is just doomed. It's like trying to pretend that floating point does not do rounding. It's far more practical to embrace what it is and deal with it. Yes, D programmers will need to understand what UTF-8 is. I don't see any way around that. And it's the right choice. 4 of the 7 billion people in the world today are in Asia and by 2100 80% of the worlds population will be in Asia and Africa. http://bigthink.com/neurobonkers/it-is-not-about-political-views-or-ideologies-it-is-blunt-facts-which-are-not-known R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: Interesting rant about Scala's issues
On Mon, 07 Apr 2014 00:17:45 +0100, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: On 4/6/14, 10:52 AM, Walter Bright wrote: On 4/6/2014 3:31 AM, Leandro Lucarella wrote: What I mean is the current semantics of enum are as they are for historical reasons, not because they make (more) sense (than other possibilities). You showed a lot of examples that makes sense only because you are used to the current semantics, not because they are the only option or the option that makes the most sense. I use enums a lot in D. I find they work very satisfactorily. The way they work was deliberately designed, not a historical accident. Sorry, I think they ought to have been better. -- Andrei Got a DIP/spec/design to share? R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: Interesting rant about Scala's issues
On Mon, 07 Apr 2014 16:15:41 +0100, Paulo Pinto pj...@progtools.org
wrote:
Am 07.04.2014 12:07, schrieb Regan Heath:
On Mon, 07 Apr 2014 00:17:45 +0100, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 4/6/14, 10:52 AM, Walter Bright wrote:
On 4/6/2014 3:31 AM, Leandro Lucarella wrote:
What I mean is the current semantics of enum are as they are for
historical reasons, not because they make (more) sense (than other
possibilities). You showed a lot of examples that makes sense only
because you are used to the current semantics, not because they are
the
only option or the option that makes the most sense.
I use enums a lot in D. I find they work very satisfactorily. The way
they work was deliberately designed, not a historical accident.
Sorry, I think they ought to have been better. -- Andrei
Got a DIP/spec/design to share?
R
How they work in languages like Ada.
Ok, brief look at those shows me enums can be converted to a Pos index
but otherwise you cannot associate a numberic value with them, right?
So if we had that in D, Walters examples would look like..
1)
enum Index { A, B, C }
T[Index.C.pos + 1] array; // perhaps?
...
array[Index.B.pos] = t; // yes?
2)
array[Index.A.pos + 1] = t; // yes?
3)
enum Mask { A=1,B=4 } // not possible?
Mask m = A | B; // Error: incompatible operator | for enum
Have I got that right?
For a proposal like this to even be considered I would imagine it would
have to be backward compatible with existing uses, so you would have to be
proposing a new keyword or syntax on enum to trigger typesafe enums,
perhaps typesafe is a good keyword, e.g.
typesafe enum Index { A, B, C } // requires use of .pos to convert to int
0, 1, or 2.
enum Index { A, B, C } // existing pragmatic behaviour
R
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: Article: Increasing the D Compiler Speed by Over 75%
On Mon, 29 Jul 2013 20:05:08 +0100, John Colvin john.loughran.col...@gmail.com wrote: On Monday, 29 July 2013 at 18:34:16 UTC, Walter Bright wrote: On 7/29/2013 5:28 AM, John Colvin wrote: Seriously... Walter wouldn't have got his mechanical engineering degree if he didn't know how to calculate a speed properly. It's a grade school concept :-) A college freshman physics problem would be calculating the delta V of a rocket fired in space given the fuel weight, rocket empty weight, thrust, etc. Physics graduate / soon to be PhD student here :) It's sad how few rockets were involved in my degree... Time to fix that! https://kerbalspaceprogram.com/ R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: Programming in D book is about 88% translated
On Tue, 16 Jul 2013 00:28:36 +0100, Ali Çehreli acehr...@yahoo.com wrote: On 07/15/2013 03:26 AM, deadalnix wrote: On Saturday, 29 June 2013 at 02:35:27 UTC, Ali Çehreli wrote: Thinking that it is free enough, I had chosen this: http://creativecommons.org/licenses/by-nc-sa/3.0/us/ NC is always kind of problematic as loosely defined. This is by far the dark corner of CC. It must be touching an irrational side of humans: Giving it completely free is fine, but other people's making profit off of it is somehow wrong! I can't explain why I feel that way. Must be primal genes... :) I think it basically boils down to fairness (interesting, there are studies which show other primates exhibit and understanding of fairness - which is kinda cool http://www.youtube.com/watch?v=-KSryJXDpZo). When someone sells something they are essentially saying you can have this but I need some compensation for the work/effort I expended creating it (or bringing it to you etc). So, if someone sells something they did no work to create then we see that as unfair. There is nothing to compensate, so asking for compensation is unfair. We have no problem with them giving it away free, because in that case they're not asking for something they haven't earned. There may also be an impression that if they're selling it, they are asserting they did create it, that it is their work in some way, and this claim is fraudulent and again conflicts with our sense of fairness. R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: Why implicit conversion of string literal to char[] does not works?
On Tue, 02 Jul 2013 12:33:14 +0100, Michal Minich michal.min...@gmail.com wrote: On Tuesday, 2 July 2013 at 11:29:05 UTC, Dicebot wrote: On Tuesday, 2 July 2013 at 11:26:59 UTC, Michal Minich wrote: But ... I'm asking only about implicit conversion of string literal, not arbitrary expressions of string type. char[] str = abc.dup; Thanks, that is workaround I didn't know about. I'm really interested about reasons why it doesn't works (without dup/cast). At some point it had to be disabled. But I really cannot find a reason why that would be useful. It is done for performance reasons. On UNIX the compiler will put the literal abc into read only memory. It could/should do the same on windows but doesn't yet (I believe). So, the compiler is treating them as such, by giving them the type immutable(char)[] (AKA string). And, the spec should, if it doesn't, define string literals to be immutable. In older versions of DMD we didn't have string AKA immutable(char), in fact at one point we didn't have immutable at all. At that time, abc was typed as char[] and people on UNIX systems ran headlong into an access violation attempting to write to ROM :p R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: Why implicit conversion of string literal to char[] does not works?
On Tue, 02 Jul 2013 14:33:09 +0100, Michal Minich michal.min...@gmail.com wrote: On Tuesday, 2 July 2013 at 13:07:40 UTC, Regan Heath wrote: It is done for performance reasons. On UNIX the compiler will put the literal abc into read only memory. It could/should do the same on windows but doesn't yet (I believe). So, the compiler is treating them as such, by giving them the type immutable(char)[] (AKA string). And, the spec should, if it doesn't, define string literals to be immutable. Ok I understand. What I did as a first thing when I get error on char[] x = a was char x = cast(char[])a, Which was obviously incorrect - as the a was/should be placed in rom. So if this expression is allays wrong - casting string literal to mutable, then compiler should emit an error on this (If one implementation (dmd/win) makes this valid, it still doesn't mean compiler should honor implementation over specification - amusing it is specified that strings go into rom...) As Dicebot has replied, cast() is the mechanism the programmer uses to force the compiler to do what s/he wants regardless of what it thinks. The compiler assumes that if cast() is used that the programmer knows what they're doing. Only use cast() if you have no other option. In this simple case, the compiler could detect the error, or as you say below take the cast(char[]) as a hint to place the a in RAM instead. But, 99.9% of cases are more complex than this simple one, so the cost/benefit of detecting the error make it very low priority, perhaps never to be implemented. Likewise for the place in RAM idea. Both/either would be nice, but neither is necessary now provide a lot of benefit. Also, given you explanation, I see it as good to type auto x = a as string, but give explicit notation char[] x = a - I don't see reason to not allow string literal to be typed as both char[] and string at the same time, and convert to char[] - and also place in ram, if explicitly asked. To explicitly place a in RAM you would write char[] x = a.dup; Or: char[] x = new char[1]; x[0] = 'a'; The only reason that comes now to mi mind is when working with old code base - before auto and immutable(char)[] .. the code had to use char[] x = a, but these must be all eliminated by now Old code using char[] x = a was technically invalid (it just happened to run ok on windows, or linux if no mutation was done) and will now error as such. For old code raising this error the correct solution .. - if mutable is required is to add .dup. - if mutable is not required is to replace char[] with string or auto. R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: DConf 2013 Day 3 Talk 1: Metaprogramming in the Real World by Don Clugston
On Fri, 14 Jun 2013 23:34:56 +0100, Nick Sabalausky seewebsitetocontac...@semitwist.com wrote: On Thu, 13 Jun 2013 11:48:52 +0100 Regan Heath re...@netmail.co.nz wrote: I use Notepad++ now and have used TextPad in the past. But, those are just text editors with syntax highlighting (fairly flexibly and simply customisable highlighting BTW). What are the basic features you would require of a development environment, I am thinking of features which go beyond the basic concept of a text editor, such as: - The concept of a 'project' or some other collection of source files which can be loaded/displayed in some fashion to make it easier to find/select/edit individual files - The ability to hook in 'tools' to key presses like compile executing dmd ... or similar. I've been using Programmer's Notepad 2 (for *all* my development for the past few years), which is *mostly* a syntax highlighting editor, but also has a concept of projects, configurable tools, and click an error to jump to it's line in the source. And I've never had it crash or get wonky, or slowdown, or stall, or use a lot of resources, ever. Oh, yes, the ability to capture the compiler output and do a bit of a parse and jump to error is another top IDE feature IMO. R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: DConf 2013 Day 3 Talk 1: Metaprogramming in the Real World by Don Clugston
On Fri, 14 Jun 2013 23:34:56 +0100, Nick Sabalausky seewebsitetocontac...@semitwist.com wrote: click an error to jump to it's line in the source. Is there a hotkey for this? .. it's little things like having a configurable hotkey (so I can make it F4 like in MSVC that make or break a new IDE/editor IMO). R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: DConf 2013 Day 3 Talk 1: Metaprogramming in the Real World by Don Clugston
On Thu, 13 Jun 2013 19:49:09 +0100, Walter Bright newshou...@digitalmars.com wrote: On 6/13/2013 3:48 AM, Regan Heath wrote: What are the basic features you would require of a development environment, People tell me that intellisense is the #1 feature. I could go either way with intellisense. Sometimes I need a hand remembering what I'm doing, but mostly I'm just fine. What bugs me more is using an editor with no F1 - go to documentation for this function or no F12 - take me to the definition of this symbol. Those are invaluable - providing the help system doesn't take 10 years to load I'm looking at you (all versions of MSVC post 6). R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: DConf 2013 Day 3 Talk 1: Metaprogramming in the Real World by Don Clugston
On Thu, 13 Jun 2013 20:39:17 +0100, Peter Alexander peter.alexander...@gmail.com wrote: On Thursday, 13 June 2013 at 18:49:14 UTC, Walter Bright wrote: On 6/13/2013 3:48 AM, Regan Heath wrote: What are the basic features you would require of a development environment, People tell me that intellisense is the #1 feature. The debugger is the #1 feature I'd miss from my day job if I didn't use Visual Studio. Feature wise, I'm sure gdb has most if not all VS has, but in VS everything is just there in front of you, easily usable (you don't need to consult the manual, or remember archaic commands). Using gdb vs. Visual Studio feels like trying to do web browsing via the command line. Agreed 100% - totally forgot about integrated debugging it's probably my #1 feature. Intellisense is a definite must, and proper intellisense, i.e. actually shows me what members a variable has, and not just some crappy lookup in the current file for potential members. Needs to work with templates, macros etc. as well. Meh, I could go either way on this, provided I have.. Go to definition and Find all references are must haves as well. Again, they need to work properly, not just some half-assed grep script that throws up lots of false positives. Again, needs to work with templates, macros, etc. These are essential, my #2/3 features. R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: DConf 2013 Day 3 Talk 1: Metaprogramming in the Real World by Don Clugston
On Thu, 13 Jun 2013 21:12:31 +0100, Don turnyourkidsintoc...@nospam.com wrote: On Thursday, 13 June 2013 at 16:35:08 UTC, Regan Heath wrote: On Thu, 13 Jun 2013 15:32:03 +0100, Colin Grogan grogan.co...@gmail.com wrote: On Thursday, 13 June 2013 at 10:48:52 UTC, Regan Heath wrote: On Thu, 13 Jun 2013 08:31:03 +0100, Don turnyourkidsintoc...@nospam.com wrote: On Thursday, 13 June 2013 at 06:58:22 UTC, Jacob Carlborg wrote: On 2013-06-11 14:33, Andrei Alexandrescu wrote: Reddit: http://www.reddit.com/r/programming/comments/1g47df/dconf_2013_metaprogramming_in_the_real_world_by/ Hackernews: https://news.ycombinator.com/item?id=5861237 Twitter: https://twitter.com/D_Programming/status/344431490257526785 Facebook: https://www.facebook.com/dlang.org/posts/655271701153181 Youtube: http://youtube.com/watch?v=pmwKRYrfEyY Please drive discussions on the social channels, they help D a lot. I really don't understand the problem with IDE. He mentions that he's not interested in any autocompletion, refactoring or anything like that. Actually not. I'm just opposed to any work on them right now. The point is that all of those things are COMPLETELY WORTHLESS if the IDE crashes. It's not just a bug. It's an absolute showstopper, and I'm begging the community to do something about it. Fix the crashes, and then we can talk. I use Notepad++ now and have used TextPad in the past. But, those are just text editors with syntax highlighting (fairly flexibly and simply customisable highlighting BTW). What are the basic features you would require of a development environment, I am thinking of features which go beyond the basic concept of a text editor, such as: - The concept of a 'project' or some other collection of source files which can be loaded/displayed in some fashion to make it easier to find/select/edit individual files - The ability to hook in 'tools' to key presses like compile executing dmd ... or similar. ... R How about a GUI front end to vibe-d's dub? I use that extensively on command line and find it very good, I imagine it would be easy enough write a GUI for it... Or, a plugin for an existing editor. Or, a 'tool' configured in an existing editor to run dub in a certain way. All good ideas. What I'm driving at here is trying to find Don's minimal requirements beyond stability, Must not be worse than Notepad. g I don't have any requirements. I *only* care about stability at this point. Ok.. but that doesn't give ppl anything to aim for as a starting point.. I'm not personally looking for an IDE. I'm more a command line guy. So you write all your code using copy con? :p So, you use vi? D has fifty people contributing to the compiler, but only two or three working on IDEs. We need a couple more. And that's really all I'm saying. Valid point, but to get more people interested I think we need a concrete goal and/or a list of faults with the existing competition. R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: DConf 2013 Day 3 Talk 1: Metaprogramming in the Real World by Don Clugston
On Thu, 13 Jun 2013 08:31:03 +0100, Don turnyourkidsintoc...@nospam.com wrote: On Thursday, 13 June 2013 at 06:58:22 UTC, Jacob Carlborg wrote: On 2013-06-11 14:33, Andrei Alexandrescu wrote: Reddit: http://www.reddit.com/r/programming/comments/1g47df/dconf_2013_metaprogramming_in_the_real_world_by/ Hackernews: https://news.ycombinator.com/item?id=5861237 Twitter: https://twitter.com/D_Programming/status/344431490257526785 Facebook: https://www.facebook.com/dlang.org/posts/655271701153181 Youtube: http://youtube.com/watch?v=pmwKRYrfEyY Please drive discussions on the social channels, they help D a lot. I really don't understand the problem with IDE. He mentions that he's not interested in any autocompletion, refactoring or anything like that. Actually not. I'm just opposed to any work on them right now. The point is that all of those things are COMPLETELY WORTHLESS if the IDE crashes. It's not just a bug. It's an absolute showstopper, and I'm begging the community to do something about it. Fix the crashes, and then we can talk. I use Notepad++ now and have used TextPad in the past. But, those are just text editors with syntax highlighting (fairly flexibly and simply customisable highlighting BTW). What are the basic features you would require of a development environment, I am thinking of features which go beyond the basic concept of a text editor, such as: - The concept of a 'project' or some other collection of source files which can be loaded/displayed in some fashion to make it easier to find/select/edit individual files - The ability to hook in 'tools' to key presses like compile executing dmd ... or similar. ... R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: DConf 2013 Day 3 Talk 1: Metaprogramming in the Real World by Don Clugston
On Thu, 13 Jun 2013 15:32:03 +0100, Colin Grogan grogan.co...@gmail.com wrote: On Thursday, 13 June 2013 at 10:48:52 UTC, Regan Heath wrote: On Thu, 13 Jun 2013 08:31:03 +0100, Don turnyourkidsintoc...@nospam.com wrote: On Thursday, 13 June 2013 at 06:58:22 UTC, Jacob Carlborg wrote: On 2013-06-11 14:33, Andrei Alexandrescu wrote: Reddit: http://www.reddit.com/r/programming/comments/1g47df/dconf_2013_metaprogramming_in_the_real_world_by/ Hackernews: https://news.ycombinator.com/item?id=5861237 Twitter: https://twitter.com/D_Programming/status/344431490257526785 Facebook: https://www.facebook.com/dlang.org/posts/655271701153181 Youtube: http://youtube.com/watch?v=pmwKRYrfEyY Please drive discussions on the social channels, they help D a lot. I really don't understand the problem with IDE. He mentions that he's not interested in any autocompletion, refactoring or anything like that. Actually not. I'm just opposed to any work on them right now. The point is that all of those things are COMPLETELY WORTHLESS if the IDE crashes. It's not just a bug. It's an absolute showstopper, and I'm begging the community to do something about it. Fix the crashes, and then we can talk. I use Notepad++ now and have used TextPad in the past. But, those are just text editors with syntax highlighting (fairly flexibly and simply customisable highlighting BTW). What are the basic features you would require of a development environment, I am thinking of features which go beyond the basic concept of a text editor, such as: - The concept of a 'project' or some other collection of source files which can be loaded/displayed in some fashion to make it easier to find/select/edit individual files - The ability to hook in 'tools' to key presses like compile executing dmd ... or similar. ... R How about a GUI front end to vibe-d's dub? I use that extensively on command line and find it very good, I imagine it would be easy enough write a GUI for it... Or, a plugin for an existing editor. Or, a 'tool' configured in an existing editor to run dub in a certain way. All good ideas. What I'm driving at here is trying to find Don's minimal requirements beyond stability, in other words trying to define the goal posts to work towards. R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: DConf 2013 Day 2 Talk 3: C# to D by Adam Wilson
On Mon, 03 Jun 2013 18:27:10 +0100, Adam Wilson flybo...@gmail.com wrote: On Mon, 03 Jun 2013 02:16:45 -0700, Regan Heath re...@netmail.co.nz wrote: On Sat, 01 Jun 2013 04:06:06 +0100, Juan Manuel Cabo juanmanuel.c...@gmail.com wrote: On 05/31/2013 05:18 PM, Nick Sabalausky wrote: On Fri, 31 May 2013 15:29:40 +0100 Regan Heath re...@netmail.co.nz wrote: I have old SHA etc hashing routines in old style D, this makes me want to spend some time bringing them up to date... http://dlang.org/phobos/std_digest_sha.html Since 2.061, IIRC. Funny.. the module listing on the left is not in alpha ordering, so I completely missed them. The sha digest in phobos is SHA1. SHA256 and SHA512 are still missing. This too.. I have those, plus a few others. R Any chance of getting those merged into Phobos? It just needs some time/love. I have very old versions of the source (prior to it's inclusion in Tango). Last time I looked the Tango devs had made some structural changes and found/fixed an endian related bug. So.. my code needs re-structuring to fit the current phobos model, it needs the endian bug fixed, and it needs complete documentation (it has none). I am happy to donate the existing code, in it's current sorry state to whomever has the time for all that. It could use some testing on a big endian platform - as I have done none. There are unittests which perform the standard tests and maybe a few others IIRC. It's been a while.. R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: DConf 2013 Day 2 Talk 3: C# to D by Adam Wilson
On Sat, 01 Jun 2013 04:06:06 +0100, Juan Manuel Cabo juanmanuel.c...@gmail.com wrote: On 05/31/2013 05:18 PM, Nick Sabalausky wrote: On Fri, 31 May 2013 15:29:40 +0100 Regan Heath re...@netmail.co.nz wrote: I have old SHA etc hashing routines in old style D, this makes me want to spend some time bringing them up to date... http://dlang.org/phobos/std_digest_sha.html Since 2.061, IIRC. Funny.. the module listing on the left is not in alpha ordering, so I completely missed them. The sha digest in phobos is SHA1. SHA256 and SHA512 are still missing. This too.. I have those, plus a few others. R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: DConf 2013 Day 2 Talk 3: C# to D by Adam Wilson
On Fri, 31 May 2013 13:33:21 +0100, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: http://www.reddit.com/r/programming/comments/1feem1/dconf_2013_day_2_talk_3_from_c_to_d_by_adam_wilson/ Excellent talk. Gives us a good idea of the things which are missing for C# conversion and less so in general, and good ideas where to concentrate our efforts. I have old SHA etc hashing routines in old style D, this makes me want to spend some time bringing them up to date... R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: dmd 2.063 beta 5
On Thu, 23 May 2013 19:52:14 +0100, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: On 5/23/13 2:08 PM, Marco Leise wrote: Am Thu, 23 May 2013 13:06:44 -0400 schrieb Andrei Alexandrescuseewebsiteforem...@erdani.org: TDPL 8.4 discusses a raw/cooked model of construction. The same principle should apply to const/immutable member construction: you get to cook the field, but you can't taste it while raw. You are not making friends with Japanese D users. Good one! And incidentally I love sashimi :o). Well let me amend it: if your plan is to cook it, don't taste it before. mmm cookie dough/cake batter. :p R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: DConf 2013 Day 1 Talk 6: Concurrent Garbage Collection for D by Leandro Lucarella
On Mon, 20 May 2013 13:50:25 +0100, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: On reddit: http://www.reddit.com/r/programming/comments/1eovfu/dconf_2013_day_1_talk_6_concurrent_garbage/ This may be the Windows Copy On Write feature mentioned in the QA at the end: http://support.microsoft.com/kb/103858 .. but it's not clear to me how useful this is for fork emulation or similar. R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: DConf 2013 Day 1 Talk 2: Copy and Move Semantics in D by Ali Cehreli
On Thu, 16 May 2013 20:52:35 +0100, Jonathan M Davis jmdavisp...@gmx.com wrote: On Thursday, May 16, 2013 11:13:27 Regan Heath wrote: So, who's responsibility is it to ensure the function/method call executes without errors caused by mutable shared data? I think that for the most part, the question of thread-safety and const that you've been discussing is moot. const by itself is thread-local by definition. Good point. Somehow I totally missed that. R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: DConf 2013 Day 1 Talk 2: Copy and Move Semantics in D by Ali Cehreli
On Wed, 15 May 2013 18:32:03 +0100, Jonathan M Davis jmdavisp...@gmx.com wrote: What's less clear is what to do when a function accepts strings but isn't really operating on them (e.g stuff in std.file or std.net.curl), as they may need immutable(char)[]. In that case, it depends on what's being done with the string. For better or worse though, at this point, I think that it's most common to just accept string for those cases. It's not something that always has a clearcut answer though. I agree with the first bit, but I think we can make a clear-cut decision on this last.. To me it comes down to a Q of responsibility. Should a function/method (like those in std.file) require that the argument will not change for the lifetime of the function/method call, or is it reasonable for the function/method to assume the caller will ensure that. Taking by immutable(char) will guarantee it will not change (ignoring blunt forced cast) whereas const(char) will not, but there is an implicit assumption that it wont change and the caller should guarantee that. So, who's responsibility is it to ensure the function/method call executes without errors caused by mutable shared data? I think it's the callers responsibility and think that const(char) is the better choice in cases like this, my reasoning as follows.. 1. Callers should already be protecting shared mutable state before using it, this is a common and well understood pattern which cannot be avoided even if we use immutable(char) arguments (caller still needs to ensure shared state is not mutated while they make the immutable copy to pass). 2. In most cases, in most code shared data is less common, especially for calls to functions/methods like those mentioned here. So, we chose the option which is nicer for the common case, and const(char) is it. 3. const(char) does not require duplication of arguments by caller or callee so is more efficient, one of D's primary goals and a good baseline to build upon. So, I think in cases where the function/method doesn't need to retain the argument for longer than the lifetime of the call it should accept const(char), otherwise as you mentioned earlier it's better to simply require the caller provide the immutable(char) you require. This decision has a nice side-effect of implicitly documenting the lifetime/usage of arguments, const(char) means call lifetime, immutable(char) means longer, possibly indefinitely (until termination). Thoughts? R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: DConf 2013 Day 1 Talk 2: Copy and Move Semantics in D by Ali Cehreli
On Thu, 16 May 2013 11:25:48 +0100, Dicebot m.stras...@gmail.com wrote: On Thursday, 16 May 2013 at 10:13:28 UTC, Regan Heath wrote: ... I agree that this is a caller responsibility. What leaves me in doubts is how this responsibility is enforced though. With const nothing in type system prevents caller to violate that contract and mutate data during function call. Because, well, const does not guarantee that data is not mutated and thus it is a valid action. True, it's not enforced. But, that's because the responsibility lies with the caller, and I think this is a reasonable position to take in these cases (std.file methods which use but do not retain the argument post-call) Contrary, immutable is absolutely strict requirement from a function that caller must take care of passed argument during the function call or fall into undefined behavior. Explicit usage of assumeUnique by caller is clear sign for a type system yes, I know what I am doing, I am responsible. And no accidents possible. Sure, but it's more verbose, and therefore annoying for the general case (where the data is not shared). And.. The issue here is not common (because shared data is not common) /and/ where shared data is used it should already be protected (because that's the existing pattern). So that leaves us a very small number of cases which are broken and the solution to all of them is to protect the shared data(*) /not/ to call assumeUnique. The cases where assumeUnique could be used, so could const(char). Basically I think the assumeUnique idea is only useful where const(char) is useful and const(char) is far nicer. (*) you cannot even just call idup, because what if the data is in the process of mutating when you do? You have to protect the shared data with a mutex or similar. Regan -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: DConf 2013 Day 1 Talk 2: Copy and Move Semantics in D by Ali Cehreli
On Thu, 16 May 2013 12:06:18 +0100, Dicebot m.stras...@gmail.com wrote: On Thursday, 16 May 2013 at 10:41:51 UTC, Regan Heath wrote: True, it's not enforced. But, that's because the responsibility lies with the caller, and I think this is a reasonable position to take in these cases (std.file methods which use but do not retain the argument post-call) You see, if it is not enforced, than no one has any real responsibility. Multi-threading based on convention has been used quite a lot in C/C++ according to my experience it sucks. D developers has done a lot of work in pursuing type system that is aware of multi-threading and can make certain enforcements / provide guarantees. It makes no sense to stop in the midway. You're missing my main point. The number of actually broken cases are small and the solution is always always always to protect the shared data. assumeUnique cannot help in these cases, so the caller ends up calling idup. The caller cannot safely call idup unless the shared data is protected. So, all roads lead to - protect the shared data. Given that, const(char) is 100% perfectly safe. One of D slogans I remember was Safe by default, efficient when needed. This is exactly one of such cases. Any type contract should be stated explicitly. Everywhere. As shown above, just using immutable(char) does not ensure it is safe. The caller could use assumeUnique mistakenly, or call idup without protecting the shared state, both are subtle bugs and the only solution is - protect the shared data. Any impression of complete safety from immutable(char) is therefore false. R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: DConf 2013 Day 1 Talk 2: Copy and Move Semantics in D by Ali Cehreli
On Sun, 12 May 2013 01:22:57 +0100, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: On 5/11/13 7:39 PM, Nick Sabalausky wrote: Furthermore, my whole point was nothing more than to merely suggest that *maybe* the delay should simply be somewhat less, *not* a demand or expectation, and *not* even a suggestion that they should all be released as soon as is technically feasable. Sure - let's take a quick poll on what would be the best release schedule. I agree that 2 a week is reasonable given the motivations and reasoning already discussed. R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: DConf 2013 Opening Keynote by Walter Bright: video and slides available
On Fri, 10 May 2013 11:45:21 +0100, JN 666to...@wp.pl wrote: Can't wait for Manu's slides/video to come up :) I want them all! :D I have to disagree with some of the points in the keynote though. The part with algorithm in D example, I don't know but map(a = a.idup) isn't exactly obvious. Agreed. This is a bit of a wart IMO. About the scope vs no-scope - it'd be interesting to see how try-finally version looks like in comparison. Have you seen Andre's slides comparing these.. does anyone have a link? About the IDE discussion near the end of keynote - I know a lot of you people are happy just using Vim/Emacs + command line compiling, but having a proper IDE is a big part in language adoption nowadays. I can't speak for VisualD and MonoD, but I've heard they are nice, I am using DDT which is also good, although debugging on windows with DMD isn't that fun. A good example would be Visual Basic 6.0 - everyone seems to hate it, yet a lot of people (mostly non-programmers) use it to make apps because in few clicks you can make a GUI application. Same would apply to Java too - language isn't the best there is, and coding Java without Netbeans/Eclipse/IntelliJ would be a new dimension of pain but with those IDEs writing stuff is 'fun'. I think Walters point about not making a language require an IDE to add boilerplate is a good one, the boilerplate itself, and the fact the language requires it is the real issue, not whether an IDE is used to generate it. As for IDE's in general, I use MSVC pretty much predominantly and when doing GUI development in C# it's RAD :p Doing the same thing with a text editor would be painful. The boilerplate in this case is the skeleton/structure for the GUI library, not the language, so it's a separate boilerplate issue, and not one that good language design can obviate. That, plus all the other nice features of an IDE - many of which can be synthesized by an editor with scripting support, are the reasons to use one. Integrated debugging, etc. All in all, great to see D community getting together to discuss and share stuff =) Wish I could have made the trip too :( R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: A look at the D programming language by Ferdynand Górski
On Tue, 15 Jan 2013 20:06:05 -, Walter Bright newshou...@digitalmars.com wrote: On 1/15/2013 4:09 AM, bearophile wrote: One common indentation-related bug is caused by relying on the indentation to understand code, while the curly brace language compiler ignores what you were seeing and only sees the braces. I have seen many cases of delayed code understanding caused by that. Making the syntax more DRY (this means stating the logical indentation using only one communication channel) helps avoid those mistakes (and reduces the visual noise, further helping code readability). This is the job of a syntax aware editor (and other source code formatting tools), not the language. In my not-so-humble opinion. BTW, I'd like to see a source code formatter for D. Anyone want to step up? In an ideal world the source code would be stored in file on disk in some standard format, and displayed in each programmers editor in their own preferred format. It could end all arguments about code formatting, for good. R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: Walter charms the audience at Sioux
On Fri, 24 Aug 2012 13:44:55 +0100, Simen Kjaeraas simen.kja...@gmail.com wrote: On Fri, 24 Aug 2012 13:52:04 +0200, F i L witte2...@gmail.com wrote: Peter Alexander wrote: There's no such thing as a perfect language. Note the asterisks. What I'm used to, *this* means bold. *Perfect* thus means absolutely perfect. Perfect*, on the other hand, would mean either 'more information below' or 'piece of crap', depending on whether it's in a technical text or an ad. And perfect might mean depends who you ask :p R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: Yet another incomplete D cryptography library.
On Thu, 09 Aug 2012 23:13:19 +0100, Nvirjskly nvirjs...@gmail.com wrote: This is a skeleton library that I decided to push out in order to motivate myself to finish it. It supports AES, and Threefish in terms of block ciphers, and SHA1. I want to implement all SHA3 finalists, fast hashes like murrmurr, and many more block ciphers (DES c.) https://github.com/Nvirjskly/cryptod Nice work. Hopefully when the std hash/digest/crypto module(s) have been accepted into phobos you'll contribute any missing algorithms.. :) R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: Pull freeze
On Tue, 31 Jul 2012 16:54:17 +0100, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: On 7/31/12 11:46 AM, deadalnix wrote: We actually have to « reverse » the way thing are done. You can't go to the other side of a gap in 2 steps. We face a change that cannot be gradually adopted. Then I need more education. I thought a good thing to do is use branching for releases, and that we can start doing that without much difficulty. No? If not, then someone or several someones need to produce a good document to describe the process they're suggesting. It seems that some people here agree on a process, but others have slightly differing ideas. The issue is deciding on the best model for D, and making it clear to everyone. So, definition is step 1, education is step 2 and implementation is steps 3+. I think a wiki page which is editable by those with concerns might be a good idea, or even a DIP. It should describe the ideal workflow and give concrete examples of common processes i.e. releases, dealing with merges/rebases etc for bug fixes etc. I've never used GIT, nor do I contribute to D at present or I might have had a crack at this, someone else would definitely be better suited. R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: Robert Schadek's Distributed Multithreaded Caching D Compiler
On Thu, 24 May 2012 11:56:56 +0100, Jacob Carlborg d...@me.com wrote: On 2012-05-24 11:47, deadalnix wrote: Why not attend? I'd love to do that, but it will be impossible for me. Coming from europe just for a conference (it imply take holidays and a quite expansive travel) isn't really realistic. And I'm pretty sure other europeans can confirm how frustrating this is. Basicaly mostly everything take place in the US, and it is unrealistic to come most of the time. I can confirm the frustration. :( Thirded! R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: D forums now live!
On Sun, 19 Feb 2012 18:53:55 -, Vladimir Panteleev vladi...@thecybershadow.net wrote: On Sunday, 19 February 2012 at 16:16:29 UTC, bearophile wrote: I don't understand how you can claim that it takes up vertical space when it's alongside the post. The only case where it would waste vertical space is when the post is a few lines long. I meant there is a empty vertical rectangle, it steals a rectangular surface. Doing so steals both vertical and horizontal space. This layout is used by nearly all web forum software. It was chosen to be familiar to people used to those forums. How would you design the layout? I've not see a web forum do this yet, but I guess ideally the message text would flow around the image as you often see in newspapers and magazines. That way lines of message text below the bottom of the image would be full width and not have a large image width margin on them, if you see what I mean. Regan -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: dmd 1.070 and 2.055 release
On Thu, 08 Sep 2011 16:52:37 +0100, Andrej Mitrovic
andrej.mitrov...@gmail.com wrote:
Ok cool, my DWin project successfully compiles. The WinAPI bindings
are missing extern(Windows) specifiers for its function aliases and
2.055 seems to enforce this now, so that api will have to be updated.
The only thing that's bothering me is the notices, there's just too
many of them.
For example this:
import std.stdio;
import std.path;
void main()
{
writeln(curdir.rel2abs);
}
turns into this:
Notice: As of Phobos 2.055, std.path.rel2abs has been scheduled for
deprecation in February 2012. Please use absolutePath instead.
Notice: As of Phobos 2.055, std.path.isabs has been scheduled for
deprecation in February 2012. Please use isAbsolute instead.
Notice: As of Phobos 2.055, std.path.getDrive has been scheduled for
deprecation in February 2012. Please use driveName instead.
Notice: As of Phobos 2.055, std.path.join has been scheduled for
deprecation in February 2012. Please use buildPath instead.
Notice: As of Phobos 2.055, std.path.rel2abs has been scheduled for
deprecation in February 2012. Please use absolutePath instead.
Notice: As of Phobos 2.055, std.path.isabs has been scheduled for
deprecation in February 2012. Please use isAbsolute instead.
Notice: As of Phobos 2.055, std.path.getDrive has been scheduled for
deprecation in February 2012. Please use driveName instead.
Notice: As of Phobos 2.055, std.path.join has been scheduled for
deprecation in February 2012. Please use buildPath instead.
That is just unacceptable imho.
It needs to tell you about each one only once, then it will be much more
acceptable. Ideally, some way to switch deprecation notices off.
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
