Re: local import hijacking
On Thursday, 14 January 2016 at 14:56:39 UTC, Byron Heads wrote:
On Thursday, 14 January 2016 at 14:36:23 UTC, Daniel Kozak
wrote:
[...]
import std.experimental.logger;
void foo() {
import std.net.curl;
lots of curl calls
trace("hello");
.. more curl calls
}
void main() {
foo();
}
std.net.curl.CurlException@std\net\curl.d(4033): Couldn't
resolve host name on handle 2188398
0x00405F65
0x00405F10
0x0040275B
0x0040259E
0x0040202B
0x00402035
0x004257A7
0x004256A8
0x0041B7FF
0x769F337A in BaseThreadInitThunk
0x77429882 in RtlInitializeExceptionChain
0x77429855 in RtlInitializeExceptionChain
This was a 4 hour debug which made it worse as I was adding
more trace calls to figure out what was going on. My boss is
now on the fence, to many compiler bugs with D, he asked me to
switch to Java if I have to deal to many more issues like
this.. (https://issues.dlang.org/show_bug.cgi?id=15457 another
issue we had)
And this awesome stack trace helped me so much to track this
issue down...
Also why is this not allowed then?
import std.stdio;
void main() {
auto x = "foo";
for(int x = 0; x < 10; ++x) {
writeln(x);
}
}
Error: variable x is shadowing variable f335.main.x
Shadowing is bad and leads to bugs!
Re: local import hijacking
On Thursday, 14 January 2016 at 14:36:23 UTC, Daniel Kozak wrote:
V Thu, 14 Jan 2016 14:25:43 +
Byron Heads via Digitalmars-d
napsáno:
I got burned by this yesterday, this code should not compile
import std.experimental.logger : trace;
void foo() {
import std.net.curl : trace;
trace("hello");
}
void main() {
foo();
}
Not sure if this is a duplicate
https://issues.dlang.org/show_bug.cgi?id=15567
No this is OK, there is no reason to not compile.
It is same as:
import std.stdio;
string trace = "trace";
void foo() {
int trace = 7;
writeln(trace);
}
void main() {
foo();
writeln(trace);
}
local symbols can hide global symbols
import std.experimental.logger;
void foo() {
import std.net.curl;
lots of curl calls
trace("hello");
.. more curl calls
}
void main() {
foo();
}
std.net.curl.CurlException@std\net\curl.d(4033): Couldn't resolve
host name on handle 2188398
0x00405F65
0x00405F10
0x0040275B
0x0040259E
0x0040202B
0x00402035
0x004257A7
0x004256A8
0x0041B7FF
0x769F337A in BaseThreadInitThunk
0x77429882 in RtlInitializeExceptionChain
0x77429855 in RtlInitializeExceptionChain
This was a 4 hour debug which made it worse as I was adding more
trace calls to figure out what was going on. My boss is now on
the fence, to many compiler bugs with D, he asked me to switch to
Java if I have to deal to many more issues like this..
(https://issues.dlang.org/show_bug.cgi?id=15457 another issue we
had)
And this awesome stack trace helped me so much to track this
issue down...
local import hijacking
I got burned by this yesterday, this code should not compile
import std.experimental.logger : trace;
void foo() {
import std.net.curl : trace;
trace("hello");
}
void main() {
foo();
}
Not sure if this is a duplicate
https://issues.dlang.org/show_bug.cgi?id=15567
Re: if(arr) now a warning
On Wed, 29 Apr 2015 22:44:22 -0400, Steven Schveighoffer wrote: > On 4/29/15 8:35 PM, Martin Nowak wrote: >> Occasionally I'm using if (auto ary = func()), despite the fact that >> the semantics are wrong, but it's nice and short and works as long a >> func always returns null instead of empty slices. > > I wonder if it's possible to fix this, as it is, IMO, the only > legitimate drawback of this change. Could we make the following work? > > if((auto ary = func()).length) > > -Steve I would have though this would work: if(auto x = foo(), !x.empty)
Re: Voting: std.logger
On Tue, 29 Jul 2014 05:11:31 +, Dicebot wrote: > 1) Yes / No for inclusion into std.experimental Yes > 2) Yes / No for inclusion into Phobos in its current state No see notes in (3) > 3) If you have answered "No" for (2) : list of mandatory changes that > are needed to make you vote "Yes" We need to hammer out how this will work inside libraries. If my app is using multiple libraries I need to know I have full control of how they log and where (), and if I write libraries I need to include logging that will not affect performance or added dependencies. I like the idea of a standard interface for D logging. Other logging implementations should be able to plug into the interface without having to inherit from std.log.Logger (single inheritance issue). I would like to see conditional logging as part of the interface, or in the documentation show how we can achieve that with stdlib in a clean and simple way. Logger should include a shared Logger, or include it in the interface for outside libraries to handle the implementation. There will be libraries that thread internally and will need to support shared logging. > 4) Any additional comments for author. Awesome work so far. Getting this "right" is I huge pain, and I applaud you going through this.
Re: DIP62: Volatile type qualifier for unoptimizable variables in embedded programming
On Wed, 16 Jul 2014 11:49:21 -0700, Walter Bright wrote: > > I'll add that if it turns out we can't do a wrapper because of some > limitations/bugs in D's expressiveness, that is the problem with D we > need to fix, not adding another type modifier. > > It all comes down to leverage. Making user defined types more capable > has far, > far more productive leverage than welding specifics into the compiler. A Volatile(T) in stdlib seems to make a lot of sense, I am also wondering if the implementation of shared should be done the same way (if it does already then ignore), just use the compile to enforce shared and have it rewrite it as Shared(T).
Re: Out of sight out of mind
Does github link issues with pull requests (and the conversation) and commits? Does it link issues with sub issues/tasks? Can Issues link to other repos (link issues that are in both runtime and std lib)? If it does have these features (and they are easy to use) then I would back it. I have found jira to be one of the best trackers out there. -Byron
Re: Is D production-ready?
On Mon, 16 Jun 2014 11:14:05 +, seeker wrote: > NO IT'S NOT! > no working/incomplete windows headers for 32 and 64 bit. > no gui or db lib and tons of abandoned libs and proggies that you > mentioned. > > if your are on linux like most of the lieutenants and the vice-general > you may be fine. > > > > On Monday, 16 June 2014 at 10:28:50 UTC, John Petal wrote: >> On Monday, 16 June 2014 at 10:24:46 UTC, John Petal wrote: >>> Hi! >>> A while ago, after my journey with PHP and Python, I've decided to >>> learn C++. However, the more I learned, the more it got complicated. I >>> think what Scott Meyer said in his talk was the main reason: the >>> language was inconsistent; it didn't make sense as a whole. It always >>> needed an extra explanation. >>> >>> I saw D. "It is unstable!" they said, "There aren't enough tools!" >>> they said. I thought, "If I learn C++, he learns C++, then how the >>> hell alternatives are supposed to rise?" I felt responsible. I wanted >>> to contribute to D community. >>> >>> So I gave D a shot. People were kind of right – it was hard for a >>> beginner for me to get into. I mean, I spent a whole day trying to >>> make DSFML work. I wasn't trying to produce anything, so I was happy >>> that I spent my time learning those things. I'm getting better – I >>> still don't consider myself as a "programmer," but I'm getting better. >>> (Sorry about the storytelling, I just wanted to share.) >>> >>> Now I want to know if the language is production-ready. I can't really >>> see anything besides abandoned libraries written in D. Is it possible >>> – for example – to write a simple 2D game, or an automation program, >>> or a text editor in D? I know the language is perfectly capable, but >>> I'm not sure if the tools are mature enough. >>> >>> Does D have a mature and cross-platform GUI library? >>> Does D have a mature SFML or SDL binding? >>> Are there any advices you can give me? >>> >>> By the way, sorry for my English. >>> >>> Thank you! >>> John >> >> And I should add: >> Would you mind sharing something where you use D actively? >> >> Thank you! >> John I have web site thats planned to launch next month that runs on windows, db included!
Re: (git HEAD) std.datetime spewing deprecation messages
On Thu, 05 Jun 2014 21:00:39 +0200, Jonathan M Davis via Digitalmars-d
wrote:
> It's a common idiom in core.time and std.datetime to use strings to
> represent units when you need to give the units as template arguments.
> If it hade't been strings, it would have been an enum (otherwise, they
> would risk conflicting with local variables and whatnot), in which case
> it would have been even more verbose - e.g. Units.days, Unit.seconds,
> Unit.msecs (and IIRC, I originally had something like that until Anrei
> suggested that I use strings in the original review for std.datetime).
> Also, days, seconds, and msecs are free functions in core.time which
> forward to dur!"days", dur!"seconds", and dur!"msecs", so trying to use
> them on their own would try and use those free functions, which
> obviously isn't what we want at all. I can see why you might want to
> remove the quotes, but they really aren't that bad, and using strings
> for this purpose has turned out to be extremely useful and flexible.
>
> - Jonathn M Davis
Yeah its more of a pipe dream, kinda of how we have moved away from
passing strings and use the short hand versions of lambdas. A CTFE
helper might make it look better, saw this somewhere on the form.
d.splitHelper!q{days, second, msecs}(...)
the function name is not import here just the idea. There is a stdx
project on code.dlang, might be a good place for little helpers like this.
Re: (git HEAD) std.datetime spewing deprecation messages
On Thu, 05 Jun 2014 07:18:59 -0700, H. S. Teoh via Digitalmars-d wrote:
> On Thu, Jun 05, 2014 at 01:23:47AM -0700, Jonathan M Davis via
> Digitalmars-d wrote:
>>
>> {
>> auto d = dur!"days"(12) + dur!"minutes"(7) + dur!"usecs"(501223);
>> long days;
>> int seconds;
>> short msecs;
>> d.split!("days", "seconds", "msecs")(&days, &seconds, &msecs);
>> assert(days == 12);
>> assert(seconds == 7 * 60);
>> assert(msecs == 501);
> [...]
>
> Very nice! I like this. It looks very D-ish, and very idiomatic.
if only we could avoid the quotes, would a enum array work?
d.split
Re: [OT] Apple introduces Swift as Objective-C sucessor
On 2014-06-02 19:45:28 +, Paulo Pinto said: On Monday, 2 June 2014 at 19:19:27 UTC, Paulo Pinto wrote: Just thought it would be nice to give a heads up about Apple's plans to replace Objective-C in the long run. The language was presented today at the WWDC Keynote, looks like Ruby, uses ARC alongside the Objective-C runtime. http://live.arstechnica.com/apples-wwdc-2014-keynote/ It also has a nice REPL experience, similar to Python's worksheets in IPython. -- Paulo More information now made available https://developer.apple.com/swift/ "Use .. to make a range that omits its upper value, and use ... to make a range that includes both values." That is going to be a source of a lot of bugs, so easy to type 3 when you ment 2
Re: 1st Call for Ideas for Google Summer of Code 2015
Some things on my wish list, not in any order - D => JS converter/compiler. There has been talk about this in a thread currently. - DDL for D2 - vibe.d - update pages without having to recompile entire server and restarting the entire server - help get std.simd into review queue - dscanner work (more lint tests, optimization tests, memory checks, threading checks) and tutorials - finish shared - finish export - ARC - CTFE memory issues - Support paths in string imports on windows (this is a real pain in vibe for me) - Use DDMD as a library for IDE or other tools like dscanner - OGI for D - D message passing accross processes, openmp concept - threading performance - std.fiber ? (not sure where d fibers are at these days) Should be as easy as threading, - std.event libevent libev in D, cross platform safe, would be nice if this worked with fibers - get some code.dlang libs into std.experimental (sdland-d, dyaml, ctini, pegged)
Re: OT: but maybe still interesting - runtime c++ compilation
On 2014-05-28 10:22:07 +, dennis luehring said: could be a nice next step for D if "D compiler as a library" comes someday available http://runtimecompiledcplusplus.blogspot.co.uk/ from the blog: Runtime Compiled C++ is in Kythera, the AI behind Star Citizen. Video: RCC++ at the 2012 Develop Conference http://vimeo.com/85934969 and it seems that the Crytek and Unreal Guys are also playing in this field Would love to have this for vibe.d
