Deimos submission - Nanopb
I've got some bindings for Nanopb I'll like to contribute to Deimos: Original C project: http://koti.kapsi.fi/jpa/nanopb/ My D Bindings: https://github.com/Abscissa/nanopb
Re: Procedure for submitting a new Deimos project?
On Thursday, 1 November 2012 at 04:58:36 UTC, Nick Sabalausky wrote: What is the procedure for submitting a new Deimos project? A lot of repositories have been opened by Walter just by posting the project name and description on this forum, so I suggest posting that information in this thread.
Re: Procedure for submitting a new Deimos project?
On Wed, 31 Oct 2012 23:58:39 -0500, Nick Sabalausky wrote: What is the procedure for submitting a new Deimos project? Message one of the contributors. Walter or Andrei or someone. They'll create the repo, then submit a pull request. It's pretty informal.
OSX Installer
I'm trying to write up a tutorial for D+vibed and have stumbled on a pretty basic issue. The DMD installer for OSX fails out of the box on Lion and Mountain Lion because Apple got rid of their developer command line tools stuff: http://robots.thoughtbot.com/post/27985816073/the-hitchhikers-guide-to-riding-a-mountain-lion So basically the install process for new mac users is: 1. Get Xcode 2. Install Command Line tools via Xcode preferences 3. Run DMD mac installer Obvious first question: D needs Xcode to run? Is this going to be fixed in the next release or should I just point to the .zip package instead? Thanks, Josh
Procedure for submitting a new Deimos project?
What is the procedure for submitting a new Deimos project?
Re: Transience of .front in input vs. forward ranges
On Thu, Nov 01, 2012 at 12:05:18AM +0100, deadalnix wrote: > Le 31/10/2012 18:19, H. S. Teoh a écrit : [...] > >Actually, there is another problem: many algorithms' output will be > >transient or not depending on the input range. For example, we could > >write map to use the transient version of byLine, say, but then the > >range that map returns will also be transient (no longer safe). > > > >IOW, transience of .front is transitive in some cases. This again > >makes things complicated: as soon as you use a single transient > >range, it makes downstream ranges transient as well. So we're back to > >the problem of how to mark the range as transient in a transparent > >way. :-( > > > > No it isn't always transitive. But that is true that it is in some > cases. > > This is why the code should default to the safe behavior. It is up to > the programmer to ensure correctness when opting for an alternate > behavior. But then can the alternate behaviour be used at all? For example, joiner will return a range which will be transient if the original range is transient. But since this is "unsafe" behaviour, joiner's implementation can't take advantage of the faster behaviour at all, since otherwise the user, not knowing that it is switching to, say, byLine.fast instead of the safe version of byLine, may assume that the resulting range is non-transient, but it is actually transient. So this nullifies the usefulness of having .fast, since many Phobos algorithms that would have been able to take advantage of .fast can't, because their result will be unsafe. In which case, is it even worth the bother to implement such a thing? I think we still haven't addressed the fundamental issue, that is, we need a way to differentiate between transient and non-transient .front values. Being able to work with transient values is the best, because it automatically also works for non-transient values, but some algos need to be able to assume non-transience. This core problem is still unsolved. T -- Windows: the ultimate triumph of marketing over technology. -- Adrian von Bidder
Re: How do you copy a const struct to a mutable?
Malte Skarupke: What am I missing in order to do this? In D when you define a struct inside a function, it's not a POD any more. If you define it as "static struct A" instead of "struct A", your code will compile. Unfortunately DMD gives a too much generic error message in this case, it doesn't explain what's the problem: test.d(7): Error: cannot implicitly convert expression (a) of type const(A) to A Bye, bearophile
How do you copy a const struct to a mutable?
I want to get this to compile:
void main()
{
struct A
{
this(int x) { this.x = x; }
int x;
}
const(A) a = A(5);
A b = a;
}
It should clearly be legal to create a non-const copy of the
struct. What am I missing in order to do this?
Cheers,
Malte
Re: DConf 2013 on kickstarter.com: we're live!
On 22/10/2012 19:25, Andrei Alexandrescu wrote: We're on! For one month starting today, we're raising funding for DConf 2013. http://www.kickstarter.com/projects/2083649206/the-d-programming-language-conference-2013-0 Please pledge your support and encourage your friends to do the same. Hope to see you in 2013! Thanks, Andrei Looking at the graph and excluding the super-villains (who are they?) the current pool seems close to empty. There will probably be an end spurt if the goals seems in sight, but as it stand I don't see this happening. My reason for not having pledged: Too expensive: flight + ticket. I will pledge 100$ if that would mean videos.
Re: [OT] .NET is compiled to native code in Windows Phone 8
Le 30/10/2012 20:15, Paulo Pinto a écrit : Now Build 2012 is happening and the new Windows Phone 8 features have been revealed. One of the most interesting is that .NET applications are actually compiled to native code as well, before being made available for download. http://blogs.msdn.com/b/dotnet/archive/2012/10/30/announcing-the-release-of-the-net-framework-for-windows-phone-8.aspx Assuming Microsoft eventually releases a native code compiler for C# (better than NGEN), this will make D use harder in the enterprise. :\ -- Paulo This compiler in the cloud things seems really scary. All my apps will not work anymore if microsoft decide so ?
Re: Transience of .front in input vs. forward ranges
Le 31/10/2012 18:19, H. S. Teoh a écrit : On Wed, Oct 31, 2012 at 02:18:55PM +0100, deadalnix wrote: Le 31/10/2012 01:56, H. S. Teoh a écrit : +1. I like this better than my proposal. The obvious drawback is that this make invalidating ranges harder to write. But they seems to be more the exception than the rule. Actually, there is another problem: many algorithms' output will be transient or not depending on the input range. For example, we could write map to use the transient version of byLine, say, but then the range that map returns will also be transient (no longer safe). IOW, transience of .front is transitive in some cases. This again makes things complicated: as soon as you use a single transient range, it makes downstream ranges transient as well. So we're back to the problem of how to mark the range as transient in a transparent way. :-( No it isn't always transitive. But that is true that it is in some cases. This is why the code should default to the safe behavior. It is up to the programmer to ensure correctness when opting for an alternate behavior.
Re: What is the use case for this weird switch mecanism
On Wednesday, 31 October 2012 at 22:58:32 UTC, bearophile wrote: Era Scarecrow: But 'switch with' seems the proper way to put it in my mind. It's not worth the unsafety of the whole switch. What? I'd need a little explanation what you'd mean. besides, 'switch with' and 'with switch' are practically identical... aren't they?
A little Py Vs C++
Maybe this Reddit thread should be completed with a nice D version :-) http://www.reddit.com/r/programming/comments/12ecq5/c11_and_boost_succinct_like_python/ The thread contains some sad comments: http://www.reddit.com/r/programming/comments/12ecq5/c11_and_boost_succinct_like_python/c6uihbi http://www.reddit.com/r/programming/comments/12ecq5/c11_and_boost_succinct_like_python/c6ugw8h Bye, bearophile
Re: What is the use case for this weird switch mecanism
Era Scarecrow: But 'switch with' seems the proper way to put it in my mind. It's not worth the unsafety of the whole switch. Bye, bearophile
Re: The D wiki engine must be replaced
On 10/28/12, Thomas Koch wrote: > [1] http://www.prowiki.org/wiki4d Also it has a rather weak search system. I often can't find pages even when I directly search for their titles. There's also the constant spam issue. If the wiki was somehow based on Git we could review pull requests before merging which would eliminate spam (+ we could put that "edit this page" button (on dlang.org) for wiki pages)
Re: What is the use case for this weird switch mecanism
On Wednesday, 31 October 2012 at 22:01:36 UTC, bearophile wrote:
Chris Nicholson-Sauls:
There is also the trick of doing 'switch(val) with(EnumType)
{...}'
What about writing with(EnumType) switch(val) {...} ?
Maybe... But a problem arises when it's function wide, and
should be able to replace (hopefully) any block. Assuming there's
no syntactical issues that may break other code.
int func()
with(EnumType) { //won't compile
}
int func() {
with(EnumType) { //compiles but seems excessive when it doesn't
need to...
}
}
But 'switch with' seems the proper way to put it in my mind.
Re: The D wiki engine must be replaced
Nick Sabalausky wrote: > I don't really understand what's wrong with the current system - unfamiliar syntax like no other wiki engine I've ever seen - no way to have site names without a camelCase - no history other then precedent version - no watched pages - ... surely much more if you try to really use it > What do you mean by "offline editing" though? Go to https://github.com/gtkd-developers/GtkD/wiki/_access You can git clone the whole content of the wiki, read offline, edit offline and push back to the online wiki. Other systems that allow that are for example ikiwiki, gitit and others
Re: The D wiki engine must be replaced
On Sun, 28 Oct 2012 14:06:08 +0100 Thomas Koch wrote: > Hi, > > I wanted to edit something in the D wiki[1], had a problem and > learned more about the used wiki engine ProWiki. > > [1] http://www.prowiki.org/wiki4d > > - The last ProWiki release was in 2006 > - This was also the first open source release > - Prowiki was apparently developed only by Helmut Leitner > - The project is dead by all standards > > I consider it extremely important for the success of D to have a > usable wiki. I don't consider the current wiki usable. I don't have a > strong opinion about other wiki engines so I won't give a > recommendation here. > > I personally would prefer a wiki system based on Git to allow offline > editing, like Ikiwiki. > > I don't know the history of the wiki, but it might be adequate to > thank Helmut Leitner for his work and efforts. > > Best regards, Thomas Koch I don't really understand what's wrong with the current system (other than the engine apparently being dead as you say...well, and that it rejects user names that have only one capital letter as supposedly not being camel-cased). But if there's a lot of people who feel this way about it (and I don't know - are there?), then that could explain it's tendency to not get updated, in which case maybe it should be changed to something else. What do you mean by "offline editing" though? I'm not a fan of web interfaces in general either, but a wiki is a website, so I'm not sure I understand what you mean. I guess I haven't used ones of these offline editing wikis, unless you count committing/pushing a 'README.md' to github. Do you just mean something that has a published HTTP API (like REST or something) so that arbitrary non-web interfaces can be created?
Re: Make [was Re: SCons and gdc]
On Tuesday, 30 October 2012 at 09:56:08 UTC, Russel Winder wrote: On Tue, 2012-10-30 at 10:08 +0100, Rob T wrote: […] Also scons has no built-in ability to scan subfolders for source files. You can manually specify sub-level source files, but that's unreasonable to do for large projects. You can write custom Python code to scan subfolders, but that is a lot more complicated than it should be. Do you know of a decent solution to scan sub-folders? Using os.walk is quite natural in SCons since SCons is just a Python internal DSL. SConstruct and SConscript are internal DSL files (not external DSL as Makefiles are), thus they are just Python programs. Scons does look like a very powerful tool, and I really do appreciate your input and the other posters as well. I am determined not to continue with Make, so maybe I will have to keep trying to get scons to do what I want. Mayhap then what you need to do is look at Parts. This is Jason Kenny's superstructure over SCons to deal with huge projects scattered across everywhere. This is the build framework Intel uses for their stuff. Intel have more and bigger C and C++ projects than I think anyone else around One more question: I am wondering how the scons D support locates dependencies from the imports specfied in the source files? So far I have not been able to get automatic dependency inclusions to work, so I end up manually specifying the import files. With C++ and Make, I could get gcc to scan source files for the #include files, and dump the list to a dependency file (.dep), and then I could include the .dep file(s) into the make process. Can scons with D support do something similar, or deal with it better? Now this is a whole different issue! I have no idea. If it is a problem it needs fixing. The general philosophy in SCons is to have scanners that find the dependencies. In C and C++ this is the awful #include. In D it's import. The code should create a graph of the dependencies that can be walked to create the list of inputs. There is a bit of code in the D tooling that is supposed to do this. If it doesn't then we need a bug report and preferably a small project exhibiting the problem that can be entered into the test suite — SCons development is obsessively TDD. I can only do stuff for Linux and OS X, I cannot do anything for Windows, and Windows is the "big problem" for the SCons D tooling at the moment which is why it has not got merged into the SCons mainline for release in 2.3.0. A plea for help: in order for SCons to have sane support for D, it needs people to step up and actively assist evolve the tools either by providing small test projects exhibiting fails, or running the tests on Windows and providing patches for fails. Currently I am not working in D, just in Python, Java, Groovy, Scala, Ceylon, Kotlin, so I have no D code activity I can use to evolve the D support in SCons. But if the D community can provide test cases, I can get SCons evolved to do the needful. But only on Linux and OS X, I definitely need a collaborator interested in working on Windows. I also belong to the JVM/.NET languages at work camp, but since I use both Windows and UNIX based systems, I could execute Windows tests if required. -- Paulo
Re: "isDroppable" range trait for slicing to end
On Wednesday, October 31, 2012 11:37:13 monarch_dodra wrote: > IMO, this makes a clean distinction between both "types" of > slicing. An added bonus is that (for now) it also correctly > supports finite RA ranges that don't define opDollar. I don' think that such a distinction should be made at all. I think that all sliceable ranges should be required to implement opDollar. The problem is that it's unreasonable to require that when opDollar just got fixed, and arguably issue# 7177 should be implemented before it's reasonable to require it. But regardless, that means that creating a trait to test for opDollar working doesn't make sense. It would just have to be thrown away later. > PS: Do we really have to force that infinite slice to be of a > type of "take"? Does that mean we can't imagine an infinite range > that defines it's own finite slice type? I think that it's more valuable to make it consistent. What would a separate finite type even buy you? It would just be doing what take would do. I do kind of like the idea of just disallowing slicing without opDollar on infinite ranges though, in which case you'd have to use take yourself. I don't know what Andrei's take would be on that though. - Jonathan M Davis
Re: "isDroppable" range trait for slicing to end
10/31/2012 10:37 AM, monarch_dodra пишет:
On Wednesday, 31 October 2012 at 08:58:18 UTC, Jonathan M Davis wrote:
I agree, but for that to be realistic, I think that issue# 7177 needs
to be
implemented first. You should check out the pull request that I have for
improving hasSlicing. I just updated it according to some of the
discussion
here, and it now checks the behavior of opDollar when it works with
the range
being sliced. For finite ranges, it essentially enforces that they
function
like arrays do, and for infinite ranges, it comes as close to that as
it can:
https://github.com/D-Programming-Language/phobos/pull/854
As of the latest state of that pull request, hasSlicing looks like
template hasSlicing(R)
{
enum bool hasSlicing = !isNarrowString!R && is(typeof(
(inout int _dummy=0)
{
R r = void;
static if(isInfinite!R)
typeof(take(r, 1)) s = r[1 .. 2];
else
R s = r[1 .. 2];
s = r[1 .. 2];
static if(is(typeof(r[0 .. $])))
{
R t = r[0 .. $];
t = r[0 .. $];
static if(!isInfinite!R)
{
R u = r[0 .. $ - 1];
u = r[0 .. $ - 1];
}
}
static assert(isForwardRange!(typeof(r[1 .. 2])));
static assert(hasLength!(typeof(r[1 .. 2])));
}));
}
- Jonathn M Davis
I'm not a huge fan of the "opDollar" check, because essentially, it
doesn't really buy you anything: if hasSlicing!R, then is "r = r[1..$]"
legal? Who knows! You as a developer need to check manually that "r[0 ..
$]" is legal first anyways...
That's a temporary thing because otherwise it'll break all of current
RA. The idea is that if there is $ then it's tested
Under those circumstances, why not cleanly splice the two notions?
//
template hasSlicing(R)
{
enum bool hasSlicing = !isNarrowString!R && is(typeof(
(inout int _dummy=0)
{
R r = void;
static if(isInfinite!R)
typeof(take(r, 1)) s = r[1 .. 2];
else
R s = r[1 .. 2];
s = r[1 .. 2];
static assert(isForwardRange!(typeof(r[1 .. 2])));
static assert(hasLength!(typeof(r[1 .. 2])));
}));
}
template hasSlicingToEnd(R)
{
enum bool hasSlicingToEnd = !isNarrowString!R && is(typeof(
(inout int _dummy=0)
{
R r = void;
static if(is(typeof(r[0 .. $])))
{
R t = r[0 .. $];
t = r[0 .. $];
static if(!isInfinite!R)
{
R u = r[0 .. $ - 1];
u = r[0 .. $ - 1];
}
}
}));
}
//
IMO, this makes a clean distinction between both "types" of slicing. An
added bonus is that (for now) it also correctly supports finite RA
ranges that don't define opDollar.
Jonathon's version also supports RA without opDollar.
//
PS: Do we really have to force that infinite slice to be of a type of
"take"? Does that mean we can't imagine an infinite range that defines
it's own finite slice type?
if we change the code to:
//
static if(isInfinite!R)
auto s = r[1 .. 2]; //HERE1
else
R s = r[1 .. 2];
s = r[1 .. 2]; //HERE2
//
Then we force nothing on the slice's type (HERE1), but do verify that
subsequent slices will be assignable back to the original slice (HERE2)...
Well I'd rather never check that infinite range has 1..2 form of slicing
to begin with. If we have some that do then we'd have to keep it.
--
Dmitry Olshansky
Re: Transience of .front in input vs. forward ranges
On Wed, Oct 31, 2012 at 02:18:55PM +0100, deadalnix wrote: > Le 31/10/2012 01:56, H. S. Teoh a écrit : > > > >+1. I like this better than my proposal. > > > > The obvious drawback is that this make invalidating ranges harder to > write. But they seems to be more the exception than the rule. Actually, there is another problem: many algorithms' output will be transient or not depending on the input range. For example, we could write map to use the transient version of byLine, say, but then the range that map returns will also be transient (no longer safe). IOW, transience of .front is transitive in some cases. This again makes things complicated: as soon as you use a single transient range, it makes downstream ranges transient as well. So we're back to the problem of how to mark the range as transient in a transparent way. :-( T -- VI = Visual Irritation
Re: SCons and gdc
On Wed, Oct 31, 2012 at 02:55:29PM +, Russel Winder wrote: > On Tue, 2012-10-30 at 09:53 -0700, H. S. Teoh wrote: > […] > > That's not a bad idea. I also noticed that gdc tends to produce smaller > > executables when compiling in this way (I'm not sure why -- are > > identical template instances not getting merged when compiling > > separately?). > > Is it fair to assume that DMD, LDC, and GDC all have the same behaviour > in this respect? [...] Interesting, I just tested this with dmd (git HEAD), and it exhibits the same effect too. Perhaps it's a good idea to do a single compile step then. T -- What are you when you run out of Monet? Baroque.
D2 auto tester is hung on specific unittest
I'm not sure who to notify, but I seem to have hung the unittester on one of my releases: http://d.puremagic.com/test-results/pull-history.ghtml?repoid=3&pullid=915 Those first 3 tests have been running (as of now) for about 5 hours. I've tried to get in touch with a couple of people, but they must all be sleeping. Anybody here have the power to kill these releases? Sorry for the inconvenience.
Re: The D wiki engine must be replaced
On Wednesday, 31 October 2012 at 13:09:10 UTC, David Nadlinger wrote: On Sunday, 28 October 2012 at 13:06:09 UTC, Thomas Koch wrote: I consider it extremely important for the success of D to have a usable wiki. I don't consider the current wiki usable. I don't have a strong opinion about other wiki engines so I won't give a recommendation here. I personally would prefer a wiki system based on Git to allow offline editing, like Ikiwiki. Yes, I agree that the current wiki setup is very awkward and clumsy to use. However, my preferred solution would just be a MediaWiki instance (with a slightly customized theme, of course), because this is what everybody is already familiar with from Wikipedia and other wiki sites. David If it's just the syntax: gollum understands mediawiki. The advantages I see are no need to setup and administrate a custom solution and the core people of the D community are already using git. That I don't need to use a crappy web interface if I don't want to is a big plus, too.
Re: SCons and gdc
On Tue, 2012-10-30 at 09:53 -0700, H. S. Teoh wrote: […] > That's not a bad idea. I also noticed that gdc tends to produce smaller > executables when compiling in this way (I'm not sure why -- are > identical template instances not getting merged when compiling > separately?). Is it fair to assume that DMD, LDC, and GDC all have the same behaviour in this respect? -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.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: Transience of .front in input vs. forward ranges
Le 31/10/2012 01:56, H. S. Teoh a écrit : +1. I like this better than my proposal. The obvious drawback is that this make invalidating ranges harder to write. But they seems to be more the exception than the rule.
Re: The D wiki engine must be replaced
On Sunday, 28 October 2012 at 13:06:09 UTC, Thomas Koch wrote: I consider it extremely important for the success of D to have a usable wiki. I don't consider the current wiki usable. I don't have a strong opinion about other wiki engines so I won't give a recommendation here. I personally would prefer a wiki system based on Git to allow offline editing, like Ikiwiki. Yes, I agree that the current wiki setup is very awkward and clumsy to use. However, my preferred solution would just be a MediaWiki instance (with a slightly customized theme, of course), because this is what everybody is already familiar with from Wikipedia and other wiki sites. David
Re: The D wiki engine must be replaced
Tobias Pankrath wrote: > What about the wiki engine build into github? The wiki engine is called Gollum[1] and is itself free software. The wiki is editable via the web interface and offline with a text editor. It supports half a douzend popular markups, including markdown, org-mode, restructured text, creole. Of course the wiki could be hosted as a wiki to a separate dummy project under https://github.com/D-Programming-Language. Please don't make it a wiki for the dmd project since D is more then one compiler implementation. Even for me as a free software advocate I'd favour this quick github solution over the current state. It's still possible at any time to setup an own instance of Gollum and host the wiki somewhere else. [1] https://github.com/github/gollum Best regards, Thomas Koch
Re: 48 hour game jam
On 2012-10-31 11:42, Manu wrote: Cool, I'll come and idle too when I'm at home. Probably just a few more little #ifdef's here and there. And the include/lib paths are weird for OpenGL in OSX if i recall... The standard way when building Cocoa applications is to use the OpenGL framework, located at /System/Library/Frameworks/OpenGL.framework. It will contain both the headers and the actual library. I'm usually online somewhere between 19:30 and 22:00 GMT +1. -- /Jacob Carlborg
Re: 48 hour game jam
On 31 October 2012 09:35, Jacob Carlborg wrote: > On 2012-10-30 23:17, Manu wrote: > > I've fixed all the outstanding Linux stuff, I'd love to finish off that >> OSX stuff some time soon. >> > > Unfortunately I haven't much time to work at D right now at all, but I can > usually squeeze in an hour per day, more during the weekends. I'm online at > the IRC D channel when I'm at the computer. > > I have the code ready for the creating a window but I need help to > integrate it with the game engine. Last time I compiled the game engine > there was some problem related to OpenGL headers or similar. Cool, I'll come and idle too when I'm at home. Probably just a few more little #ifdef's here and there. And the include/lib paths are weird for OpenGL in OSX if i recall...
Re: "isDroppable" range trait for slicing to end
On Wednesday, 31 October 2012 at 08:58:18 UTC, Jonathan M Davis
wrote:
I agree, but for that to be realistic, I think that issue# 7177
needs to be
implemented first. You should check out the pull request that I
have for
improving hasSlicing. I just updated it according to some of
the discussion
here, and it now checks the behavior of opDollar when it works
with the range
being sliced. For finite ranges, it essentially enforces that
they function
like arrays do, and for infinite ranges, it comes as close to
that as it can:
https://github.com/D-Programming-Language/phobos/pull/854
As of the latest state of that pull request, hasSlicing looks
like
template hasSlicing(R)
{
enum bool hasSlicing = !isNarrowString!R && is(typeof(
(inout int _dummy=0)
{
R r = void;
static if(isInfinite!R)
typeof(take(r, 1)) s = r[1 .. 2];
else
R s = r[1 .. 2];
s = r[1 .. 2];
static if(is(typeof(r[0 .. $])))
{
R t = r[0 .. $];
t = r[0 .. $];
static if(!isInfinite!R)
{
R u = r[0 .. $ - 1];
u = r[0 .. $ - 1];
}
}
static assert(isForwardRange!(typeof(r[1 .. 2])));
static assert(hasLength!(typeof(r[1 .. 2])));
}));
}
- Jonathn M Davis
I'm not a huge fan of the "opDollar" check, because essentially,
it doesn't really buy you anything: if hasSlicing!R, then is "r =
r[1..$]" legal? Who knows! You as a developer need to check
manually that "r[0 .. $]" is legal first anyways...
Under those circumstances, why not cleanly splice the two notions?
//
template hasSlicing(R)
{
enum bool hasSlicing = !isNarrowString!R && is(typeof(
(inout int _dummy=0)
{
R r = void;
static if(isInfinite!R)
typeof(take(r, 1)) s = r[1 .. 2];
else
R s = r[1 .. 2];
s = r[1 .. 2];
static assert(isForwardRange!(typeof(r[1 .. 2])));
static assert(hasLength!(typeof(r[1 .. 2])));
}));
}
template hasSlicingToEnd(R)
{
enum bool hasSlicingToEnd = !isNarrowString!R && is(typeof(
(inout int _dummy=0)
{
R r = void;
static if(is(typeof(r[0 .. $])))
{
R t = r[0 .. $];
t = r[0 .. $];
static if(!isInfinite!R)
{
R u = r[0 .. $ - 1];
u = r[0 .. $ - 1];
}
}
}));
}
//
IMO, this makes a clean distinction between both "types" of
slicing. An added bonus is that (for now) it also correctly
supports finite RA ranges that don't define opDollar.
//
PS: Do we really have to force that infinite slice to be of a
type of "take"? Does that mean we can't imagine an infinite range
that defines it's own finite slice type?
if we change the code to:
//
static if(isInfinite!R)
auto s = r[1 .. 2]; //HERE1
else
R s = r[1 .. 2];
s = r[1 .. 2]; //HERE2
//
Then we force nothing on the slice's type (HERE1), but do verify
that subsequent slices will be assignable back to the original
slice (HERE2)...
Re: The D wiki engine must be replaced
On Sunday, 28 October 2012 at 13:06:09 UTC, Thomas Koch wrote: Hi, I wanted to edit something in the D wiki[1], had a problem and learned more about the used wiki engine ProWiki. [1] http://www.prowiki.org/wiki4d - The last ProWiki release was in 2006 - This was also the first open source release - Prowiki was apparently developed only by Helmut Leitner - The project is dead by all standards I consider it extremely important for the success of D to have a usable wiki. I don't consider the current wiki usable. I don't have a strong opinion about other wiki engines so I won't give a recommendation here. I personally would prefer a wiki system based on Git to allow offline editing, like Ikiwiki. I don't know the history of the wiki, but it might be adequate to thank Helmut Leitner for his work and efforts. Best regards, Thomas Koch What about the wiki engine build into github?
Re: [OT] .NET is compiled to native code in Windows Phone 8
On Wednesday, 31 October 2012 at 07:19:23 UTC, thedeemon wrote: On Tuesday, 30 October 2012 at 19:15:59 UTC, Paulo Pinto wrote: Now Build 2012 is happening and the new Windows Phone 8 features have been revealed. One of the most interesting is that .NET applications are actually compiled to native code as well, before being made available for download. http://blogs.msdn.com/b/dotnet/archive/2012/10/30/announcing-the-release-of-the-net-framework-for-windows-phone-8.aspx Assuming Microsoft eventually releases a native code compiler for C# (better than NGEN), this will make D use harder in the enterprise. :\ -- Paulo I don't think they're going to. There are many reasons of keeping assemblies in easy to verify and operate bytecode, and ngen has been here for quite a while without much impact. The problem with ngen is that it has a very basic optimizer, and there are some restrictions to which type of bytecode (no reflection tricks) is ngen-able. Those restrictions are artificial, other C# native code compilers (Mono, Sing#) don't have them. -- Paulo
Re: "isDroppable" range trait for slicing to end
On Wednesday, October 31, 2012 12:37:10 Dmitry Olshansky wrote:
> I just wanted to point out that we may as well require all RA ranges to
> have opDollar. Finite already have length, infinite would have marker.
> Just need some migration path so that current RA won't lose their title
> over night.
I agree, but for that to be realistic, I think that issue# 7177 needs to be
implemented first. You should check out the pull request that I have for
improving hasSlicing. I just updated it according to some of the discussion
here, and it now checks the behavior of opDollar when it works with the range
being sliced. For finite ranges, it essentially enforces that they function
like arrays do, and for infinite ranges, it comes as close to that as it can:
https://github.com/D-Programming-Language/phobos/pull/854
As of the latest state of that pull request, hasSlicing looks like
template hasSlicing(R)
{
enum bool hasSlicing = !isNarrowString!R && is(typeof(
(inout int _dummy=0)
{
R r = void;
static if(isInfinite!R)
typeof(take(r, 1)) s = r[1 .. 2];
else
R s = r[1 .. 2];
s = r[1 .. 2];
static if(is(typeof(r[0 .. $])))
{
R t = r[0 .. $];
t = r[0 .. $];
static if(!isInfinite!R)
{
R u = r[0 .. $ - 1];
u = r[0 .. $ - 1];
}
}
static assert(isForwardRange!(typeof(r[1 .. 2])));
static assert(hasLength!(typeof(r[1 .. 2])));
}));
}
- Jonathn M Davis
Re: To avoid some linking errors
On 10/31/2012 12:39 AM, Jacob Carlborg wrote:> Assuming you have a fairly unique symbols in a quite small project. This where > an IDE would be great to have. It could point to all the locations of the actual > symbol, not just all text that matches the symbol. Sure, but us long time command line users tend to write greppable names :-)
Re: "isDroppable" range trait for slicing to end
10/31/2012 4:48 AM, Jonathan M Davis пишет: On Monday, October 29, 2012 15:33:00 monarch_dodra wrote: More often than not, we want to slice a range all the way to the end, and we have to use the clumsy "r[0 .. r.length]" syntax. What's worst is that when a range is infinite, there is no real way to "slice to the end", unless you just repeatedly popFront. As already pointed out, this is solved by opDollar. We don't have a trait for it, but it can be tested for easily enough by doing something like typeof(is(r[0 .. $])) or __traits(compiles, r[0 .. $]). We may still want to create a trait for it though (e.g. hasOpDollar). I just wanted to point out that we may as well require all RA ranges to have opDollar. Finite already have length, infinite would have marker. Just need some migration path so that current RA won't lose their title over night. [snip] Finite ranges which could have n elements popped in O(1) would be sliceable anyway, meaning that popFrontN would be O(1) for them already and that if a function requires popping n elements in O(1), it can just slice the range. So, isDroppable buys us nothing for finite ranges. The only gain that I really see here is that it would provide a way for infinite ranges to pop off their first n elements and still be infinite. As it stands, the best that you can do is slice them, but that has to result in another range type, because a finite slice can't be infinite. Yes, the whole argument started with infinite ranges. However, if we take advantage of opDollar, then I think we can solve the problem that way. By using opDollar when slicing an infinite range, you should be able to keep the original range type. That being the case, I don't think that isDroppable is really necessary. I said elsewhere I have feeling that hasSlicing should really check for x = x[a..b]; Whereas for infinite ranges we need a weaker trait isDropable/hasSlicingToEnd(??): x = [a..$]; Howevere, it _does_ mean that I should probably adjust my pull for hasSlicing so that it tests that slicing an infinite range with opDollar returns the original type (assuming that opDollar compiles for it). Of course, once opDollar works (I don't know what it's current state is), it would be desirable to require it to work with slicing anyway, so maybe hasSlicing should have that requirement added at a later date. Indeed, alternatively we can check for both hasSlicing and isInfinite. Then in case of Infinite = true slicing only works up to $, this could be a better idea. -- Dmitry Olshansky
Re: 48 hour game jam
On 2012-10-30 23:17, Manu wrote: I've fixed all the outstanding Linux stuff, I'd love to finish off that OSX stuff some time soon. Unfortunately I haven't much time to work at D right now at all, but I can usually squeeze in an hour per day, more during the weekends. I'm online at the IRC D channel when I'm at the computer. I have the code ready for the creating a window but I need help to integrate it with the game engine. Last time I compiled the game engine there was some problem related to OpenGL headers or similar. -- /Jacob Carlborg
Re: To avoid some linking errors
On 2012-10-30 22:49, Andrei Alexandrescu wrote: Non-issue. Grep takes care of that. Finding the cross-references and the overloading part are the hard problems here. This is so clear to me for so many reasons, I am paralyzed by options. Assuming you have a fairly unique symbols in a quite small project. This where an IDE would be great to have. It could point to all the locations of the actual symbol, not just all text that matches the symbol. -- /Jacob Carlborg
Re: Imports with versions
On 2012-10-30 21:55, Paulo Pinto wrote: This cannot be enforced on runtime for most languages, that was why I was generalizing. For example C and C++ require the programmer to do this, somehow. It's possible to change the path where a dynamic library is expected to be located after the application/library is compiled. The package manager can change this when installing a package. Java requires you bundled something like OSGi with your application. From the languages I have real project experience, only Groovy and .NET provide out of the box mechanisms for runtime validations given in the package manager. It's one thing saying that your existing tools cannot handle this. It's an entirely different thing saying it's not possible. -- /Jacob Carlborg
Re: opDollar questions
On Tuesday, October 30, 2012 08:01:58 monarch_dodra wrote:
> 1.
> I saw a pull request that claimed to "fix" opDollar go through
> recently. Does this mean we can now use it correctly? In both
> r[0..$];
> and
> r[$..$];
> forms?
It seems to work from the little playing around with it that I've done.
> 2.
> Would it be OK if I asked for a little implementation tutorial on
> opDollar, and how to correctly write one when dimensions can get
> involved? I'm unsure how it is done (I've seen both
> "opDollar(size_t dim)()" and "opDollar(size_t dim)")
The only documentation on it that I'm aware of is in TDPL, and the section
isn't very long.
> 3.
> One last question: The possibility of using opDollar to slice a
> range to its end (in particular, infinite ranges) has been
> brought up more than once. May I request we have a normalized
> type:
> struct InfDollar{}
>
> Or something inside range.d?
>
> This way, infinite ranges would not have to invent a new token
> themselves just for this, and simply implement "auto
> opSlice(size_t i, InfDollar dol)?"
Sounds reasonable to me.
> 4. In the context of the above question, would it be possible to
> implement opDollar simply as an enum?
> enum opDollar = InfDollar.init;
> Or would that be a problem?
I very much doubt it, but I don't know. You'll have to try it and see if it
works.
- Jonathan M Davis
Re: DMD on Haiku?
On 30-10-2012 21:59, Paulo Pinto wrote: On Tuesday, 30 October 2012 at 18:53:23 UTC, Alex Rønne Petersen wrote: On 30-10-2012 19:35, Paulo Pinto wrote: On Tuesday, 30 October 2012 at 13:55:42 UTC, Alex Rønne Petersen wrote: On 30-10-2012 14:46, Isak Andersson wrote: Based on my experience POSIX compliance is like any standard. You end up getting lots of #ifdef for each POSIX system anyway. The only people that think POSIX is a standard without any issues, only know GNU/Linux. One thing missing from the list which costs a lot of effort, is code generation. Based on my toy Solaris experience with DMD, I think it is easier to use LDC or GDC for bringing D to other platforms. -- Paulo Yeah, it seems like POSIX kind of failed in the sense that you can't just have a simple posix makefile that works for any posix compliant os. I direct you to the POSIX makefiles of DMD, druntime, and phobos. ;) Which as far as I am aware only work on POSIX == Linux. Er... they work on Linux, OS X, FreeBSD, OpenBSD, Solaris/SunOS. Ok I was a bit stupid with my remark, sorry about that. Anyway, I remember when I tried my toy experiment with porting DMD for Solaris I had to do some patches. You would be surprised what commercial UNIX systems understand as POSIX vs what the standard says. Somehow I don't miss my days porting software among UNIX platforms. -- Paulo All D toolchain makefiles should work fine on Solaris out of the box now - at least the latest version of the OS. -- Alex Rønne Petersen a...@lycus.org http://lycus.org
Re: "isDroppable" range trait for slicing to end
On Wednesday, October 31, 2012 08:13:08 monarch_dodra wrote: > BTW: Once you are done, maybe you could present here what it > means exactly to be slice-able? AFAIK, your current proposal > allows for infinite ranges to verify "hasSlicing", if they can be > sliced between [a ... b], whereas Dmitry seems to think that > should not be so. At all. It works now, but I'm open to removing it, since it _is_ odd to be able to slice an infinite range and get a completely different type from out. opSlice with opDollar combined with take would give you the same effect: take(infRange[a .. $], b - a); But without at least having opSlice with opDollar, you'd be forced to use drop or popFrontN, which would be O(n) rather than O(1). > Well in conclusion, sorry to have brought a crappy solution :/ I > guess we had something simple all along... Well, live and learn. It happens to us all from time to time. I'd forgotten about opDollar prior to this discussion (mostly because it wasn't working), and it's quite applicable to hasSlicing. - Jonathan M Davis
Re: [OT] .NET is compiled to native code in Windows Phone 8
On Tuesday, 30 October 2012 at 19:15:59 UTC, Paulo Pinto wrote: Now Build 2012 is happening and the new Windows Phone 8 features have been revealed. One of the most interesting is that .NET applications are actually compiled to native code as well, before being made available for download. http://blogs.msdn.com/b/dotnet/archive/2012/10/30/announcing-the-release-of-the-net-framework-for-windows-phone-8.aspx Assuming Microsoft eventually releases a native code compiler for C# (better than NGEN), this will make D use harder in the enterprise. :\ -- Paulo I don't think they're going to. There are many reasons of keeping assemblies in easy to verify and operate bytecode, and ngen has been here for quite a while without much impact.
Re: "isDroppable" range trait for slicing to end
On Tuesday, 30 October 2012 at 17:49:20 UTC, Dmitry Olshansky wrote: 10/30/2012 6:53 AM, monarch_dodra пишет: Not *that* theoretical when you think about it. ascii's "digits" etc are all immutable ranges. They are a bad example, because they are strings (ergo un-sliceable), but as a rule of thumb, any global container can be saved as an immutable range. For example, I could define "first 10 integers" as an immutable range. That range would be slice-able, but would not verify "hasSlicing". You do make a common mistake of confusing a container and a range over it. Ranges are means of iteration, they are mutable by the very definition - every time you call popFront/popBack iteration state *changes*. So you can't pop first item of "first 10 integers". It's an immutable entity that you can't manipulate. In that sense slicing such an entity (container) is the way of extracting a _mutable_ range from it. Yet numbers it cycles through are immutable. Yes, that is quite true. Although in this case, the slice is both container and range. The way I see it, maybe a beter solution would be a refinement of: *hasSlicing: **r = r[0 .. 1]; MUST work (so infinite is out) *hasEndSlicing **r = r[1 .. $]; Must work (intended for infinite, or to verify opDollor) I suggest to stop there. In other words introduce hasEndSlicing (awful name) and check self-assignabliity of both. To which we could add "limited" variants: "hasLimitedSlicing" and "hasLimitedEndSlicing", which would *just* mean we can extract a slice, but not necessarily re-assign it. This repeats the same argument of extractSlice albeit differently. Well, in my mind, the argument was the opposite, it would mean you'd be able to write r[i..j] simply (as opposed to r.extractSlice(i, j)). This seems like a simple but efficient solution. Thoughts? It's not simple. I suggest we drop the no self-assignable slicing altogether. I claim that *if* you can't self assign a slice of a range it basically means that you are slicing something that is not meant to be a range but rather a container (adapter etc.). That *would* make things simpler. I guess that's a good way of seeing it. On Wednesday, 31 October 2012 at 04:53:00 UTC, Jonathan M Davis wrote: As already pointed out, this is solved by opDollar. We don't have a trait for it, but it can be tested for easily enough by doing something like typeof(is(r[0 .. $])) or __traits(compiles, r[0 .. $]). We may still want to create a trait for it though (e.g. hasOpDollar). In my defense, I started thinking about this back when opDollar didn't work at all. However, if we take advantage of opDollar, then I think we can solve the problem that way. By using opDollar when slicing an infinite range, you should be able to keep the original range type. That being the case, I don't think that isDroppable is really necessary. Yes, in that context, that would also work (but had not thought of this). BTW: Once you are done, maybe you could present here what it means exactly to be slice-able? AFAIK, your current proposal allows for infinite ranges to verify "hasSlicing", if they can be sliced between [a ... b], whereas Dmitry seems to think that should not be so. At all. Well in conclusion, sorry to have brought a crappy solution :/ I guess we had something simple all along... Whilst were on the subject of opDollar, and how it can solve all of our problems, could one of you two maybe answer the questions in this thread? http://forum.dlang.org/thread/ehywdvmcmgyawgzfp...@forum.dlang.org
