Re: LLVM 3.6 released - LDC master branch/0.15.1 is ready to use it!
On Friday, 27 February 2015 at 19:44:01 UTC, Kai Nacke wrote: Hi all! Finally, LLVM 3.6 has been released! See the release notes here: http://llvm.org/releases/3.6.0/docs/ReleaseNotes.html Downloads: http://llvm.org/releases/download.html#3.6.0 Also note that LDC is mentioned in the release notes as one of the projects who are already supporting LLVM 3.6. Just recompile LDC using master branch from GitHub or from the 0.15.1 source. This is the 6th time that LDC and D are mentioned in the LLVM release notes! Regards, Kai Congratulations! Thanks for your work on this.
LLVM 3.6 released - LDC master branch/0.15.1 is ready to use it!
Hi all! Finally, LLVM 3.6 has been released! See the release notes here: http://llvm.org/releases/3.6.0/docs/ReleaseNotes.html Downloads: http://llvm.org/releases/download.html#3.6.0 Also note that LDC is mentioned in the release notes as one of the projects who are already supporting LLVM 3.6. Just recompile LDC using master branch from GitHub or from the 0.15.1 source. This is the 6th time that LDC and D are mentioned in the LLVM release notes! Regards, Kai
Re: Berlin D Meetup Feb 2015
I thought I would give a brief summary of the last meetup. Joseph Wakeling gave a presentation entitled “Random number generation in Phobos and beyond”. It was a great talk and we had some interesting discussions afterwards. The talk began by mentioning some naive ways of generating random numbers and some of the negative consequences this can cause. Joseph then mentioned other methods of generating random numbers including big tables of random numbers, physical randomness, and deterministic methods (pseudo-random). Pseudo-random number generators (RNGs) use a state variable and a transition function that maps from the current state to the next state and this sounds like a good match for a forward range. Currently in Phobos all RNGs are implemented as ForwardRange structs. Other ranges such as randomCover and randomSample wrap the Phobos RNGs. Wrapping the RNGs can cause problems as structs are passed by value. This means that if the same RNG is used in subsequent calls to say randomCover then the same sequence of random numbers will be produced by each range. A simple solution to this would be make random ranges classes. This can also cause problems but with memory management (we want to avoid lots of small alloc and free events). It also does not address problems with functions that make bad assumptions about their arguments. If we can solve these problems then there are several different avenues to push forward with new RNG wrapper functionality. There are also other opportunities for looking at random number generation. After the talk there was some discussion on a number of points including: Testing RNGs. The unittests in std.random don't (and can't) provide tests of randomness. There are existing RNG tests in linux. It would be good to get a good randomness test suite in D. Does the c++ standard library have the same problems? Possibly, there was some certainty that the boost documentation has some reference to the same problems. Is this a general problem with forward ranges? Could there be something missing from the range interface or perhaps it would be better to have a distinct range type for random numbers. There was then a discussion of the various types of hardware RNGs. Martin Novak mentioned “haveged” a C program that can generate large numbers of random numbers. It generates randomness based on variations in code execution time on a processor. Thanks, Ben.
Re: Berlin D Meetup Feb 2015
On Thursday, 12 February 2015 at 01:58:04 UTC, Walter Bright wrote: I see you're doing the presentation! I note that you haven't submitted a presentation proposal for Dconf 2015 yet. Please submit this one! Why not get the most mileage out of it? Submitted :-)
Re: Mister Math is wanted!
On Friday, 27 February 2015 at 09:27:49 UTC, Ilya Yaroshenko wrote: Unfortunate overlap in functionality is unfortunate. $ git grep -i kahan std/algorithm/iteration.d:$(D sum) uses the $(WEB en.wikipedia.org/wiki/Kahan_summation, std/algorithm/iteration.d:Kahan summation) algorithm.) std/algorithm/iteration.d:return sumKahan!E(seed, r); std/algorithm/iteration.d:// Kahan algo http://en.wikipedia.org/wiki/Kahan_summation_algorithm std/algorithm/iteration.d:private auto sumKahan(Result, R)(Result result, R r) $ _ Andrei Would one of the following solutions be fortunate ? I. Use alias of fsum!(Summation. Appropriate) for floating version of std.algorithm.sum. Appropriate algorithm performs D Pairwise summation for random access ranges. Otherwise performs D KBN summation of floating point and complex numbers and Kahan summation of user defined types. or II. Move this submodule to std.algorithm.iteration. or III. Remove Kahan (including KBN and KB2) and Pairwise algorithms from fsum, and use only Precise algorithm for std.numeric. Probably, I have found good solution. Summator struct can be represented in std.numeric and std.algorithm.sum can be extended by the new functionality. So there will be no overlap in functionality.
Re: LDC for iOS
On Thursday, 26 February 2015 at 18:35:00 UTC, Dan Olson wrote: I think this all is in good enough shape that someone else should give it a try. https://github.com/smolt/ldc-iphone-dev This is an LDC development sandbox for iPhone iOS. It glues together various pieces needed to build an LDC cross compiler targeting iPhoneOS. It also includes a few samples to show how to get started. The compiler and libraries are in good enough shape to pass the druntime/phobos unittests with a few minor test failures (see project README.md). This means someone could, if so inclined, build their D library and use it in an iOS App. Currently based on LDC 0.15.1 (DMD v2.066.1) and LLVM 3.5.1. There are no prebuild binaries, so you have to do it yourself. Nobody has reported yet on trying to build beside me, so there may be potholes. Enjoy, Dan Thank you very much! Although I cannot test it right now (working mainly on Linux), I will soon give it a go, because we've been asked several times whether one of our apps will be available on the iPhone/iPad one day. This is very important work and, again, I thank you for your efforts.
Re: Dgame revived
This module should work as a standalone with a few tiny import changes: https://github.com/Dav1dde/glamour/blob/master/glamour/util.d The interesting bit is checkgl, used for example like this: checkgl!glDrawArrays(GL_POINTS, 0, 10); then you get a nice debug message if glDrawArrays reports an error. It will also report if a previous error has occurred and wasn't cleared, but of course in that case it won't be able to tell you where. I wrap every OpenGL call with checkgl, it helps immensely. Yes, I will do so in the future too.
Re: Dgame revived
Hey, I'm using tilemap :P I guess a separate project for tilemaps built on Dgame would be cool. I might look into this during the semester break. It's very easy to build a TileMap if you use Sprites. So I don't see (currently) any use case of the TileMap module. One thing that would be cool is some sort of support for 2D physics. It's probably outside Dgame scope but as a separate project that keeps a consistent API with Dgame would be nice. Kind of like the way SDL, SDL_image, SDL_ttf all do. Yeah, that would be nice and usefull for future games. :) Cool, two new projects for me to look into when I should be studying :) Thanks, amber
Re: Mister Math is wanted!
Unfortunate overlap in functionality is unfortunate. $ git grep -i kahan std/algorithm/iteration.d:$(D sum) uses the $(WEB en.wikipedia.org/wiki/Kahan_summation, std/algorithm/iteration.d:Kahan summation) algorithm.) std/algorithm/iteration.d:return sumKahan!E(seed, r); std/algorithm/iteration.d:// Kahan algo http://en.wikipedia.org/wiki/Kahan_summation_algorithm std/algorithm/iteration.d:private auto sumKahan(Result, R)(Result result, R r) $ _ Andrei Would one of the following solutions be fortunate ? I. Use alias of fsum!(Summation. Appropriate) for floating version of std.algorithm.sum. Appropriate algorithm performs D Pairwise summation for random access ranges. Otherwise performs D KBN summation of floating point and complex numbers and Kahan summation of user defined types. or II. Move this submodule to std.algorithm.iteration. or III. Remove Kahan (including KBN and KB2) and Pairwise algorithms from fsum, and use only Precise algorithm for std.numeric.
Re: Dgame revived
On Thursday, 26 February 2015 at 02:22:18 UTC, stewarth wrote:
On Wednesday, 25 February 2015 at 15:36:21 UTC, Gan wrote:
On Tuesday, 24 February 2015 at 22:03:29 UTC, stewarth wrote:
On Tuesday, 24 February 2015 at 21:10:53 UTC, Gan wrote:
On Tuesday, 24 February 2015 at 21:07:04 UTC, stewarth wrote:
On Tuesday, 24 February 2015 at 19:32:08 UTC, Gan wrote:
On Tuesday, 24 February 2015 at 16:28:59 UTC, Namespace
wrote:
I had to force dub to upgrade in order for it to pull
the latest code from the master branch.
But on the plus side it runs.
On the downside it still only displays a blank white
screen for Mac users.
As growlercab pointed out
(https://github.com/Dgame/Dgame/pull/29), I think also
that you should set the Version to 3.2 rather than 3.0.
Could you give it a try and say if that works for you?
No dice. Running the shapes tutorial again, just a blank
screen. Console output looks good though:
init openAL
Derelict loaded GL version: GL33 (GL33), available GL
version: 3.3 INTEL-10.0.22
Quit Event
Finalize Sound (0)
>> Sound Finalized
Text: Finalize Font
Font finalized
Close open Windows.
Open Windows closed.
Finalize Texture (0)
>> Texture Finalized
quit sdl
Did you try commenting out the line that sets the forward
compatibility flag as well?
(sorry it isn't clear from the posts)
if (style & Style.OpenGL) {
SDL_GL_SetAttribute(SDL_GL_CONTEXT_MAJOR_VERSION, 3);
SDL_GL_SetAttribute(SDL_GL_CONTEXT_MINOR_VERSION, 3);
SDL_GL_SetAttribute(SDL_GL_CONTEXT_PROFILE_MASK,
SDL_GL_CONTEXT_PROFILE_CORE);
/*
* SDL_GL_SetAttribute(SDL_GL_CONTEXT_FLAGS,
* SDL_GL_CONTEXT_FORWARD_COMPATIBLE_FLAG);
*/
}
This fixed a similar issue for me on Linux.
Cheers,
stew
Yeah I did that, doesn't show anything but a blank white
screen.
OK, thanks for letting me know.
Is there anything more I can test to try to get it working on
Mac?
Also anyone else have a Mac to test on? I wanna make sure it's
not just me getting the blank white screen.
Without a MAC I am just guessing, but my next steps would be
along the lines of:
1. The venerable printf binary search bug hunt approach :)
Check glGetError, which you can turn the error into a string
with GLU as follows:
---
void reportGLErrors() {
GLenum errCode;
const GLubyte *errString;
if ((errCode = glGetError()) != GL_NO_ERROR)
{
errString = gluErrorString(errCode);
writeln(errString.fromStringz)
}
// UNTESTED!!
}
---
This module should work as a standalone with a few tiny import
changes:
https://github.com/Dav1dde/glamour/blob/master/glamour/util.d
The interesting bit is checkgl, used for example like this:
checkgl!glDrawArrays(GL_POINTS, 0, 10);
then you get a nice debug message if glDrawArrays reports an
error. It will also report if a previous error has occurred and
wasn't cleared, but of course in that case it won't be able to
tell you where.
I wrap every OpenGL call with checkgl, it helps immensely.
Re: Dgame revived
On Thursday, 26 February 2015 at 22:27:12 UTC, Namespace wrote: On Thursday, 26 February 2015 at 22:09:33 UTC, stewarth wrote: On Thursday, 26 February 2015 at 20:43:20 UTC, Namespace wrote: I've just pushed the current state of the 0.5.0 version: https://github.com/Dgame/Dgame/tree/0.5.0 It's far from finished but it works. So if anyone has requests, wishes or suggestions: now is the time. :) That's great :) At the moment my small test apps don't build due to missing features such as Audio, System.Clock etc. I assume these will be added as work progresses? No, only the tests in test/main.d are working currently. But it's possible, that Dgame 0.5.0 will break some things. E.g. The static make methods in Shape and Surface were converted into CTor calls and I guess that I will abandon Image and TileMap. Next step is Font, Text and Spritesheet. Then I'll inspect Clock, Power and MessageBox and in the end I'll inspect Audio. I think the most breaking changes will happen here, because I'll use this time SDL_Audio instead of OpenAL. I'll do some testing over the weekend with what's in place on the 0.5.0 branch and submit bug reports if I find anything. Cheers, Stew Thanks, that would be great! Hey, I'm using tilemap :P I guess a separate project for tilemaps built on Dgame would be cool. I might look into this during the semester break. One thing that would be cool is some sort of support for 2D physics. It's probably outside Dgame scope but as a separate project that keeps a consistent API with Dgame would be nice. Kind of like the way SDL, SDL_image, SDL_ttf all do. Cool, two new projects for me to look into when I should be studying :) Thanks, amber
