Re: how to migrate to std.datetime
On 2011-05-08 23:22, Russel Winder wrote: > On Mon, 2011-05-09 at 01:33 -0400, Nick Sabalausky wrote: > > "Jonathan M Davis" wrote in message > > [ . . . ] > > > This is great info, and very helpful. Perhaps it could be summarized into > > a general overview at the top of std.datetime's documentation page? > > My reaction was very much "This material is really great, but why isn't > it directly associated with the std.datetime package somewhere?" My > second reaction was "Jonathan should not have had to write such a long > email in reply, he should have been able to say 'Please go read ' > for an explanation." > > Jonathan, Please can you take time to put the material of these and a > couple of other long emails you have written in the past about > std.datetime into pages ion the Web somewhere. This one should clearly > be part of a page "Moving from std.date to std.datetime. > > Go could really do with a new date/time handling package, one that is as > good as D's! I could look at writing an article on moving from std.date to std.datetime, I suppose. We already have an article contest going, and it would make sense to put such an article on the site. I don't really have anywhere online that I can post anything myself though, let alone links to whatever newsgroup posts might be useful for understanding std.datetime. I would have hoped that the documentation in std.datetime would have been sufficient, but either it isn't and/or it's just too overwhelming for some folks, given some of the things that have been posted. There haven't been a lot of questions about it though since it got into Phobos, so either a fair number of people are understanding it well enough, or they aren't using it. Part of the problem with better explaining std.datetime though is that it's pretty much all in the documentation, so it's not generally clear what I should be explaining further without people asking specific questions. - Jonathan M Davis
Re: how to migrate to std.datetime
On Mon, 2011-05-09 at 01:33 -0400, Nick Sabalausky wrote: > "Jonathan M Davis" wrote in message [ . . . ] > > This is great info, and very helpful. Perhaps it could be summarized into a > general overview at the top of std.datetime's documentation page? My reaction was very much "This material is really great, but why isn't it directly associated with the std.datetime package somewhere?" My second reaction was "Jonathan should not have had to write such a long email in reply, he should have been able to say 'Please go read ' for an explanation." Jonathan, Please can you take time to put the material of these and a couple of other long emails you have written in the past about std.datetime into pages ion the Web somewhere. This one should clearly be part of a page "Moving from std.date to std.datetime. Go could really do with a new date/time handling package, one that is as good as D's! -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: how to migrate to std.datetime
On 2011-05-08 22:33, Nick Sabalausky wrote: > "Jonathan M Davis" wrote in message > news:mailman.74.1304905547.14074.digitalmars-d-le...@puremagic.com... > > > On 2011-05-08 17:46, Adam D. Ruppe wrote: > >> I decided to update my compiler today, and regret it for a lot of > >> reasons, but meh. > >> > >> One of the things is std.datetime. A lot of my code uses std.date. It > >> works very, very well for me and I like it. > >> > >> But, the compile process is nagging me about it. I want it to shut up. > > > > Well, std.date is going away. While it may work for what you've been > > doing, > > it's highly buggy. > > > >> However, I'm not even sure where to start with std.datetime... > > > > Well, it is true that it doesn't function anything like std.date. > > > >> Which one of it's functions does the same as std.date.getUTCtime()? > >> > >> It looks like sysTimeToDTime is almost sorta kinda related, but it's > >> got that same ugly deprecation text. > >> > >> sysTimeToDTime(Clock.currTime(UTC())); // best we can do? > >> > >> > >> Note that it's important to me that the numbers match up - I have > >> some stored and comparisons need to work the same way. > > > > std.date and the values that it uses (i.e. d_time) are going away > > entirely. > > sysTimeToDTime is there entirely to ease the transition. Anything that > > std.date it is going to have to be redesigned so that it doesn't, unless > > you > > want to copy the code to your own project and continue using that. > > > >> What about std.date.toUTCString()? There's a lot of toBlahString > >> in there, but none seem to match up. > >> > >> Another thing it's bitching at me about is std.file.lastModifed. I > >> just want to check the file's age. With the old function, this is > >> simple subtraction. How can I ask the new system "is this file > >> greater than 8 hours old?" > >> > >> > >> Last question: my app handles timezones on it's own by means of > >> addition and subtraction of offsets against the getUTCtime() result. > >> (it's a web app that fetches the offset from javascript so the server > >> knows what the user's local time is relative to it's internal > >> representation). > >> > >> std.date was pretty timezone agnostic. > >> > >> It looks like the DateTime doesn't mess around with them, so as > >> long as I always ask for things in UTC, shouldn't be a problem, right? > >> > >> > >> There's some more, but I think I can make the rest work with > >> DateTimes by multiplying the numbers before input. > > > > Okay. Basic overiew. > > > > Date: Represents a date of the year. It holds a year, month, and day > > internally. It has no relation to time zones. > > > > TimeOfDay: Represents a time of day. It holds an hour, minute, and second > > internally. It has no relation to time zones. > > > > DateTime: Represents a specific time of day on a specific day of the > > year. It > > holds a Date and TimeOfDay internally. It has no relation to time zones. > > > > SysTime: Represents a specific date and time like DateTime does, except > > it holds it internally in hecto-nanoseconds (100ns) from midnight > > January 1st, 1 > > A.D. (rather than holding the pieces of the date and time separately), > > and it > > _does_ care about time zone. It also has precision up to > > hecto-nanoseconds whereas DateTime only goes to the second. > > > > Date, TimeOfDay, and DateTime are meant to handle basic calendar-based > > operations where you don't care about the time zone. SysTime is intended > > for > > dealing with the system time, and it incorporates time zones. You can > > convert > > between SysTime and the other types (SysTime will cast to the other > > types, and > > it'll take the other types in its constructors), but you do risk problems > > with > > DST when converting from the other types to SysTime due to the fact that > > one > > hour of the year exists twice and another doesn't exist at all due to DST > > changes. But unfortunately, that's unavoidable. The only way to avoid the > > problem entirely is to keep times internally in UTC at all times (which > > SysTime does), though if the Date, TimeOfDay, or DateTime that you're > > constructing a SysTime from represents a time in UTC, and you give it UTC > > as > > its time zone, then you don't have that problem, since UTC doesn't have > > DST. > > > > What you want to use is almost certainly SysTime. Clock.currTime() > > returns a > > SysTime with the current time in the local time zone. > > Clock.currTime(UTC()) > > returns a SysTime with the current time in UTC. If you give it another > > TimeZone object, it gives the current time in whatever time zone that > > object > > represents. SysTime always holds the time internally in UTC and converts > > to > > its time zone when queried for values such as its year or day, or when > > you do > > something like convert it to a string. > > > > The way that I would write the time out would be to use SysTime and > > either have it in UTC a
Re: how to migrate to std.datetime
"Jonathan M Davis" wrote in message news:mailman.74.1304905547.14074.digitalmars-d-le...@puremagic.com... > On 2011-05-08 17:46, Adam D. Ruppe wrote: >> I decided to update my compiler today, and regret it for a lot of >> reasons, but meh. >> >> One of the things is std.datetime. A lot of my code uses std.date. It >> works very, very well for me and I like it. >> >> But, the compile process is nagging me about it. I want it to shut up. > > Well, std.date is going away. While it may work for what you've been > doing, > it's highly buggy. > >> However, I'm not even sure where to start with std.datetime... > > Well, it is true that it doesn't function anything like std.date. > >> Which one of it's functions does the same as std.date.getUTCtime()? >> >> It looks like sysTimeToDTime is almost sorta kinda related, but it's >> got that same ugly deprecation text. >> >> sysTimeToDTime(Clock.currTime(UTC())); // best we can do? >> >> >> Note that it's important to me that the numbers match up - I have >> some stored and comparisons need to work the same way. > > std.date and the values that it uses (i.e. d_time) are going away > entirely. > sysTimeToDTime is there entirely to ease the transition. Anything that > std.date it is going to have to be redesigned so that it doesn't, unless > you > want to copy the code to your own project and continue using that. > >> What about std.date.toUTCString()? There's a lot of toBlahString >> in there, but none seem to match up. >> >> Another thing it's bitching at me about is std.file.lastModifed. I >> just want to check the file's age. With the old function, this is >> simple subtraction. How can I ask the new system "is this file >> greater than 8 hours old?" >> >> >> Last question: my app handles timezones on it's own by means of >> addition and subtraction of offsets against the getUTCtime() result. >> (it's a web app that fetches the offset from javascript so the server >> knows what the user's local time is relative to it's internal >> representation). >> >> std.date was pretty timezone agnostic. >> >> It looks like the DateTime doesn't mess around with them, so as >> long as I always ask for things in UTC, shouldn't be a problem, right? >> >> >> There's some more, but I think I can make the rest work with >> DateTimes by multiplying the numbers before input. > > Okay. Basic overiew. > > Date: Represents a date of the year. It holds a year, month, and day > internally. It has no relation to time zones. > > TimeOfDay: Represents a time of day. It holds an hour, minute, and second > internally. It has no relation to time zones. > > DateTime: Represents a specific time of day on a specific day of the year. > It > holds a Date and TimeOfDay internally. It has no relation to time zones. > > SysTime: Represents a specific date and time like DateTime does, except it > holds it internally in hecto-nanoseconds (100ns) from midnight January > 1st, 1 > A.D. (rather than holding the pieces of the date and time separately), and > it > _does_ care about time zone. It also has precision up to hecto-nanoseconds > whereas DateTime only goes to the second. > > Date, TimeOfDay, and DateTime are meant to handle basic calendar-based > operations where you don't care about the time zone. SysTime is intended > for > dealing with the system time, and it incorporates time zones. You can > convert > between SysTime and the other types (SysTime will cast to the other types, > and > it'll take the other types in its constructors), but you do risk problems > with > DST when converting from the other types to SysTime due to the fact that > one > hour of the year exists twice and another doesn't exist at all due to DST > changes. But unfortunately, that's unavoidable. The only way to avoid the > problem entirely is to keep times internally in UTC at all times (which > SysTime does), though if the Date, TimeOfDay, or DateTime that you're > constructing a SysTime from represents a time in UTC, and you give it UTC > as > its time zone, then you don't have that problem, since UTC doesn't have > DST. > > What you want to use is almost certainly SysTime. Clock.currTime() returns > a > SysTime with the current time in the local time zone. > Clock.currTime(UTC()) > returns a SysTime with the current time in UTC. If you give it another > TimeZone object, it gives the current time in whatever time zone that > object > represents. SysTime always holds the time internally in UTC and converts > to > its time zone when queried for values such as its year or day, or when you > do > something like convert it to a string. > > The way that I would write the time out would be to use SysTime and either > have it in UTC already or call toUTC on it to get one in UTC, and then > call > its toISOExtString (it was toISOExtendedString until dmd 2.053) function > to > convert it to a string to write it out. When reading it in again, I'd then > use > SysTime's fromISOExtString. You could just write it and r
Re: how to migrate to std.datetime
On 2011-05-08 21:29, Adam D. Ruppe wrote: > Jonathan M Davis wrote: > > I would point out though that'll be a while before std.date and its > > related functions actually go away, so any code which needs to be > > converted to std.datetime definitely has time to be reworked > > however is appropriate. > > Yeah, but I figure it's better to do it sooner than later. The more > I wait, the more data I've got to deal with converting and the more > users I risk angering too. Oh, I totally agree that it's generally better to switch sooner rather than later, but you do have time to figure out what the best solution is in your situation rather then being in a situation where all of your code is about to break because std.date is eminently disappearing. Also, any insights into where std.datetime might have problems integrating with formats that you might have to keep your time in (other than d_time) would be useful. So, if you see areas where std.datetime is just plain lacking (as opposed to just being different), feel free to point them out. It's a very different type of solution than std.date was though, so it could take some getting used to. std.date was essentially the same solution as C except that it made d_time hold milliseconds whereas time_t holds seconds. std.datetime, on the other hand, is very much an object-oriented solution. - Jonathan M Davis
Re: how to migrate to std.datetime
Jonathan M Davis wrote: > I would point out though that'll be a while before std.date and its > related functions actually go away, so any code which needs to be > converted to std.datetime definitely has time to be reworked > however is appropriate. Yeah, but I figure it's better to do it sooner than later. The more I wait, the more data I've got to deal with converting and the more users I risk angering too.
Re: Why does toUTF16z only work with UTF8 encoding?
I guess this should do it:
const(wchar)* toUTF16z(in dchar[] s)
{
return (toUTF16(s) ~ "\000").ptr;
}
Why does toUTF16z only work with UTF8 encoding?
toUTF16 can take a char[], wchar[] or dchar[]. But toUTF16z can only take a char[]. Why? I'm storing some text as dchar[] internally and have to pass it to WinAPI Unicode functions which expect null-terminated UTF16 strings. But toUTF16z only works with char[] for some reason.
Re: how to migrate to std.datetime
I would point out though that'll be a while before std.date and its related functions actually go away, so any code which needs to be converted to std.datetime definitely has time to be reworked however is appropriate. Currently, they're scheduled for deprecation, which just results in the compiler complaining at you in the cases where it can tell that you've used a type or function which has been scheduled for deprecation. Later, they'll actually be deprecated, so then -d will then be required when compiling if you want to use them. _Then_ they will finally be removed. It has never been officially decided how long each of those phases is supposed to be, so it could be quite a while before std.date is actually gone. Walter definitely wants to avoid breaking people's code when API changes are made, so it's going to be a gradual process. My first guess would be that it'll be around 6 months of "scheduled for deprecation" followed by 6 months of deprecated before something actually is removed, but I really don't know. It could be longer. Which reminds me that I need to bring up that topic again on the Phobos list. We really should have a plan for how long each of the phases of deprecation take. - Jonathan M Davis
Re: how to migrate to std.datetime
On 2011-05-08 17:46, Adam D. Ruppe wrote: > I decided to update my compiler today, and regret it for a lot of > reasons, but meh. > > One of the things is std.datetime. A lot of my code uses std.date. It > works very, very well for me and I like it. > > But, the compile process is nagging me about it. I want it to shut up. Well, std.date is going away. While it may work for what you've been doing, it's highly buggy. > However, I'm not even sure where to start with std.datetime... Well, it is true that it doesn't function anything like std.date. > Which one of it's functions does the same as std.date.getUTCtime()? > > It looks like sysTimeToDTime is almost sorta kinda related, but it's > got that same ugly deprecation text. > > sysTimeToDTime(Clock.currTime(UTC())); // best we can do? > > > Note that it's important to me that the numbers match up - I have > some stored and comparisons need to work the same way. std.date and the values that it uses (i.e. d_time) are going away entirely. sysTimeToDTime is there entirely to ease the transition. Anything that std.date it is going to have to be redesigned so that it doesn't, unless you want to copy the code to your own project and continue using that. > What about std.date.toUTCString()? There's a lot of toBlahString > in there, but none seem to match up. > > Another thing it's bitching at me about is std.file.lastModifed. I > just want to check the file's age. With the old function, this is > simple subtraction. How can I ask the new system "is this file > greater than 8 hours old?" > > > Last question: my app handles timezones on it's own by means of > addition and subtraction of offsets against the getUTCtime() result. > (it's a web app that fetches the offset from javascript so the server > knows what the user's local time is relative to it's internal > representation). > > std.date was pretty timezone agnostic. > > It looks like the DateTime doesn't mess around with them, so as > long as I always ask for things in UTC, shouldn't be a problem, right? > > > There's some more, but I think I can make the rest work with > DateTimes by multiplying the numbers before input. Okay. Basic overiew. Date: Represents a date of the year. It holds a year, month, and day internally. It has no relation to time zones. TimeOfDay: Represents a time of day. It holds an hour, minute, and second internally. It has no relation to time zones. DateTime: Represents a specific time of day on a specific day of the year. It holds a Date and TimeOfDay internally. It has no relation to time zones. SysTime: Represents a specific date and time like DateTime does, except it holds it internally in hecto-nanoseconds (100ns) from midnight January 1st, 1 A.D. (rather than holding the pieces of the date and time separately), and it _does_ care about time zone. It also has precision up to hecto-nanoseconds whereas DateTime only goes to the second. Date, TimeOfDay, and DateTime are meant to handle basic calendar-based operations where you don't care about the time zone. SysTime is intended for dealing with the system time, and it incorporates time zones. You can convert between SysTime and the other types (SysTime will cast to the other types, and it'll take the other types in its constructors), but you do risk problems with DST when converting from the other types to SysTime due to the fact that one hour of the year exists twice and another doesn't exist at all due to DST changes. But unfortunately, that's unavoidable. The only way to avoid the problem entirely is to keep times internally in UTC at all times (which SysTime does), though if the Date, TimeOfDay, or DateTime that you're constructing a SysTime from represents a time in UTC, and you give it UTC as its time zone, then you don't have that problem, since UTC doesn't have DST. What you want to use is almost certainly SysTime. Clock.currTime() returns a SysTime with the current time in the local time zone. Clock.currTime(UTC()) returns a SysTime with the current time in UTC. If you give it another TimeZone object, it gives the current time in whatever time zone that object represents. SysTime always holds the time internally in UTC and converts to its time zone when queried for values such as its year or day, or when you do something like convert it to a string. The way that I would write the time out would be to use SysTime and either have it in UTC already or call toUTC on it to get one in UTC, and then call its toISOExtString (it was toISOExtendedString until dmd 2.053) function to convert it to a string to write it out. When reading it in again, I'd then use SysTime's fromISOExtString. You could just write it and read it with its time zone being in the local time, but then that loses the time zone. If you have a time in UTC with its time zone as numbers representing its offset from UTC and DST, you could use SimpleTimeZone. It just has the offset from UTC though, since it h
Is there a better way to write this split functionality?
import std.stdio;
import std.array;
import std.range;
import std.algorithm;
void main()
{
auto arr = [64, 64, 64, 32, 31, 16, 32, 33, 64];
auto newarr = arr[];
bool state = true;
while (arr.length)
{
newarr = state ? array(until!("a < 32")(arr))
: array(until!("a >= 32")(arr));
arr = arr[newarr.length .. $];
state ^= 1;
writeln(newarr);
}
}
The idea is to find as many elements in a sequence that conform to some
predicate, followed by as many elements that conform to another predicate. The
two predicates are switched on each run.
The above code will print:
[64, 64, 64, 32]
[31, 16]
[32, 33, 64]
Is there a better way to do this, some std.range/algorithm function I don't
know of?
how to migrate to std.datetime
I decided to update my compiler today, and regret it for a lot of reasons, but meh. One of the things is std.datetime. A lot of my code uses std.date. It works very, very well for me and I like it. But, the compile process is nagging me about it. I want it to shut up. However, I'm not even sure where to start with std.datetime... Which one of it's functions does the same as std.date.getUTCtime()? It looks like sysTimeToDTime is almost sorta kinda related, but it's got that same ugly deprecation text. sysTimeToDTime(Clock.currTime(UTC())); // best we can do? Note that it's important to me that the numbers match up - I have some stored and comparisons need to work the same way. What about std.date.toUTCString()? There's a lot of toBlahString in there, but none seem to match up. Another thing it's bitching at me about is std.file.lastModifed. I just want to check the file's age. With the old function, this is simple subtraction. How can I ask the new system "is this file greater than 8 hours old?" Last question: my app handles timezones on it's own by means of addition and subtraction of offsets against the getUTCtime() result. (it's a web app that fetches the offset from javascript so the server knows what the user's local time is relative to it's internal representation). std.date was pretty timezone agnostic. It looks like the DateTime doesn't mess around with them, so as long as I always ask for things in UTC, shouldn't be a problem, right? There's some more, but I think I can make the rest work with DateTimes by multiplying the numbers before input.
Re: Cannot interpret struct at compile time
On 08/05/2011 19:19, Lutger Blijdestijn wrote:
test also doesn't compile normally on my box, dmd errors on Foo.tupleof. Not
sure if this is illegal or not. I think you want the allMembers trait or
something similar. Something like this:
import std.traits;
string test(T)()
{
string str = "struct " ~ T.stringof ~ "_{";
alias FieldTypeTuple!T FieldTypes;
foreach (i, fieldName; __traits(allMembers, T ) )
{
str ~= FieldTypes[i].stringof ~ " " ~ fieldName ~ ";";
}
return str ~ "}";
}
This works for your example but is a bit crude, I'm sorry for that, you'll
have to modify it. ( allMembers also returns functions, including ctors
while FieldTypeTuple doesn't. I also haven't read anything about the order
in which FieldTypeTuple and allMembers return their elements )
This seems to do what I need, thanks! :D
--
Robert
http://octarineparrot.com/
Re: Linux: How to statically link against system libs?
On 08/05/2011 20:42, Nick Sabalausky wrote: "Spacen Jasset" wrote in message news:iq69q1$1ack$1...@digitalmars.com... It should work,but again is depends what your target platform is. It's quite important that - Even on windows. At the company I am now contracting for we compile the software agents using visual studio 2003 because later versions do not let the agent work with windows 98. This is not just a Linux phenomenon. But at least you can still compile *on* XP+ and get the result to work on 98. And fairly easily (ie: Just use VS 2003). That sort of thing *might* be true on Linux as well, but it seems to be either difficult or really obscure. For instance, no one here seems to know: http://ubuntuforums.org/showthread.php?t=1740277 Plus, there's the fact that Linux has not just different versions, but many different distros, too. And the distros apperently tend to be somewhat divergent in different things. (But again, it's not like I'm saying "Windows kicks Linux's ass" or anything like that.) In any case centos 4.7 is a point release of 4.0 and as such there should be no breaking libc changes. Ah! Thanks, that's good to know. In fact, I was specifically wondering about that, but I wasn't certain and didn't want to assume. Yes, what you say it true. The most important thing usually is the glibc version. In terms of distributions, yes they all have different libraries installed, which can be a pain. For expat, we do infact statically link that, and boost, and zlib. - but you can ship dlls instead in that case, again of course, using some voodoo magic, RPATH linker setting. It was the case back in the day, that to install something on unix systems, you would compile it, and in fact, sys admins would not install binaries... If you get stuck again, or need assistance, then you can look me up on linkedin, facebook and send me a message. "Jason Spashett"
Re: private module stuff
> On 5/8/2011 4:05 AM, Jonathan M Davis wrote:
> >> Sean Cavanaugh:
> >>> So I was learning how to make a module of mine very strict with
> >>> private
> >>>
> >>> parts, and was surprised I could only do this with global variables and
> >>> functions. Enums, structs, and classes are fully visible outside the
> >>> module regardless of being wrapped in a private{} or prefixed with
> >>> private. Am I expecting too much here?
> >>
> >> You are expecting the right thing. If you are right, then it's a bug
> >> that eventually needs to be fixed. Take a look in Bugzilla, there are
> >> several already reported import/module-related bugs.
> >
> > They're private _access_ but still visible. I believe that that is the
> > correct behavior and not a bug at all. I believe that it's necessary for
> > stuff like where various functions in std.algorithm return auto and
> > return a private struct which you cannot construct yourself. Code which
> > uses that struct needs to know about it so that it can use it properly,
> > but since it's private, it can't declare it directly. It works because
> > the types are appropriately generic (ranges in this case). Regardless, I
> > believe that the current behavior with private is intended.
> >
> > - Jonathan M Davis
>
> The more I play with private/protected/package the more confused I am by
> it.
>
> For the most part the rules are:
> Functions and variables have protection
> Types (enum, struct, class) do not
> this and ~this are special and are not considered functions, and are
> always public
> struct and class members always default to public
>
>
>
> If you search phobos you will find occurences of 'private struct' and
> 'private class', so even the people writing libraries are expecting
> something to be happening that isn't. For example:
>
>
> //in std.parallelism:
> private struct AbstractTask {
> mixin BaseMixin!(TaskStatus.notStarted);
>
> void job() {
> runTask(&this);
> }
> }
>
>
> //and in std.demangle:
> private class MangleException : Exception
> {
> this()
> {
> super("MangleException");
> }
> }
>
>
> and in my code I can compile the following without compile-time errors:
>
>
> import std.parallelism;
> import std.demangle;
>
> int main()
> {
> MangleException bar = new MangleException();
>
> AbstractTask foo;
> foo.job();
>
> return 0;
> }
>
>
>
>
> With the language the way it is now, it is nonsensical to have the
> attributes public/protected/package/private/export precede the keyword
> struct, class, or enum.
private, public, protected, and private are _always_ about access and _never_
about visibility. They affect whether you can _use_ a particular symbol in a
particular piece of code, _not_ whether the compiler can see it in that
context. It doesn't matter whether it's a function, variable, class, etc. Now,
there may be bugs in the current implementation, but the design is fairly
straightforward.
For instance, anything templated is currently always public regardless of what
you mark it as ( http://d.puremagic.com/issues/show_bug.cgi?id=1904 ,
http://d.puremagic.com/issues/show_bug.cgi?id=2775 ). Also, it looks like
there is a bug report for structs and classes not dealing with private
properly ( http://d.puremagic.com/issues/show_bug.cgi?id=2830 ) when the
entire class or struct is marked as private. So unfortunately, the
implementation _is_ currently buggy, but the design is fairly straightforward.
Oh, and this and ~this _are_ functions (albeit special) and can be made
private - or even outright removed entirely with @disable. Traits works with
__ctor and __dtor rather than this and ~this, and you can call the constructor
with __ctor (though it's unlikely that there's a case where you should) and
the destructor with __dtor (though there probably isn't really a valid case to
do that - use clear instead, and it'll call the destructor along with
everything else it does).
The thing with the default constructor is that it exists if you don't declare
any constructors, and it'll default to public, so you generally have to
declare it and make it private if you want it to have a default constructor
and not have it public. That _does_ seem like a likely place for a bug in the
case where the class is private, but since that's completely broken right now
anyway, that's not really a concern. The destructor is in the same boat,
though why you'd want to make the destructor private, I don't know. And
structs don't have the issue with default constructors because they can't have
them.
So, yes, the current implementation is broken (and more broken than I thought
that it was actually), but the basic design is quite straightforward. I would
think that assuming that dmd were not buggy with regards to private that the
access specifiers would generally work as you expect them to - though there
may be some cases where t
Re: Linux: How to statically link against system libs?
"Spacen Jasset" wrote in message news:iq69q1$1ack$1...@digitalmars.com... > > It should work,but again is depends what your target platform is. It's > quite important that - Even on windows. At the company I am now > contracting for we compile the software agents using visual studio 2003 > because later versions do not let the agent work with windows 98. This is > not just a Linux phenomenon. > But at least you can still compile *on* XP+ and get the result to work on 98. And fairly easily (ie: Just use VS 2003). That sort of thing *might* be true on Linux as well, but it seems to be either difficult or really obscure. For instance, no one here seems to know: http://ubuntuforums.org/showthread.php?t=1740277 Plus, there's the fact that Linux has not just different versions, but many different distros, too. And the distros apperently tend to be somewhat divergent in different things. (But again, it's not like I'm saying "Windows kicks Linux's ass" or anything like that.) > In any case centos 4.7 is a point release of 4.0 and as such there should > be no breaking libc changes. > Ah! Thanks, that's good to know. In fact, I was specifically wondering about that, but I wasn't certain and didn't want to assume.
Re: Linux: How to statically link against system libs?
"Jacob Carlborg" wrote in message news:iq6llk$20ch$1...@digitalmars.com... > On 2011-05-08 19:50, Jacob Carlborg wrote: >> On 2011-04-29 22:02, Nick Sabalausky wrote: >>> I'm having a rediculously hard time trying to find a CentOS 3 >>> installation >>> disc image (or any other version before 5.6). This is the closest I've >>> been >>> able to find: >> >> Have a look at this: http://vault.centos.org/ > > I see now that you've already found this link, never mind. > Missed it by *that* much. ;)
Re: Linux: How to statically link against system libs?
"Adam D. Ruppe" wrote in message
news:iq6osh$25di$1...@digitalmars.com...
> Nick Sabalausky wrote:
>> Actually, I did have to remove the HTTP status code output from my
>> little hello world cgi test in forder for Apache to not throw up a
>> 500.
>
> HTTP status is normally done with a Status: header in cgi. (Actually
> writing the line works too but only with certain settings.)
>
> writefln("Status: 200 OK"); // note: optional; 200 OK is assumed
> writefln("Content-Type: text/plain");
> writefln(); // blank line ends headers
> writefln("Hello, world!");
>
Ahh, sweet. Didn't know about that "Status:" thing. Or maybe I did and
forgot... ;)
BTW, another thing I just learned (posting here in case anyone reads this
and has similar problems) is that on some servers, like mine, the
permissions on the executable have to be set to *not* be writable by group
or world, or Apache will just throw a 500. Apperently there's a whole list
of conditions that have to be met here:
http://httpd.apache.org/docs/current/suexec.html
When I first compiled the app on my local CentOS VM, gcc set the binary's
permissions to 775, which were preserved by ftp, and then I could run it on
the server through ssh, but not through Apache/HTTP. Changing them to 755
fixed it.
> I just saw this thread, but when I do my cgi apps, I actually
> recompile them right on the live server. If that's an option
> for you, it's a bit of a pain to set up, but it's less painful
> than dealing with Linux's generally retarded library/bits situation.
Yea, that would definitely a better way to go. Unfortunately I normally have
to deal with shared hosts, so the stuff I can actually do on the server is
usually very limited. On this particular server, I know I can't run gcc. (At
least not the system's gcc anyway. Maybe there's some way to have a portable
install of gcc? But knowing gcc, if there is a way, I'm sure it would be a
royal pain.) DMD *is* a portable install, which is nice, but on linux it
still needs gcc to link. And then on the other server I need to use, I don't
think ssh is even available.
Re: Linux: How to statically link against system libs?
Nick Sabalausky wrote:
> Actually, I did have to remove the HTTP status code output from my
> little hello world cgi test in forder for Apache to not throw up a
> 500.
HTTP status is normally done with a Status: header in cgi. (Actually
writing the line works too but only with certain settings.)
writefln("Status: 200 OK"); // note: optional; 200 OK is assumed
writefln("Content-Type: text/plain");
writefln(); // blank line ends headers
writefln("Hello, world!");
---
I just saw this thread, but when I do my cgi apps, I actually
recompile them right on the live server. If that's an option
for you, it's a bit of a pain to set up, but it's less painful
than dealing with Linux's generally retarded library/bits situation.
Re: Cannot interpret struct at compile time
Robert Clipsham wrote:
> Hey all,
>
> I was wondering if anyone could enlighten me as to why the following
> code does not compile (dmd2, latest release or the beta):
>
> struct Foo
> {
> int a;
> }
>
> string test()
> {
> string str = "struct " ~ Foo.stringof ~ "_{";
> foreach (j, f; Foo.tupleof)
> {
> enum fullFieldName = Foo.tupleof[j].stringof;
> str ~= typeof(f).stringof ~ ' ' ~
> fullFieldName[Foo.stringof.length + 3 .. $];
> }
> return str ~ "}";
> }
>
> void main()
> {
> mixin(test());
> }
>
> If fails with the errors:
> test.d(9): Error: Cannot interpret Foo at compile time
> test.d(19): Error: cannot evaluate test() at compile time
> test.d(19): Error: argument to mixin must be a string, not (test())
> test.d(19): Error: cannot evaluate test() at compile time
> test.d(19): Error: argument to mixin must be a string, not (test())
>
> Thanks,
>
test also doesn't compile normally on my box, dmd errors on Foo.tupleof. Not
sure if this is illegal or not. I think you want the allMembers trait or
something similar. Something like this:
import std.traits;
string test(T)()
{
string str = "struct " ~ T.stringof ~ "_{";
alias FieldTypeTuple!T FieldTypes;
foreach (i, fieldName; __traits(allMembers, T ) )
{
str ~= FieldTypes[i].stringof ~ " " ~ fieldName ~ ";";
}
return str ~ "}";
}
This works for your example but is a bit crude, I'm sorry for that, you'll
have to modify it. ( allMembers also returns functions, including ctors
while FieldTypeTuple doesn't. I also haven't read anything about the order
in which FieldTypeTuple and allMembers return their elements )
Re: Getting equivalent elements in a range/array
Thanks, group seems to work fine too.
Re: Linux: How to statically link against system libs?
On 2011-05-08 19:50, Jacob Carlborg wrote: On 2011-04-29 22:02, Nick Sabalausky wrote: I'm having a rediculously hard time trying to find a CentOS 3 installation disc image (or any other version before 5.6). This is the closest I've been able to find: Have a look at this: http://vault.centos.org/ I see now that you've already found this link, never mind. -- /Jacob Carlborg
Re: Linux: How to statically link against system libs?
On 2011-04-29 22:02, Nick Sabalausky wrote: I'm having a rediculously hard time trying to find a CentOS 3 installation disc image (or any other version before 5.6). This is the closest I've been able to find: Have a look at this: http://vault.centos.org/ -- /Jacob Carlborg
Re: Problem Passing Struct to C
On 2011-05-06 21:05, Robert Clipsham wrote: On 06/05/2011 19:40, Jacob Carlborg wrote: No, D implicitly casts string literals to zero-terminated const(char)*. That part is fine. -Steve Since when? Since const was introduced, before then they implicitly casted to char* instead. And that has been the case since early D1. I think I've heard of it but I thought that was before D1 and had been remove. -- /Jacob Carlborg
Re: int or size_t ?
On 07/05/2011 18:09, %u wrote: In Patterns of Human Error, the slide 31 point that you should replce int with size_t why that consider an error ? For those who aren't sure what this is on about: http://www.slideshare.net/dcacm/patterns-of-human-error But the short answer is because dim is a size_t, i needs to cover its range. But <= should be = ? Don't you mean < ? And the use of a meaningless type alias gets at me. Stewart.
Re: Shouldn't duplicate functions be caught by DMD?
On 08/05/2011 09:41, bearophile wrote: Andrej Mitrovic: I think the compiler should check catch these mistakes at compile-time. I suggest to add an enhancement request in Bugzilla. Bugzilla entries are a form of "voting" by themselves too. One should not file stuff in Bugzilla without first looking to see whether it's already there. And this one is: http://d.puremagic.com/issues/show_bug.cgi?id=1003 Stewart.
Re: private module stuff
Sean Cavanaugh: > With the language the way it is now, it is nonsensical to have the > attributes public/protected/package/private/export precede the keyword > struct, class, or enum. It's an implementation bug or a design bug. If it's not already in Bugzilla then it deserves to be there. Bye, bearophile
Re: Linux: How to statically link against system libs?
On 08/05/2011 12:59, Nick Sabalausky wrote: "Nick Sabalausky" wrote in message news:iq2g72$ngp$1...@digitalmars.com... Aggg!!! God damnnit, I officially fucking hate linux now... (not that I'm a win, mac or bsd fan, but whatever...) I temporarily gave up trying to actually get ahold of an old distro, so I tried the other angles (not counting just simply *wishing* it was like win and I could just copy the damn binary over to another linux box...nooo, that would be too simple for a unix-style system): I got my web host to switch me to a server that has 32-bit libs installed (a pain in and of itself because I had to coordinate with a client to find a convenient downtime, and then I ended up needing to change my domain's DNS entires, so now my whole domain's down for a couple days)...And it make no difference. So I guess in my particular case it wasn't a 32-bit/64-bit issue at all (or maybe there still would have been that problem too, I dunno). So I went to try uClibc: I started my Linux box...and it decides to hang mid-startup. So I reboot and at least this time the dumb thing finishes booting (I had problems with linux randomly breaking for no apperent reason ten years ago with Mandrake and Red Hat. I can't believe it's still happening now). Anyway, at the uClibc site, I saw the "simple steps" here: http://uclibc.org/toolchains.html and thought "Uhh, hell no, not if I don't have to" and went to the link for the pre-built verison instead. The link was broken. Then the page says those are really old versions anyway. Great :/ So I go through the steps: I get to the part where I download buildroot. Copy/paste the link over to my linux box...and discover that Synergy+ has suddenly decided it no longer feels like offering the "shared clipboard" feature that always worked before. Ok, so I type the URL into my linux box manually, download buildroot, unpack it...so far so good...and follow the instruction to run "make menuconfig"...BARF. It fails with some error about ncurses being missing, and that I should get ncurses-devel. "sudo apt-get install ncurses-devel": Can't find package. "sudo apt-get install ncurses": Can't find package. "sudo apt-get install fuck-shit-cock": Can't find package. Google "ncurses deb package". Actually found it. Download. Run...You ready for this? Here's the message: "Error: A later version is already installed." SERIOUSLY?! This is the point where I would normally say "fuck this shit", but the thought of continuing to use PHP (even if it is via Haxe) is enough to keep me bashing my head against this wall. Next stop: See if I can get ahold of *some* version of CentOS and see if using that in a VM will manage to work. (And rip Kubuntu off my Linux box and see if I can replace it with Debian+XFCE. How is it possible that GNOME and KDE were both fairly ok ten years ago, at least as far as I can remember, but the latest versions of both are complete shit? And then there's that iOS garbage that Ubuntu is moving to now (The one main thing I've always disliked about Ubuntu is their incompresensible Apple-envy, which only seems to be increasing). And fuck, the latest KDE actually makes the Win7 UI seem good (at least the Win7 UI actually *works* and has some semblance of consistency, even as obnoxious as it is), and I could have sworn that KDE never used to be so completely broken before. Or broken at all, for that matter. Which is too bad, because Dolphin actually shows some promise...at least when it isn't doing the random-horizontal-scrolling-for-no-apparent-reason dance.) Yay! I've just had some success! I managed to find this: http://vault.centos.org/ Which has all the CentOS ISOs. (You'd think I would have had an easier time finding that URL...) I downloaded 4.2 (picked pretty much at random), installed it in VirtualBox, compiled a trivial test C program in the included GCC, uploaded that to the server, and it worked! :) Next step: Install DMD on this CentOS VM and try for a D cgi... And then later, I may try 4.7, see if that'll work for me too. And I still have another web host I need to get CGI working on (although that one has some pretty bad support, so I'm a little nervous about that). But it's looking good so far. Finegrs crossed... I'd be nice to not have to use a VM to compile, of course. But as long as I can I have some way to do my server-side web stuff in D, and *completely* sidestep the entire PHP runtime, then it'll certainly still be well worth it. It should work,but again is depends what your target platform is. It's quite important that - Even on windows. At the company I am now contracting for we compile the software agents using visual studio 2003 because later versions do not let the agent work with windows 98. This is not just a Linux phenomenon. Centos 4 is fairly new, and it's possible that your hosting providers use older, even unsupported versions of distributions. Centos 3 might have been a wiser bet. In any case centos 4.7 is a
Re: private module stuff
On 5/8/2011 4:05 AM, Jonathan M Davis wrote:
Sean Cavanaugh:
So I was learning how to make a module of mine very strict with private
parts, and was surprised I could only do this with global variables and
functions. Enums, structs, and classes are fully visible outside the
module regardless of being wrapped in a private{} or prefixed with
private. Am I expecting too much here?
You are expecting the right thing. If you are right, then it's a bug that
eventually needs to be fixed. Take a look in Bugzilla, there are several
already reported import/module-related bugs.
They're private _access_ but still visible. I believe that that is the correct
behavior and not a bug at all. I believe that it's necessary for stuff like
where various functions in std.algorithm return auto and return a private
struct which you cannot construct yourself. Code which uses that struct needs
to know about it so that it can use it properly, but since it's private, it
can't declare it directly. It works because the types are appropriately
generic (ranges in this case). Regardless, I believe that the current behavior
with private is intended.
- Jonathan M Davis
The more I play with private/protected/package the more confused I am by it.
For the most part the rules are:
Functions and variables have protection
Types (enum, struct, class) do not
this and ~this are special and are not considered functions, and are
always public
struct and class members always default to public
If you search phobos you will find occurences of 'private struct' and
'private class', so even the people writing libraries are expecting
something to be happening that isn't. For example:
//in std.parallelism:
private struct AbstractTask {
mixin BaseMixin!(TaskStatus.notStarted);
void job() {
runTask(&this);
}
}
//and in std.demangle:
private class MangleException : Exception
{
this()
{
super("MangleException");
}
}
and in my code I can compile the following without compile-time errors:
import std.parallelism;
import std.demangle;
int main()
{
MangleException bar = new MangleException();
AbstractTask foo;
foo.job();
return 0;
}
With the language the way it is now, it is nonsensical to have the
attributes public/protected/package/private/export precede the keyword
struct, class, or enum.
Re: Linux: How to statically link against system libs?
"Nick Sabalausky" wrote in message news:iq60qt$pm0$1...@digitalmars.com... > > I downloaded 4.2 (picked pretty much at random), installed it in > VirtualBox, compiled a trivial test C program in the included GCC, > uploaded that to the server, and it worked! :) > Actually, I did have to remove the HTTP status code output from my little hello world cgi test in forder for Apache to not throw up a 500. That kind of surprised me, actually. But maybe it just means it's been far too long since I've done CGI... *shrug*
Re: Linux: How to statically link against system libs?
"Nick Sabalausky" wrote in message news:iq2g72$ngp$1...@digitalmars.com... > > Aggg!!! God damnnit, I officially fucking hate linux now... (not that > I'm a win, mac or bsd fan, but whatever...) > > I temporarily gave up trying to actually get ahold of an old distro, so I > tried the other angles (not counting just simply *wishing* it was like win > and I could just copy the damn binary over to another linux box...nooo, > that would be too simple for a unix-style system): > > I got my web host to switch me to a server that has 32-bit libs installed > (a pain in and of itself because I had to coordinate with a client to find > a convenient downtime, and then I ended up needing to change my domain's > DNS entires, so now my whole domain's down for a couple days)...And it > make no difference. So I guess in my particular case it wasn't a > 32-bit/64-bit issue at all (or maybe there still would have been that > problem too, I dunno). > > So I went to try uClibc: > > I started my Linux box...and it decides to hang mid-startup. So I reboot > and at least this time the dumb thing finishes booting (I had problems > with linux randomly breaking for no apperent reason ten years ago with > Mandrake and Red Hat. I can't believe it's still happening now). > > Anyway, at the uClibc site, I saw the "simple steps" here: > http://uclibc.org/toolchains.html and thought "Uhh, hell no, not if I > don't have to" and went to the link for the pre-built verison instead. The > link was broken. Then the page says those are really old versions anyway. > Great :/ > > So I go through the steps: I get to the part where I download buildroot. > Copy/paste the link over to my linux box...and discover that Synergy+ has > suddenly decided it no longer feels like offering the "shared clipboard" > feature that always worked before. > > Ok, so I type the URL into my linux box manually, download buildroot, > unpack it...so far so good...and follow the instruction to run "make > menuconfig"...BARF. It fails with some error about ncurses being missing, > and that I should get ncurses-devel. "sudo apt-get install ncurses-devel": > Can't find package. "sudo apt-get install ncurses": Can't find package. > "sudo apt-get install fuck-shit-cock": Can't find package. > > Google "ncurses deb package". Actually found it. Download. Run...You ready > for this? Here's the message: "Error: A later version is already > installed." SERIOUSLY?! > > This is the point where I would normally say "fuck this shit", but the > thought of continuing to use PHP (even if it is via Haxe) is enough to > keep me bashing my head against this wall. Next stop: See if I can get > ahold of *some* version of CentOS and see if using that in a VM will > manage to work. (And rip Kubuntu off my Linux box and see if I can replace > it with Debian+XFCE. How is it possible that GNOME and KDE were both > fairly ok ten years ago, at least as far as I can remember, but the latest > versions of both are complete shit? And then there's that iOS garbage that > Ubuntu is moving to now (The one main thing I've always disliked about > Ubuntu is their incompresensible Apple-envy, which only seems to be > increasing). And fuck, the latest KDE actually makes the Win7 UI seem good > (at least the Win7 UI actually *works* and has some semblance of > consistency, even as obnoxious as it is), and I could have sworn that KDE > never used to be so completely broken before. Or broken at all, for that > matter. Which is too bad, because Dolphin actually shows some promise...at > least when it isn't doing the > random-horizontal-scrolling-for-no-apparent-reason dance.) > Yay! I've just had some success! I managed to find this: http://vault.centos.org/ Which has all the CentOS ISOs. (You'd think I would have had an easier time finding that URL...) I downloaded 4.2 (picked pretty much at random), installed it in VirtualBox, compiled a trivial test C program in the included GCC, uploaded that to the server, and it worked! :) Next step: Install DMD on this CentOS VM and try for a D cgi... And then later, I may try 4.7, see if that'll work for me too. And I still have another web host I need to get CGI working on (although that one has some pretty bad support, so I'm a little nervous about that). But it's looking good so far. Finegrs crossed... I'd be nice to not have to use a VM to compile, of course. But as long as I can I have some way to do my server-side web stuff in D, and *completely* sidestep the entire PHP runtime, then it'll certainly still be well worth it.
Re: private module stuff
> Jonathan M Davis:
> > They're private _access_ but still visible.
>
> In my opinion this is not good, it looks like a messy special case.
>
> > I believe that it's necessary for stuff like
> > where various functions in std.algorithm return auto and return a private
> > struct which you cannot construct yourself.
I believe that C++, C#, and Java all treat private as a matter of access, not
visibility, though in most cases, there's no real difference in usage. So,
there's nothing abnormal - quite the opposite really - with D doing what it's
doing.
> Do you mean something like this? This returns a struct defined inside, but
> it's not a private definition.
>
> auto foo() {
> struct Bar {}
> return Bar();
> }
True. That wasn't the best example, since that's not techinically private, but
you can run into the same situation with classes or structs which _are_
private.
- Jonathan M Davis
Re: private module stuff
Jonathan M Davis:
> They're private _access_ but still visible.
In my opinion this is not good, it looks like a messy special case.
> I believe that it's necessary for stuff like
> where various functions in std.algorithm return auto and return a private
> struct which you cannot construct yourself.
Do you mean something like this? This returns a struct defined inside, but it's
not a private definition.
auto foo() {
struct Bar {}
return Bar();
}
Bye,
bearophile
Re: private module stuff
> Sean Cavanaugh:
> > So I was learning how to make a module of mine very strict with private
> >
> > parts, and was surprised I could only do this with global variables and
> > functions. Enums, structs, and classes are fully visible outside the
> > module regardless of being wrapped in a private{} or prefixed with
> > private. Am I expecting too much here?
>
> You are expecting the right thing. If you are right, then it's a bug that
> eventually needs to be fixed. Take a look in Bugzilla, there are several
> already reported import/module-related bugs.
They're private _access_ but still visible. I believe that that is the correct
behavior and not a bug at all. I believe that it's necessary for stuff like
where various functions in std.algorithm return auto and return a private
struct which you cannot construct yourself. Code which uses that struct needs
to know about it so that it can use it properly, but since it's private, it
can't declare it directly. It works because the types are appropriately
generic (ranges in this case). Regardless, I believe that the current behavior
with private is intended.
- Jonathan M Davis
Re: Getting equivalent elements in a range/array
Andrej M.: > I want to turn this: > auto arr = [1, 1, 2, 3, 4, 4]; > > into this: > auto arr2 = [[1, 1], [2], [3], [4, 4]]; > > I want an array of arrays of the same elements. Lazy or not, I don't care. Currently if you use group like this: writeln(arr.group()); You get: [Tuple!(int,uint)(1, 2), Tuple!(int,uint)(2, 1), Tuple!(int,uint)(3, 1), Tuple!(int,uint)(4, 2)] Andrei has recently said he wants to modify group() to make it work more like python itertools.groupby(), so it will do what you want (the duplicated items too will be lazy, as in Python). Bye, bearophile
Re: private module stuff
Sean Cavanaugh:
> So I was learning how to make a module of mine very strict with private
> parts, and was surprised I could only do this with global variables and
> functions. Enums, structs, and classes are fully visible outside the
> module regardless of being wrapped in a private{} or prefixed with
> private. Am I expecting too much here?
You are expecting the right thing. If you are right, then it's a bug that
eventually needs to be fixed. Take a look in Bugzilla, there are several
already reported import/module-related bugs.
Bye,
bearophile
Re: Shouldn't duplicate functions be caught by DMD?
Andrej Mitrovic: > I think the compiler should check catch these mistakes at compile-time. I suggest to add an enhancement request in Bugzilla. Bugzilla entries are a form of "voting" by themselves too. Bye, bearophile
private module stuff
So I was learning how to make a module of mine very strict with private
parts, and was surprised I could only do this with global variables and
functions. Enums, structs, and classes are fully visible outside the
module regardless of being wrapped in a private{} or prefixed with
private. Am I expecting too much here?
rough code:
module mymoduletree.mymodule;
private
{
struct foo
{
int x;
int y;
}
int somevar = 4;
}
.
module someothertree.othermodule;
import mymoduletree.mymodule;
int bar(int arg)
{
foo var; // why can i use this type here??
var.x = arg;
var.y = somevar; // this generates an error (access of somevar is
private and not allowed)
return var.y;
}
