Re: [ANN] 3T Software Labs MongoDB tools for D programmers.
On Thursday, 17 April 2014 at 15:50:04 UTC, Graham Fawcett wrote: To clarify: you've built these tools in D? Or do the tools provide some kind of D API to MongoDB? Best, Graham Fawcett (not the 3T software Graham; last names are helpful!) They've posted this same thing to a number of different mailing lists in last day or so. Looks valid code however hence I didn't say anything earlier.
Re: Unencumbered V0.1.2: Write Cucumber step definitions in D
On Friday, 25 April 2014 at 08:52:18 UTC, Atila Neves wrote:
On Friday, 25 April 2014 at 08:45:20 UTC, Atila Neves wrote:
On Thursday, 24 April 2014 at 18:53:22 UTC, Jacob Carlborg
wrote:
On 2014-04-23 15:24, Atila Neves wrote:
Like testing with Cucumber? Wish you could call native D
code with it?
Now you can!
http://code.dlang.org/packages/unencumbered
https://github.com/atilaneves/unencumbered
I especially like registering functions that take the
parameters with
the types they need from the regexp captures, as well as the
compile-time failures that come from that if done
incorrectly.
Now I just need to use in real life.
BTW, why is the description passed as a template argument to
the Cucumber keywords. @Given!(foo) instead of
@Given(foo)?
Ehm... because until now I didn't know that @Given(foo) was
possible. In my head I was doing compile-time stuff so
everything had to be compile-time, if that makes any sense.
After I read the above I wasn't even sure how @Given(foo)
would work so I wrote some code and now know that all I need
is a struct with a regular string field. I think the
documenation on http://dlang.org/attribute.html is severely
lacking.
I think I have some refactoring to do now. Thanks for pointing
this out!
Atila
Hmm. So for the string argument is fine, unfortunately I also
need to know the line number of the step definition, and that
doesn't work:
struct Given {
this(string s, ulong l = __LINE__) {
this.s = s;
this.l = l;
}
string s;
ulong l;
}
@Given(foobar)
auto func() pure nothrow @safe {
}
void main() {
foreach(attr; __traits(getAttributes, func)) {
pragma(msg, s is , __traits(getMember, attr, l));
}
}
I get:
s is attr_str.d(21): Error: variable attr cannot be read at
compile time
attr_str.d(21):while evaluating pragma(msg,
__traits(getMember, attr, l))
struct Given {
this(ulong l = __LINE__)(string s) {
this.s = s;
this.l = l;
}
string s;
ulong l;
}
@Given(foobar)
auto func() pure nothrow @safe {
}
void main() {
pragma(msg, s is , getGivenL!func);
}
pure ulong getGivenL(alias symbol)() {
foreach(attr; __traits(getAttributes, func)) {
static if (is(typeof(attr) == Given)) {
return attr.l;
}
}
assert(0);
}
Basically move the checking of UDA's to specialist functions
that are reusable.
Also when using things like __LINE__ keep them to template args,
as they are inferred to the initiation if possible.
Re: Unencumbered V0.1.2: Write Cucumber step definitions in D
On Friday, 25 April 2014 at 10:02:45 UTC, Dicebot wrote: On Friday, 25 April 2014 at 09:45:06 UTC, Rikki Cattermole wrote: Also when using things like __LINE__ keep them to template args, as they are inferred to the initiation if possible. This is antipattern. Default function arguments for __LINE__ and __FILE__ are also evaluated at call site. Moving this to template parameter creates huge amount of template bloat and must be used only if there is no other way around (that usually implies variadic arguments) True in this specific case it might be over the top.
Re: New libraries wave-d and y4m-d
On Tuesday, 29 April 2014 at 18:48:33 UTC, ponce wrote: There was a typo error: https://github.com/p0nce/y4m-d On Tuesday, 29 April 2014 at 18:46:51 UTC, ponce wrote: y4m-d is a library for reading and writing Y4M files. https://github.com/p0nce/wave-d I checked out y4m-d when it went up on the dub repository. Looks interesting. I do have to ask, are you interested in creating a unified library for multimedia with a importers/exporters a bit like ASIMPP? Because I think that could be rather useful and not too much work on top of the given types already had.
Re: Livestreaming DConf?
On 10/05/2014 7:48 a.m., Andrei Alexandrescu wrote: Hi folks, We at Facebook are very excited about the upcoming DConf 2014. In fact, so excited we're considering livestreaming the event for the benefit of the many of us who can't make it to Menlo Park, CA. Livestreaming entails additional costs so we're trying to assess the size of the online audience. Please follow up here and on twitter: https://twitter.com/D_Programming/status/464854296001933312 Thanks, Andrei Definitely would if I'm available to watch!
Re: OpenGL Examples in D and a birth of a New Initiative
On 15/05/2014 5:01 p.m., Manu via Digitalmars-d-announce wrote: I tried to gather support for a community game project (FeedBack). Lots of interest, but nobody actually joined the party when I kicked it off. On 15 May 2014 05:04, Andrej Mitrovic via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: I am starting an initiative for everyone interested in D game development by creating the github organization d-gamedev-team[1]. The first project hosted here is the the freshly created opengl-tutorials[2] project. This is a long-term project that aims to collect as many modern OpenGL examples ported to D or even provide new examples created from scratch in D. All the examples should be easy to build, provided you have a fresh D compiler and a recent version of the dub[3] dependency manager / builder tool. Currently the project contains an almost-complete port of the samples contained on the website opengl-tutorial.org[4] - which cover OpenGL v3.3x and were created by Sam Hocevar. The D examples are not straight ports, they have been D-ified and may contain more features than their original counterparts. They also use 3rd-party D OpenGL wrappers to avoid a lot of scaffolding work typical of OpenGL applications. Thanks to dub[3] you won't have to manually install the D dependencies. However you may have to install some C/C++ 3rd-party library dependencies, such as GLFW, SDL2, SDL2 Image, and potentially other libraries depending on the ones the samples require. The dependencies are documented in the project's readme[5]. Additional OpenGL example ports are planned and some are already in progress but have not yet been pushed upstream. See the opengl-tutorials[2] github repo for a list of ports which are in progress and a list of desired ports. If you wish to contribute with your own ports or with brand new D OpenGL examples don't hesitate to make a pull request. I want the d-gamedev-team organization to gradually grow and have it host as many useful projects, whether it be libraries, tools, tutorials, tips tricks, assets, or anything else related to D game development. I am strongly interested in game development in D, and although I'm at a starting stage I'm very much committed to working on this project to the best of my abilities. Hopefully in a few years we'll see some major titles made entirely in D. But before that can happen we have to make a collective push to bring D to a higher stage where it's acceptable and viable to game developers, whether it be through language support (@nogc/allocators) or library and tooling support. We'll see where this goes, but I'm very excited for the future! Cheers. :o) [1] : https://github.com/d-gamedev-team [2] : https://github.com/d-gamedev-team/opengl-tutorials [3] : http://code.dlang.org/download [4] : http://opengl-tutorial.org/ [5] : https://github.com/d-gamedev-team/opengl-tutorials/tree/master/ports/opengl-tutorial.org Yeah I was one of those people who wanted to work on it. Unfortunately that was while I was working on DOOGLE and pre aurora commencing. That to me really killed my enthusiasm. Personally I'm waiting for aurora before starting up on the GUI front.
Re: OpenGL Examples in D and a birth of a New Initiative
On 16/05/2014 12:07 a.m., Manu via Digitalmars-d-announce wrote: On 15 May 2014 16:30, Rikki Cattermole via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On 15/05/2014 5:01 p.m., Manu via Digitalmars-d-announce wrote: I tried to gather support for a community game project (FeedBack). Lots of interest, but nobody actually joined the party when I kicked it off. Yeah I was one of those people who wanted to work on it. Unfortunately that was while I was working on DOOGLE and pre aurora commencing. That to me really killed my enthusiasm. Personally I'm waiting for aurora before starting up on the GUI front. What's doogle and aurora? And why did that kill enthusiasm? DOOGLE[0] was my attempt at a gui toolkit. And aurora is this[1]. I would have replied earlier but it appears that there has been enough changes with dub and dmd that it just won't. But I managed to grab an old build and here is its output [2]. Not really that nice but hey, was my go at it. I was building it as pretty much the all in one toolbox for D and OpenGL and with Aurora getting more support, the issues I was having continuing just kinda was the last straw. And anyways I'm better at web development then game dev. Never really understood the 3d pipeline. [0] https://github.com/rikkimax/DOOGLE [1] https://github.com/auroragraphics [2] https://drive.google.com/file/d/0B-EiBquZktsLcGtMSmtMS1ZoZHM/edit?usp=sharing
Re: OpenGL Examples in D and a birth of a New Initiative
On 16/05/2014 1:38 a.m., Manu via Digitalmars-d-announce wrote: On 15 May 2014 23:24, Rikki Cattermole via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On 16/05/2014 12:07 a.m., Manu via Digitalmars-d-announce wrote: On 15 May 2014 16:30, Rikki Cattermole via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On 15/05/2014 5:01 p.m., Manu via Digitalmars-d-announce wrote: I tried to gather support for a community game project (FeedBack). Lots of interest, but nobody actually joined the party when I kicked it off. Yeah I was one of those people who wanted to work on it. Unfortunately that was while I was working on DOOGLE and pre aurora commencing. That to me really killed my enthusiasm. Personally I'm waiting for aurora before starting up on the GUI front. What's doogle and aurora? And why did that kill enthusiasm? DOOGLE[0] was my attempt at a gui toolkit. And aurora is this[1]. I would have replied earlier but it appears that there has been enough changes with dub and dmd that it just won't. But I managed to grab an old build and here is its output [2]. Not really that nice but hey, was my go at it. I was building it as pretty much the all in one toolbox for D and OpenGL and with Aurora getting more support, the issues I was having continuing just kinda was the last straw. And anyways I'm better at web development then game dev. Never really understood the 3d pipeline. Those aurora repos appear to be empty :/ Is aurora intended to be a GUI toolkit? Only DirectX has code so far from what I've heard and seen. I still think there's huge need for a realtime gfx environment GUI toolkit. I'm completely on board with that, but I really don't have the skills for it. But hey we also need a web service framework aimed at enterprise in D and that's my target work now days. But if I were you, I wouldn't be marrying it to any particular gfx API. Just make sure to structure the API to allow backends (like OpenGL) to be plugged in. It was designed to be completely independent of any 3d api. In theory you could have a different implementation of controls to a window. But I never bothered going there considering. In fact I had plans to make it like GWT does as another backend and hooking it up to Vibe. [0] https://github.com/rikkimax/DOOGLE [1] https://github.com/auroragraphics [2] https://drive.google.com/file/d/0B-EiBquZktsLcGtMSmtMS1ZoZHM/edit?usp=sharing
Re: OpenGL Examples in D and a birth of a New Initiative
On Thursday, 15 May 2014 at 14:55:46 UTC, Adil Baig via Digitalmars-d-announce wrote: On Thu, May 15, 2014 at 7:22 PM, Rikki Cattermole via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On 16/05/2014 1:38 a.m., Manu via Digitalmars-d-announce wrote: On 15 May 2014 23:24, Rikki Cattermole via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On 16/05/2014 12:07 a.m., Manu via Digitalmars-d-announce wrote: On 15 May 2014 16:30, Rikki Cattermole via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On 15/05/2014 5:01 p.m., Manu via Digitalmars-d-announce wrote: I tried to gather support for a community game project (FeedBack). Lots of interest, but nobody actually joined the party when I kicked it off. Yeah I was one of those people who wanted to work on it. Unfortunately that was while I was working on DOOGLE and pre aurora commencing. That to me really killed my enthusiasm. Personally I'm waiting for aurora before starting up on the GUI front. What's doogle and aurora? And why did that kill enthusiasm? DOOGLE[0] was my attempt at a gui toolkit. And aurora is this[1]. I would have replied earlier but it appears that there has been enough changes with dub and dmd that it just won't. But I managed to grab an old build and here is its output [2]. Not really that nice but hey, was my go at it. I was building it as pretty much the all in one toolbox for D and OpenGL and with Aurora getting more support, the issues I was having continuing just kinda was the last straw. And anyways I'm better at web development then game dev. Never really understood the 3d pipeline. Those aurora repos appear to be empty :/ Is aurora intended to be a GUI toolkit? Only DirectX has code so far from what I've heard and seen. I still think there's huge need for a realtime gfx environment GUI toolkit. I'm completely on board with that, but I really don't have the skills for it. But hey we also need a web service framework aimed at enterprise in D and that's my target work now days. Interesting. What are you working on? Is it on github? It is indeed and on dub repository. https://github.com/rikkimax/Cmsed https://github.com/rikkimax/Dvorm
Re: 10 Years of Derelict
On 16/05/2014 3:02 a.m., Mike Parker wrote: I managed to let this little anniversary slip by me. My first post in the old Derelict forum at DSource[1] is dated May 6, 2004, my initial commit to svn[2] was May 7, and my announcement in the newsgroup[3] was on May 8. My attention to the project has waxed and waned, but I'm still puttering along. I expect to continue for the forseeable future. There have been a number of contributors over the years who have helped out in porting to Linux and Mac, fixing bugs, and keeping the bindings up to date. It's been very much a community project, which has made it more enjoyable to work on. It helps that it isn't difficult to maintain :) Maybe before the next decade goes by I'll actually finish a game in D, which is the reason I started Derelict in the first place. For those who don't know, the current iteration of Derelict can be found at the DerelictOrg group at github[4]. I've still got work to do on it (ahem, documentation), but it's coming along. [1] http://www.dsource.org/forums/viewtopic.php?t=105 [2] http://www.dsource.org/projects/derelict/changeset/5/ [3] http://forum.dlang.org/thread/c7hl51$2k4u$1...@digitaldaemon.com [4] https://github.com/DerelictOrg I also have to say good job on your work on it! I definitely value it, even if I don't use it much.
Duml: Uml diagram generation
Alright so a little project I've put together[0]. Not entirely complete yet. But I feel its at a point where it can be announced. What it does is given a class it'll generate the PlantUML[1] descriptors for it. If asked it can call PlantUML itself to generate the image version of it. My plan is to integrate it into Cmsed at some point when it supports structs (dvorm models). At which point it'll document properly routes, models and any you manually specify. Object class can be ignored by adding a version if you want it to be. [0] https://github.com/rikkimax/Duml [1] http://plantuml.sourceforge.net/
Re: Duml: Uml diagram generation
On 17/05/2014 8:53 p.m., w0rp wrote: That's pretty cool. I think I would change outputPlantUML so it works in terms of something which outputs to an OutputRange or File. So you can dump the UML directly to the file. I've added that as a TODO.
Re: OpenGL Examples in D and a birth of a New Initiative
On Sunday, 18 May 2014 at 21:22:25 UTC, Casey wrote: But hey we also need a web service framework aimed at enterprise in D and that's my target work now days. Just out of curiosity, have you looked into Vibe.d for this? I've created a couple prototypes with it and they came out pretty good. Sonke is also pretty good about responding to issues as you find them. Just so happens my web service framework Cmsed is built using it. No, its not what I am meaning. Its far too low level, its essentially a web server. What's needed is a higher level view of web services and how they work.
Re: Dash: An Open Source Game Engine in D
On 20/05/2014 7:50 a.m., Colden Cullen wrote: Hi everyone, I’m super excited to be able to announce that the Dash game engine[1] is finally stable and ready for public use! I’m currently the Lead Engine Programmer at Circular Studios[2] (the group behind Dash). We had 14 people working on the team, 6 engine programmers and 8 game developers creating Spectral Robot Task Force, a turn-based strategy game built with Dash. Dash is an OpenGL engine written in the D language that runs on both Windows and Linux. We use a deferred-rendering model in the current pipeline, and a component model for game development and logic. Other major features at the moment include networking, skeletal-animation support, content and configuration loading via YAML, and UI support through Awesomium[3] (though we are in the process of moving over to using CEF[4] itself). Our vision for Dash is to have the programmer-facing model of XNA/Monogame combined with the designer-friendliness of Unity in a fully free and open source engine. We also hope that Dash can help to prove the power and maturity of D as a language, as well as push D to continue improving. We’re open to any feedback you may have, or better yet, we’d love to see pull requests for improvements. [1] https://github.com/Circular-Studios/Dash [2] http://circularstudios.com/ [3] http://awesomium.com/ [4] https://code.google.com/p/chromiumembedded/ Awesome to see! Will be looking forward to what ever you guys get up to. Only thing I can suggest, is get UML diagrams ext. Up on docs.
Re: Dash: An Open Source Game Engine in D
On 20/05/2014 2:21 p.m., Colden Cullen wrote: On Tuesday, 20 May 2014 at 01:12:38 UTC, Rikki Cattermole wrote: Awesome to see! Will be looking forward to what ever you guys get up to. Only thing I can suggest, is get UML diagrams ext. Up on docs. Says the author of Duml :) It's definitely something I want to do, I just haven't gotten the chance yet. Selfish promotion ;) But yes, for this type of thing it definitely does give confidence to new users that they can see this type of thing. And hey, when its practically free(work wise) why not?
Re: Duml: Uml diagram generation
On 17/05/2014 6:34 p.m., Rikki Cattermole wrote: Alright so a little project I've put together[0]. Not entirely complete yet. But I feel its at a point where it can be announced. What it does is given a class it'll generate the PlantUML[1] descriptors for it. If asked it can call PlantUML itself to generate the image version of it. My plan is to integrate it into Cmsed at some point when it supports structs (dvorm models). At which point it'll document properly routes, models and any you manually specify. Object class can be ignored by adding a version if you want it to be. [0] https://github.com/rikkimax/Duml [1] http://plantuml.sourceforge.net/ Just pushed another version. Wouldn't normally mention this except for the fact that I've got it hooked up and exported out a uml diagram[0] of object module from drumtime. Its nearly 6000 pixels wide, so a bit big ;) [0] https://github.com/rikkimax/Duml/wiki/images/output_v0.2.0_object.png
Dakka: Actors for D
Alright so, I've just finished Dakka's[0] exception support. Functionality supported: Local actor references Remote node connections, using given ip/port Remote actor calling On start/stop/error support Capabilities per node (can this node do x? if not which can do to create a reference?) Seemless integration of both actor references to actors Singleton (controller classes) actor support per node, works with AllActorRefs for calling them e.g. sequentially, or until a return value. At this point, I'm entering it into maintenance. What this means is I cannot myself expand on its functionality e.g. adding encryption. However if anybody wants to, please do. This is what I need, I've tried to make it as flexible as possible and inline with how akka works, but as I'm not the most adapt in it. Please feel free on drawing up a wanted feature list. There will be issues with threading, so if anyone is more skilled at it and understands Vibe's workers feel free pointing that out. For anybody interested, the code itself isn't well documented (I'll get back to it when I have time). But the actual overall design should be fairly documented. The protocol[2] and life cycle[3] can be found on the wiki[1]. [0] https://github.com/rikkimax/dakka [1] https://github.com/rikkimax/dakka/wiki [2] https://github.com/rikkimax/dakka/wiki/Protocol [3] https://github.com/rikkimax/dakka/wiki/LifeCycleOfObjects
Skeletal generator
In advancing to a reload system for Cmsed, I've built a directory skeleton generator[0]. It supports both lua and a simpler text file syntax. An example of this is: # Simple skeleton descriptor dlfile livereload.txt livereload.txt mkdir bin mkdir deps dlfile deps/package.json package.json mkdir dynamic/config mkdir dynamic/models mkdir dynamic/public mkdir dynamic/routes mkdir dynamic/templates mkdir dynamic/caches mkdir static/config mkdir static/models mkdir static/public mkdir static/routes mkdir static/templates mkdir static/caches You can basically do everything you need with the simpler syntax except for conditional and input gathering or manipulation. Regex(find/replace) on files based upon the cli args is possible however. I will be using a variation of this for Cmsed. With regards to lua support, I've hooked up lua's require module system into the providers (github/bitbucket), so it is possible to require any file from a repository and use it as a required module. I've also bound std.file and std.stdio into lua. So it should be possible to do almost anything you need if lua cannot do it natively. [0] https://github.com/rikkimax/skeleton
Recompiling D code
Hello everyone. As you all may know I've been working on recompiling D for web services last few weeks. Its both good news and bad news. Good: Reloading definitely possible. With dependency handling using dub. Bad: Its slow. And not in my code sort of way. You're welcome to atest my speeds that I have gotten so far (older well used hdd, Win7 x64), its around 2-3 seconds for a basic go download webpage and not much more. I've done a bit of working with it and with 2.066-rc2 got it to the lower end of 2s. Atleast from my experience with this, its dmd thats actually taking the time. I know my code isn't the best and optimized, so I have compared mine against dmd itself. 100-200ms difference normally. For those who don't know why I'm making a fuss over 2 seconds, its because you actually do notice this when doing web dev stuff. Without including start up time, this could become a lot larger. [0] https://github.com/rikkimax/livereload
Re: Recompiling D code
On 15/08/2014 12:47 a.m., Vladimir Panteleev wrote: On Thursday, 14 August 2014 at 11:54:57 UTC, Rikki Cattermole wrote: Atleast from my experience with this, its dmd thats actually taking the time. I can't glean this from looking at the code, but are you recompiling the entire program? Web development is a perfect fit for incremental compilation, so when changing one web page's template or view code, you should need to compile only one .d file. ld and gold seem to support incremental linking, that could help speed things up as well. Dub automatically handles caching of dependencies such as vibe-d. So they are not rebuilt. The only things that get recompiled for example is a single code unit. This is defined as being the dependency between a route file and template files (simplified). The necessary dependencies such as vibe-d then should be added as part of the build process. Incremental builds of things such as routes and templates are not a good idea. Same goes for data models. It could change the code unit output a little too much. Possibly even cause a corrupt binary from missing symbols ext. But in this case none of this matters much. Pretty much I'm only testing against a single route module. No dependencies outside phobos and vibe-d.
Re: Recompiling D code
On 15/08/2014 3:09 a.m., Justin Whear wrote: On Thu, 14 Aug 2014 14:58:20 +, John Colvin wrote: My experience with these sort of things suggests that it'll be the linker taking the time. Dynamic libraries are the solution. Dub needs proper support for dynamic library dependencies. I'll second that suggestion. Can you run the timings using -c? Obviously you won't get binaries out the end, but it'd help diagnose the problem. Yes its definitely a lot faster. Around 600ms - 800ms. Even with other applications running.
Re: Recompiling D code
On 15/08/2014 2:58 a.m., Vladimir Panteleev wrote: On Thursday, 14 August 2014 at 12:56:10 UTC, Rikki Cattermole wrote: Dub automatically handles caching of dependencies such as vibe-d. So they are not rebuilt. The only things that get recompiled for example is a single code unit. This is defined as being the dependency between a route file and template files (simplified). How many D modules / object files is that? I haven't gone into that, I don't really want to go around modifying dub if I can help it. The necessary dependencies such as vibe-d then should be added as part of the build process. Incremental builds of things such as routes and templates are not a good idea. Same goes for data models. It could change the code unit output a little too much. Possibly even cause a corrupt binary from missing symbols ext. That approach sounds much more high-level than what I meant, and I don't see why you'd need to abstract things to that level. I'm not familiar with how dub builds things, but inter-module dependencies are a solved problem, thanks to DMD's -v and -deps switches. Incremental compilation was implemented in older (D1-era) build tools, such as xfbuild, however has never picked up due to DMD bugs with incrementally compiling more than one object file at a time (which might very well be fixed by now).
Re: Recompiling D code
On 15/08/2014 6:06 a.m., Jacob Carlborg wrote: On 2014-08-14 13:54, Rikki Cattermole wrote: Hello everyone. As you all may know I've been working on recompiling D for web services last few weeks. Its both good news and bad news. Good: Reloading definitely possible. With dependency handling using dub. Bad: Its slow. And not in my code sort of way. Has anyone thought of trying to JIT using LDC. Supposedly the llvm is slower for generation then dmd's backend. Atleast what was said during the SDC DCONF talk. But I'm all for this, could also use it to cache code that is generated ext. in memory. Less usage on the hdd can only be a good thing. I'll leave this to somebody who does know this area of things.
Re: Recompiling D code
On 16/08/2014 11:29 a.m., Vladimir Panteleev wrote: On Friday, 15 August 2014 at 06:54:28 UTC, Rikki Cattermole wrote: On 15/08/2014 2:58 a.m., Vladimir Panteleev wrote: How many D modules / object files is that? I haven't gone into that, I don't really want to go around modifying dub if I can help it. Well, to be blunt, I doubt you'll get satisfactory results unless you're ready to get down to the nitty-gritty. Unfortunately I agree with you. But from what I've heard this isn't bad results considering native language and all. I may work towards using something like parrotVM or lua. Could be interesting for dev vs production. Don't see why I can't get that working rather well.
Re: COFF support for Win32 merged
On 17/08/2014 9:57 p.m., Jacob Carlborg wrote: I though that this might be important enough to share on the announce list: A pull request [1] by Rainer Schuetze which adds COFF support for Win32 has recently been merged by Walter. It seems to be enabled using the -m32mscoff flag. [1] https://github.com/D-Programming-Language/dmd/pull/3843 Well this makes me happy :3 Thank you Rainer!
Re: Multiple alias this is coming.
On 18/09/2014 11:20 p.m., IgorStepanov wrote: I've created pull request, which introduces multiple alias this. https://github.com/D-Programming-Language/dmd/pull/3998 Please see the additional tests and comment it. Awesome was waiting for something like this! Also did we ever consider alias this = ...; syntax?
Re: Digger 1.0
On Sunday, 21 September 2014 at 17:43:14 UTC, Rainer Schuetze wrote: How about running the test suite? +1 Would make me far more happier of starting seriously getting into dmd bug fixing.
Re: Walter and I are on at FLOSS weekly
On Wednesday, 8 October 2014 at 21:01:27 UTC, Andrei Alexandrescu wrote: Recorded this morning. Enjoy! http://twit.tv/show/floss-weekly/311 Andrei I'm currently up to the part where its mentioned about TAP testing protocol [0]. Based upon my quick glance over at druntime [1]. I think we could implement it fairly easily. This should be a fairly easy win for anyone who wants to give it a go. [0] http://testanything.org/tap-specification.html [1] https://github.com/D-Programming-Language/druntime/blob/master/src/test_runner.d
Re: dmedia library
On 7/11/2014 6:56 p.m., luminousone wrote: I have been working on a media library, it still has a long way to go, but I figured its about time I shared what I am doing. https://github.com/luminousone/dmedia If I could possibly convince a few people out their to give'er a once over. I use XCB/XLIB/GLX directly, so I am not just simply wrapping SDL or SFML. And I am using XCB for event handling and opening windows. Threading should work much more reliably, due to the use of XCB. I am releasing the library under the BSD license, Its a good start. But instead of creating the window itself manually would you consider using DWC [0]? DWC is more or less done. But I need help with my plans for a game dev framework in D. If you're interested in helping with that please give me an email fi...@lastname.co.nz [0] https://github.com/rikkimax/DWC
Re: dmedia library
On 7/11/2014 7:38 p.m., luminousone wrote: On Friday, 7 November 2014 at 06:29:14 UTC, Rikki Cattermole wrote: On 7/11/2014 6:56 p.m., luminousone wrote: I have been working on a media library, it still has a long way to go, but I figured its about time I shared what I am doing. https://github.com/luminousone/dmedia If I could possibly convince a few people out their to give'er a once over. I use XCB/XLIB/GLX directly, so I am not just simply wrapping SDL or SFML. And I am using XCB for event handling and opening windows. Threading should work much more reliably, due to the use of XCB. I am releasing the library under the BSD license, Its a good start. But instead of creating the window itself manually would you consider using DWC [0]? DWC is more or less done. But I need help with my plans for a game dev framework in D. If you're interested in helping with that please give me an email fi...@lastname.co.nz [0] https://github.com/rikkimax/DWC XLIB is an absolute train wreck when it comes to threading, call XPollEvent outside your draw thread will most likely segfault. As well I need control of the opengl contexts, as I want to separate drawing and loading into separate threads. I need both good threading support, and control over my opengl contexts to fulfill the goals I have set for myself. That said, it is a nice looking library. But it would not fulfill my needs. Fair enough. Threading is a major issue with those low level api's.
Re: dmedia library
On 7/11/2014 7:58 p.m., luminousone wrote: On Friday, 7 November 2014 at 06:42:24 UTC, Rikki Cattermole wrote: On 7/11/2014 7:38 p.m., luminousone wrote: On Friday, 7 November 2014 at 06:29:14 UTC, Rikki Cattermole wrote: On 7/11/2014 6:56 p.m., luminousone wrote: I have been working on a media library, it still has a long way to go, but I figured its about time I shared what I am doing. https://github.com/luminousone/dmedia If I could possibly convince a few people out their to give'er a once over. I use XCB/XLIB/GLX directly, so I am not just simply wrapping SDL or SFML. And I am using XCB for event handling and opening windows. Threading should work much more reliably, due to the use of XCB. I am releasing the library under the BSD license, Its a good start. But instead of creating the window itself manually would you consider using DWC [0]? DWC is more or less done. But I need help with my plans for a game dev framework in D. If you're interested in helping with that please give me an email fi...@lastname.co.nz [0] https://github.com/rikkimax/DWC XLIB is an absolute train wreck when it comes to threading, call XPollEvent outside your draw thread will most likely segfault. As well I need control of the opengl contexts, as I want to separate drawing and loading into separate threads. I need both good threading support, and control over my opengl contexts to fulfill the goals I have set for myself. That said, it is a nice looking library. But it would not fulfill my needs. Fair enough. Threading is a major issue with those low level api's. I eventually want to build a entity system, and make use of parallel_foreach, or fibers/routines, and have a loading thread that can get assets in an async fashion. Large voxel/cube-voxel systems and mega texturing interest me, I feel like a small team could develop a big game with tools built around a voxel system. XCB mostly solves the threading issues that XLIB suffers from, However XCB has poor support for the input extensions, as of yet nothing that replaces xlookupstring, I hope to find a good work around at some point, but it seems good enough for my needs. Also I am not sure of how well XXf86vm extension is supported for full screen access, As I have yet to implement full screen windows. Its a learning experience, however so I can't complain to much! Interesting, just out of interest have you thought about separating it out and work independently of GUI's for e.g. game servers? Or would that abstract it to the point of non-usefulness?
Re: dmedia library
On 7/11/2014 8:22 p.m., luminousone wrote: On Friday, 7 November 2014 at 07:08:02 UTC, Rikki Cattermole wrote: On 7/11/2014 7:58 p.m., luminousone wrote: On Friday, 7 November 2014 at 06:42:24 UTC, Rikki Cattermole wrote: On 7/11/2014 7:38 p.m., luminousone wrote: On Friday, 7 November 2014 at 06:29:14 UTC, Rikki Cattermole wrote: On 7/11/2014 6:56 p.m., luminousone wrote: I have been working on a media library, it still has a long way to go, but I figured its about time I shared what I am doing. https://github.com/luminousone/dmedia If I could possibly convince a few people out their to give'er a once over. I use XCB/XLIB/GLX directly, so I am not just simply wrapping SDL or SFML. And I am using XCB for event handling and opening windows. Threading should work much more reliably, due to the use of XCB. I am releasing the library under the BSD license, Its a good start. But instead of creating the window itself manually would you consider using DWC [0]? DWC is more or less done. But I need help with my plans for a game dev framework in D. If you're interested in helping with that please give me an email fi...@lastname.co.nz [0] https://github.com/rikkimax/DWC XLIB is an absolute train wreck when it comes to threading, call XPollEvent outside your draw thread will most likely segfault. As well I need control of the opengl contexts, as I want to separate drawing and loading into separate threads. I need both good threading support, and control over my opengl contexts to fulfill the goals I have set for myself. That said, it is a nice looking library. But it would not fulfill my needs. Fair enough. Threading is a major issue with those low level api's. I eventually want to build a entity system, and make use of parallel_foreach, or fibers/routines, and have a loading thread that can get assets in an async fashion. Large voxel/cube-voxel systems and mega texturing interest me, I feel like a small team could develop a big game with tools built around a voxel system. XCB mostly solves the threading issues that XLIB suffers from, However XCB has poor support for the input extensions, as of yet nothing that replaces xlookupstring, I hope to find a good work around at some point, but it seems good enough for my needs. Also I am not sure of how well XXf86vm extension is supported for full screen access, As I have yet to implement full screen windows. Its a learning experience, however so I can't complain to much! Interesting, just out of interest have you thought about separating it out and work independently of GUI's for e.g. game servers? Or would that abstract it to the point of non-usefulness? Yes, tho I have yet to put much thought into how that will all be put together. Working towards something that I could use in vibe.d, without any dependence on the windowing system would be important for a good gameserver. Depending on the needs of the game server, I would keep it apart from the web server aspect from vibe.d all together. By in large interacting with e.g. a task, shouldn't be hard but that's not quite why. The idea behind my actor framework Dakka [0] (although would need a bit of work for this sort of thing). Share the data (including data models) between the web server and game server over sockets with method calling support. But keep its functions separate. Although the original context was all about having front end nodes for web development and backend nodes for interacting with e.g. VM's. But that's just me rambling with not much reason. [0] https://github.com/rikkimax/dakka
Devisualization and DWC
Right, time for a new announcement from me. First off the library I have been talking about called DWC has been renamed. It is now Under the banner of Devisualization, window[0] project. Devisualization.window otherwise known as de_window is a window and context creation for Windows, Linux and Mac OSX. It does need a good bit of testing especially on Linux. In short, the goal of Devisualization Github organization is to promote game development and the libraries to facilitate it in D. Projects I want made: - Events/controls abstraction + GUI controls - Native GUI controls (such as the menu for OSX) - Virtual File System - OpenGL wrappers and tooling - Image loading/exporting (currently working on png) - 3d model loading/exporting (.3ds .obj at the minimum) - Scenegraph - Audio loading/exporting - Unity like interface - Scripting - Entity modeling Not in any particular order and can very easily be added to. I'm sure there is a lot of code already available that can do some of these things, but to make it all work together nicely would be a challenge. I did write up on my blog about all this [1], but you don't need to read it. It just goes into a bit more depth. About Cmsed and my web dev stuff, I haven't stopped working on it per-say. I'm waiting on e.g. [2]. [0] https://github.com/Devisualization/window [1] http://blog.alphaglosined.tk/2014/11/window-creation-d-initiative.html [2] https://github.com/D-Programming-Language/dmd/pull/3921
Re: Devisualization and DWC
On 8/11/2014 12:46 a.m., ponce wrote: Nice work, it's basically the SDL replacement I wished for! I like that its scope is well defined. I don't get why it depends on DerelictGL. AFAIK SDL, GLFW and friends do not depend on GL function loaders. It depends because of OpenGL context creation. And it requires a reload to work properly when activating. Might be better as an optional dependency.
Re: Devisualization and DWC
On 8/11/2014 12:48 a.m., Kagamin wrote: On Friday, 7 November 2014 at 10:48:46 UTC, Rikki Cattermole wrote: - Native GUI controls (such as the menu for OSX) D native or OS native? Short answer: Basically it should use the native implementation if possible otherwise it should use the non native version. Long answer: I'll use the example of OSX with the menu. OSX has a specialized menu as part of its UI which all applications are meant to use. On this case it should use this. But on a platform such as Windows, if there is no context it can freely use the native menu system. But if it has a context it should emulate it via e.g. OpenGL like it wasn't native. Then of course is X11 which case it would be OpenGL as their is no native version of it.
Devisualization.Image
To further Devisualization, I have got the start of an image library. It should be fairly interface complete now. For this I really could use help from anyone with experience with PNG especially with Adam7 interlacing and color correction such as gamma. Currently missing an exporter. Only imports. Does not import grayscale or palleted. Goal: to act as the image representation within memory (including colors). Usage: Devisualization.Window uses it for window icon's (untested for x11 can somebody confirm this does indeed work?). Devisualization.Font heavily uses it for glyphs and the output of its rasterization. [0] https://github.com/Devisualization/image
Re: Devisualization.Image
On 18/11/2014 10:37 p.m., Timur Gafarov wrote: 15.11.2014 07:48, Rikki Cattermole пишет: To further Devisualization, I have got the start of an image library. It should be fairly interface complete now. For this I really could use help from anyone with experience with PNG especially with Adam7 interlacing and color correction such as gamma. Currently missing an exporter. Only imports. Does not import grayscale or palleted. Goal: to act as the image representation within memory (including colors). Usage: Devisualization.Window uses it for window icon's (untested for x11 can somebody confirm this does indeed work?). Devisualization.Font heavily uses it for glyphs and the output of its rasterization. [0] https://github.com/Devisualization/image I have working PNG export in my image processing package, part of dlib: https://github.com/gecko0307/dlib There're also importers for BMP and TGA. Hmm I see. There is quite a few incompatibilities so porting or reusing isn't really an option without hitting the filesystem at this time. Unfortunately. While I like the idea of dlib, I'm not a fan of all encompassing libraries atleast now (yes yes I know Cmsed and all). I don't feel adding a dependency on the entire package is worth it. However by the looks of things, you definitely have better quality code. At the very least some way to convert between the two e.g. SuperImage and my Image would be worth it.
Re: crate.d a draft for a mvc library
On 28/11/2014 8:16 a.m., gedaiu wrote: Hi, In the last weeks I tried to make a draft for a mvc library. I tried to take advantage of templates, uda and ctfe to make the interaction with the database and the routing easier. There is still a lot of work to do for making it ready to work in production... but anyway.. what do you think? https://github.com/gedaiu/crate.d Thanks, Bogdan I had a look at it, it looks very simplistic. But I assume it would be rather fast for linking. Which is a good thing. I would recommend if you haven't already to look at my projects, Cmsed[0], livereload[1], skeleton[2] and dvorm[3]. I started dvorm end of last year and is fairly complete at this point. Cmsed is due for rewrite (got most of the code done if you are interested) but I'm waiting on a PR for dmd before doing more. [0] https://github.com/rikkimax/Cmsed [1] https://github.com/rikkimax/livereload [2] https://github.com/rikkimax/skeleton [3] https://github.com/rikkimax/dvorm
Re: crate.d a draft for a mvc library
On 30/11/2014 1:20 p.m., Dylan Knutson wrote: MongoModel in the model part of crate.d is interesting, and I'm glad to see there's a more structured way of interacting with MongoDB than just poking at untyped objects. I think D is still missing a really good ORM (Rikki's dvorm is a start), but there's nothing out there that conforms to the activerecord pattern as far as I can tell. There is hibernated around, but something about it always made me go yeah no. But so does actual hibernate so meh. Dvorm was meant as a very simple interface completely abstracted out from the database engine itself :) It does this very well, even can send/receive emails! I would like to eventually build another library that is backwards compatible with Dvorm but with a lot more features. And far less database engine abstracted away. Mostly so things like Cmsed don't need a full rewrite. But alas, I'm trying to improve the situation for gui's atm.
Re: forum.dlang.org is now using DCaptcha
On 4/12/2014 8:13 p.m., ketmar via Digitalmars-d-announce wrote: On Thu, 04 Dec 2014 04:02:46 + Mike via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: I had to maintain a technical forum last year that was getting spammed like crazy. I added the question how many bits are in a byte? six. am i failed? Google is your friend. https://www.google.co.nz/webhp?sourceid=chrome-instantion=1espv=2ie=UTF-8#q=1+byte+to+bits
Re: Travis-CI support for D
On 14/12/2014 4:28 a.m., Martin Nowak wrote: On 12/13/2014 02:59 PM, ZombineDev wrote: Thanks for the great work! Is it possible to also include dmd+druntimie+phobos git-head? It would be helpful to know if your project can be built with the new version of DMD (when it is officially released) ahead of time. If you are using some yet-to be deprecated code you can fix the issue much sooner and when the next version is released the migration cost would be virtually zero. Sure, this won't be useful for everybody, but I am sure that for some larger organizations this will be helpful. Also this will help test the new compiler and standard library code better, which should benefit everyone. There are some interesting points in here, but the implication that more people should test master is wrong, at least I hope so. 1. New releases should be pain-free Obviously new releases shouldn't introduce regressions. If there are new warnings/deprecations you should be able to live with them for a while and fix them when you have time. This is how we perceive this and if that doesn't work for you I'd be interested to know why. 2. master == unstable There are quite some newsgroup posts like my project doesn't build with the latest dmd or latests dmd does A. That's not too helpful IMO, as it creates additional support overhead (deduplicating issues, answering, discussing). Therefor I wouldn't want to encourage this even more. If something breaks, go directly to bugzilla and file an issue. If you happen to know the cause go to github and add a comment on the relevant pull. New dmd and phobos code should be well tested and designed before we merge it into master. Things like std.experimental are supposed to deal with the lack of broad testing feedback during normal development. 3. Beta is for testing Alpha and beta releases are the right time to try a new release and they will be available on Travis-CI too [1]. During beta releases we're actively monitoring the dmd-beta mailing list [2] and are fixing any open regressions. This is the time when we're most receptive for newly reported issues. [1]: https://github.com/travis-ci/travis-build/pull/340/files#diff-ac986a81b67f1bd5851c535881c18abeR91 [2]: http://lists.puremagic.com/mailman/listinfo/dmd-beta Git pulling and rebuilding dmd every time you update your project is not extremely efficient, but perhaps this can be done once a week. Or the autotester can upload the first binaries that pass all tests to some ftp in the beginning of every week. I was thinking about releasing nightlies every now and then. We can't really reduce the release cycle without massively changing our workflow. That doesn't seem worthwhile for the few core contributors that we are. I am not very familiar with Travis or the dmd release process, so correct me if I am wrong. Done :) -Martin I'm also on the side of, we should get dmd, gdc and ldc nightlies available. As an early warning of issues instead of OMG it breaks fixxx i. Even though I don't use travis, I do think it would be a good thing to have. And anyway, it forces us to have good infrastructure going for automated releases.
Re: Travis-CI support for D
On 15/12/2014 5:03 a.m., Martin Nowak wrote: On 12/14/2014 01:42 AM, Rikki Cattermole wrote: And anyway, it forces us to have good infrastructure going for automated releases. We already have that, I build that in Jan 2014. Unless we have nightlies for e.g. installers, I'm not quite sure its going far enough. Although shouldn't be much of a stretch now (or atleast its not advertised anywhere).
Re: HDF5 bindings for D
On 22/12/2014 5:51 p.m., Laeeth Isharc wrote: https://github.com/Laeeth/d_hdf5 HDF5 is a very valuable tool for those working with large data sets. From HDF5group.org HDF5 is a unique technology suite that makes possible the management of extremely large and complex data collections. The HDF5 technology suite includes: * A versatile data model that can represent very complex data objects and a wide variety of metadata. * A completely portable file format with no limit on the number or size of data objects in the collection. * A software library that runs on a range of computational platforms, from laptops to massively parallel systems, and implements a high-level API with C, C++, Fortran 90, and Java interfaces. * A rich set of integrated performance features that allow for access time and storage space optimizations. * Tools and applications for managing, manipulating, viewing, and analyzing the data in the collection. * The HDF5 data model, file format, API, library, and tools are open and distributed without charge. From h5py.org: [HDF5] lets you store huge amounts of numerical data, and easily manipulate that data from NumPy. For example, you can slice into multi-terabyte datasets stored on disk, as if they were real NumPy arrays. Thousands of datasets can be stored in a single file, categorized and tagged however you want. H5py uses straightforward NumPy and Python metaphors, like dictionary and NumPy array syntax. For example, you can iterate over datasets in a file, or check out the .shape or .dtype attributes of datasets. You don't need to know anything special about HDF5 to get started. In addition to the easy-to-use high level interface, h5py rests on a object-oriented Cython wrapping of the HDF5 C API. Almost anything you can do from C in HDF5, you can do from h5py. Best of all, the files you create are in a widely-used standard binary format, which you can exchange with other people, including those who use programs like IDL and MATLAB. === As far as I know there has not really been a complete set of HDF5 bindings for D yet. Bindings should have three levels: 1. pure C API declaration 2. 'nice' D wrapper around C API (eg that knows about strings, not just char*) 3. idiomatic D interface that uses CTFE/templates I borrowed Stefan Frijter's work on (1) above to get started. I cannot keep track of things when split over too many source files, so I put everything in one file - hdf5.d. Have implemented a basic version of 2. Includes throwOnError rather than forcing checking status C style, but the exception code is not very good/complete (time + lack of experience with D exceptions). (3) will have to come later. It's more or less complete, and the examples I have translated so far mostly work. But still a work in progress. Any help/suggestions appreciated. [I am doing this for myself, so project is not as pretty as I would like in an ideal world]. https://github.com/Laeeth/d_hdf5 You seem to be missing your dub file. Would be rather hard to get it onto dub repository without it ;) Oh and keep the bindings separate from wrappers in terms of subpackages.
Re: Calypso: Direct and full interfacing to C++
On 23/12/2014 12:14 p.m., Elie Morisse wrote: Hi everyone, I have the pleasure to announce to you all the existence of a modified LDC able to interface directly to C++ libraries, wiping out the need to write bindings: https://github.com/Syniurge/Calypso It's at a prototype stage, but its C++ support is pretty wide already: • Global variables • Functions • Structs • Unions (symbol only) • Enums • Typedefs • C++ class creation with the correct calls to ctors (destruction is disabled for now) • Virtual function calls • Static casts between C++ base and derived classes (incl. multiple inheritance offsets) • Mapping template implicit and explicit specializations already in the PCH to DMD ones, no new specialization on the D side yet • D classes inheriting from C++ ones, including the correct vtable generation for the C++ part of the class So what is this sorcery? Let's remind ourselves that this isn't supposed to be feasible: Being 100% compatible with C++ means more or less adding a fully functional C++ compiler front end to D. Anecdotal evidence suggests that writing such is a minimum of a 10 man-year project, essentially making a D compiler with such capability unimplementable. http://dlang.org/cpp_interface.html Well.. it is :D Calypso introduces the modmap keyword, as in: modmap (C++) cppheader.h; That really should be a pragma. pragma(modmap, C++, cppheader.h); Since pragma's are the way to instruct the compiler to do something. to generate with the help of Clang libraries a virtual tree of C++ modules. Then after making Clang generate a PCH for all the headers, the PCH is loaded and classes, structs, enums are placed inside modules named after them, while global variables and functions are in a special module named _. For example: import (C++) Namespace.SomeClass; // imports Namespace::SomeClass import (C++) Namespace._; // imports all the global variables and functions in Namespace import (C++) _ : myCfunc, myGlobalVar; // importing the global namespace = bad idea, but selective imports work Being a prototype, I didn't really pay attention to code conventions or elegance and instead focused on getting things working. And being tied to LDC and Clang (I have no idea how feasible a GCC version would be), it's going to stay like this for some time until I get feedback from the contributors on how this all should really be implemented,. For example Calypso introduces language plugins, to minimize the amount of code specific to C++ and to make support of foreign languages cleaner and less intrusive, although it of course needs numerous hooks here and there in DMD and LDC. Calypso is still WIP, but it's in pretty good shape and already works in a lot of test cases (see tests/calypso/), and is almost ready to use for C++ libraries at least. Since C libraries are in the global namespace, it's not a convenient replacement yet for bindings until I implement the Clang module map format. More info this blog post detailing some of the history behind Calypso: http://syniurge.blogspot.com/2013/08/calypso-to-mars-first-contact.html So.. Merry Christmas dear D community? :) My take on the current talks of feature freezing D: the strength of D is its sophistication. The core reason why D fails to attract more users isn't the frequent compiler bugs or regressions, but the huge amount of time needed to get something done because neither equivalent nor bindings exist for most big and widespread C++ libraries like Qt. All these talks about making D a more minimalist language won't solve much and will only result in holding back D, which has the potential to become a superset of all the good in other system languages, as well as bringing its own powerful unique features such as metaprogramming done right. By removing the main reason why D wasn't a practical choice, this will hopefully unlock the situation and make D gain momentum as well as attract more contributors to the compilers to fix bugs and regressions before releases. Will you be upstreaming this? Or maintaining this completely yourself?
Re: D is one if Wired's 10 Most Hardcore Tech Stories of 2014
On 28/12/2014 7:45 a.m., Walter Bright wrote: On 12/27/2014 7:36 AM, Laeeth Isharc wrote: On Saturday, 27 December 2014 at 11:15:11 UTC, Walter Bright wrote: On 12/26/2014 10:25 PM, Walter Bright wrote: http://www.wired.com/2014/12/wired-enterprise-year/ https://www.reddit.com/r/programming/comments/2qioj8/dlang_story_makes_wireds_10_most_hardcore_tech/ Congratulations, Walter. It's very satifying to see emerging mainstream recognition of something so solid and whose advantages are based in real advantages rather than marketing hype. I am personally very glad you decided on 'retirement' that you were not after all the daytime TV kind of guy, and I wanted to thank you for everything you have contributed to D and its users. I wish you a great start to the new year. Thank you very much for the kind words! I am not interested in retirement. I'll be writing code until my mind gives out. I do enjoy TV a bit much, building a home theater in the basement which is rather nice! It's amazing that an excellent theater can be built for under a grand outlay. Now all you need is a rather decent computer with tv capture card and wala. Enjoy your full immersion programming environment! and media center.
Re: My D Cookbook on sale: $5 ebook from the publisher
On 29/12/2014 10:13 a.m., Adam D. Ruppe wrote: I just noticed they temporarily reduced the price of my book: https://www.packtpub.com/application-development/d-cookbook If you haven't gotten a copy yet, start off the new year right! :) Among the stuff covered are how to use ranges, reflection, structs for resource management, OS APIs, and even a little on starting to write a kernel level program in D. Practical to fun, educational all around! PS for those of you who have read it and haven't yet, write an amazon review! http://www.amazon.com/gp/product/1783287217/ref=s9_simh_gw_p14_d0_i1?pf_rd_m=ATVPDKIKX0DERpf_rd_s=center-2pf_rd_r=1P864AG6WY9Y7H86MVFGpf_rd_t=101pf_rd_p=1688200382pf_rd_i=507846 Happy birthday to me, Happy birthday to me, thank you Adam. Happy birthday to me. Yes it's my birthday, and yes I just bought it.
Re: DlangUI project update
On 29/12/2014 10:33 p.m., Vadim Lopatin wrote: On Monday, 29 December 2014 at 09:30:40 UTC, Vadim Lopatin wrote: On Monday, 29 December 2014 at 07:35:13 UTC, ketmar via Digitalmars-d-announce wrote: ah, and another thing: freeimage sux for GNU/Linux. it looks completely alien and no sane GUI software requires it. i didn't looked at the code, but i hope that image loading is well abstracted in DlangUI? if it is, i can try to write a loaders for png and jpg (jpg? in GUI? holy heavens, why?!). it's better to check if the system has the corresponding libraries with corresponding versions (imlib2 rocks, for example), but i suppose that dub cannot into configure checks, am i right? Initially, I've used libpng for loading images. But it is compatible only with some particular version of libpng.so API version is passed somwhere in calls, and doesn't work with updated library. I've tried to find some replacement for it, and found FreeImage (there was Derelict suport for it, and it was used in some D projects). Probably, it makes sense to move to SDL_image. But it looks like it requires SDL as dependency. Does it work ok on linux? Let me check imlib2 as well. BTW, there is de_image package - Image loading and exporting Devisualization. It's native D implementation, and possible if PNG only is enough, it makes sense to use it. Did some try de_image? Author here. Devisualization.Image png support is not complete. But should be fine for RGBA images. Interlacing is not done, however should be pretty easy to implement. I just haven't really wrapped my head around how to do and undo Adam7. There is much more complete implementations in e.g. ae with support for jpeg, bmp, tiff ext. However my reasons for Devisualization.Image is = less code to compile in. Highly scoped.
Re: DlangUI project update
On 30/12/2014 12:14 a.m., Vadim Lopatin wrote: On Monday, 29 December 2014 at 09:43:34 UTC, Rikki Cattermole wrote: On 29/12/2014 10:33 p.m., Vadim Lopatin wrote: On Monday, 29 December 2014 at 09:30:40 UTC, Vadim Lopatin wrote: BTW, there is de_image package - Image loading and exporting Devisualization. It's native D implementation, and possible if PNG only is enough, it makes sense to use it. Did some try de_image? Author here. Devisualization.Image png support is not complete. But should be fine for RGBA images. Interlacing is not done, however should be pretty easy to implement. I just haven't really wrapped my head around how to do and undo Adam7. There is much more complete implementations in e.g. ae with support for jpeg, bmp, tiff ext. However my reasons for Devisualization.Image is = less code to compile in. Highly scoped. Does de_image support PNGs with more than 256 colors? It should support 8bit and 16bit sample (not RGB I mean just for e.g. R)[0]. I haven't really tested 16bit support however. Does it support alpha? Yes Interlacing is not critical for usage in GUI resources - it's always possible to open interlaced image and save as non-interlaced. Just so you know [1]. Are you planning to separate import and export operations? E.g. possibility to build read-only configuration of library to reduce code size? Currently there is no way to disable exporting. Its honestly not much code extra, double roughly at most. I'm going to try de_image instead of FreeImage in dlangui. Sweet sounds good. Also if you don't mind looking into Devisualization.Window as well? It would help get you on to OSX rather fast. Since it already supports it. If there is anything you want help with or just general chat, feel free to ping me on gitter.im. All Devisualization projects especially the more complete ones have a conversation on there with me sitting in them. [0] https://github.com/Devisualization/image/blob/master/source/png/devisualization/image/png/reader_chunks_IDAT.d#L67 [1] https://github.com/Devisualization/image/blob/master/source/png/devisualization/image/png/reader_chunks_IDAT.d#L57
Re: DlangUI project update
On 25/01/2015 9:29 a.m., Suliman wrote: I checked what is in: derelict-sdl2-1.9.1\.dub\build\library-debug-windows-x86-dmd_2066-C6F79EB15955F23DC333E5B450077DDB In this folder located only file: DerelictSDL2.lib $ dub clean $ dub build --force Some inconsistency in build caches I bet.
Re: Martin Nowak is our new release czar
On 5/02/2015 1:07 p.m., Andrei Alexandrescu wrote: Andrew Edwards, our former release czar, declined his czardom because he went to college. Thanks and good luck! He left a void of power. After a period of turmoil and intestine political fights, we have a new, ruthless czar: Martin Nowak. He plans to put us on a path of regular, predictable 6-week releases, thus ending the D Middle Ages. Please throw your hat in the air with me to hail the new czar! :o) Andrei Congrats! and yay!
Re: Anyone interested in embedding a JVM in their D app?
On 15/01/2015 3:26 a.m., Ben Boeckel via Digitalmars-d-announce wrote: On Wed, Jan 14, 2015 at 15:05:18 +1300, Rikki Cattermole via Digitalmars-d-announce wrote: Definitely need to get JNI support first class. It definitely will help with getting D on Android. My experience is that the D runtime needed some work to accept that there are Linux machines without glibc (bionic for Android). After getting those assumptions out, I had it to a point where it was compiling, but things blew up in the runtime somewhere (or bionic; it was never really giving useful backtraces) during my argument parsing (my guess is the GC was mucking with the wrong bits, but there wasn't anything conclusive since debugging was never easier than what I got from logcat and looking at disassemblies). This was back in 2.065 era though and I haven't done much with it since then. --Ben That's trying to get JNI to work, I'm assuming that part has already been done and we want a nice wrapper around it. At the worse case scenario, at least it'll work for e.g. Windows, OSX and Linux.
Re: DerelictCEF: Chromium Emdedded Framework Binding
On 22/01/2015 3:07 a.m., Mike Parker wrote: I've been wanting to play around with the Chromium Emdedded Framework for a while. So I've created a D binding for it. I want to stress that I can offer no support for this right now beyond fixing bugs, i.e. I can't help anyone with how to use the CEF C API as I don't know it myself. I've put up a blog post at [1] for a few helpful links and more warnings. Beyond that, if you want to use it right now, you're on your own. Here be monsters! Screenshot: http://i.imgur.com/pYlP3dE.png?1 [1] http://dblog.aldacron.net/derelictcef-binding-to-chromium-embedded-framework/ Awesome! I was looking into this a while back. I am certainly glad this is being explored.
Re: Deadcode: A code editor in D
On 20/01/2015 1:48 a.m., Jonas Drewsen wrote: On Sunday, 18 January 2015 at 22:00:51 UTC, Piotrek wrote: On Friday, 16 January 2015 at 21:19:08 UTC, Jonas Drewsen wrote: I have been working on an editor written in D for use with D for some time now and have made a blog post about it. Any feedback or suggestions are welcome. http://deadcodedev.steamwinter.com Thanks Jonas Hi, This is an impressive work. I's really nice to see a presentation of how much help can be provided from the D editor and existing language labiaries. I have several questions as well: 1. Was the libdparser integrated with extension system or is it embedded in the core? Done with the extension system. 2. What are the dependencies? sdl2, opengl, freetype, libdparse (if you want the extension for D semantic) I am keeping an eye on some of the native D input/window libraries that is being worked on in the hope of being able to replace the SDL2 dependency. Please file any enhancement requests for any Devisualization projects you need. It would help me know what is needed of them more. 3. How hard it would be to change the feellook of the gui as it is in conventional editors (Visual, MonoDeveop, GtCreator, Eclipse). I mean menus, buttons, views etc? Would require some more views/controls to be created. The styling is done through CSS sheets. A common subset of CSS keys are supported but maybe a few more would be needed.
Re: DDocs.org: auto-generated documentation for all DUB projects (WIP)
On 11/02/2015 11:40 a.m., Kiith-Sa wrote: DDocs.org (http://ddocs.org) is a repository of documentation for DUB projects that automatically re-generates docs as new projects/releases/branch changes are added. The idea is to make documenting D projects as simple as possible, to the point where you don't need to do any work to get documentation for your project other than adding it to the DUB registry. Also, users can now browse documentation for DUB projects even if the author was too lazy to generate it themselves (assuming thy did include some documentation comments). Note that this is still in a very early stage, it was put together in a very quick-and-dirty style by a person with little webdev experience. Currently it just scans `code.dlang.org`, looking for changes (yes, I know, this will break as soon as code.dlang.org changes, I plan to raise issue/s (PRs?) to the dub registry project so it can have a full/stable API, but I wanted to get something to work *right now*. Code is here: * ddocs.org: https://github.com/kiith-sa/ddocs.org * hmod-dub: https://github.com/kiith-sa/hmod-dub * harbored-mod: https://github.com/kiith-sa/harbored-mod Background: When optimizing harbored-mod by testing it on big D projects (gtk-d, tango, vibe.d, etc.), I wrote a simple tool to fetch/generate docs for any DUB project; I got carried away and used that as base for a tool that checks for changes in the DUB registry and generates docs for all projects. Right this needs to be made first class link wise on dlang.org and code.dlang.org
New book: Developing with compile time in mind
Exciting news, my book on CTFE is out[0]. To summarize, it contains most of my knowledge of CTFE in a generic'ish form with examples being in D. There is a bit of talk of what support there can be and what we have. The design patterns are probably the most interesting. If you have any improvements or find any issues e.g. stray hyphens (Copied directly from Word wasn't a good idea) please let me know. The size of the book is around 51 pages. I understand if you do not consider it worth $15USD so the minimum price is $5USD. If there is demand I can create an extra package (will cost) that contains full examples on how to use the design patterns. Leanpub support sending to Kindle and will you give you a pdf, mobi and epub versions. [0] https://leanpub.com/ctfe
Re: New book: Developing with compile time in mind
On 18/02/2015 5:08 a.m., Andrei Alexandrescu wrote:
On 2/17/15 3:49 AM, Russel Winder via Digitalmars-d-announce wrote:
On Tue, 2015-02-17 at 16:40 +1300, Rikki Cattermole via
Digitalmars-d-announce wrote:
[…]
Just let me know any improvements that could be made. Updates are
free after all! (Leanpub is amazing, what with markdown writing and
all).
How did you find Markdown for writing a book?
My prejudice is that you need XeLaTeX or AsciiDoc for large document
writing, especially when targeting press PDF.
Mine too. However, PDF is for fixed layout and any future book should
aim at flexible format or at least multiple fixed layouts.
I think Markdown's use for a book is works, won't ever win an interior
design contest.
TDPL's second edition will most likely use ddoc macros to generate
LaTeX, HTML, and a couple of ebook formats.
Andrei
Idk Makura version (leanpub's specification) is pretty nice.
You really don't think about formatting much. You just make the content
and let it do the rest.
Everything you put into the markdown documents themselves are pretty
straight forward easy to read and understand e.g.
{title=On top of code snippet text}
```D
void main() {
import std.stdio;
writeln(Hello World!);
}
```
And yes it support D code blocks :D Much better then my previous method
of using images. In fact this is a requirement for me.
You can configure Makura's generation via a config file which includes
output page size. So right now leanpub is generating pdf's that can be
used on lulu.com. There is some modifications need to be done e.g. blank
last page. But that's about it. Specifically for a pocketbook.
I would highly recommend giving leanpub a go. I absolutely fell in love
with it.
In fact I'm seriously considering implementing Makura in D once I have a
good pdf generation library. I know we already have a markdown library
but I might just make my own.
Re: New book: Developing with compile time in mind
On 17/02/2015 4:32 p.m., Walter Bright wrote: On 2/16/2015 3:07 PM, Rikki Cattermole wrote: [0] https://leanpub.com/ctfe Thank you. I bought my copy! No problem! Just let me know any improvements that could be made. Updates are free after all! (Leanpub is amazing, what with markdown writing and all).
Re: New book: Developing with compile time in mind
On 18/02/2015 12:49 a.m., Russel Winder via Digitalmars-d-announce wrote:
On Tue, 2015-02-17 at 16:40 +1300, Rikki Cattermole via Digitalmars-d-announce
wrote:
[…]
Just let me know any improvements that could be made. Updates are
free after all! (Leanpub is amazing, what with markdown writing and
all).
How did you find Markdown for writing a book?
My prejudice is that you need XeLaTeX or AsciiDoc for large document
writing, especially when targeting press PDF.
Rather enjoyable.
I loved that I could just write my content. Maybe splash some hashes or
{pagebreak} in there.
Although I lost a lot of control especially since leanpub's system isn't
opensource unfortunately. But I intend to fix that one day ;)
Re: Harbored-mod (doc generator) 0.2: Cross-referencing, methods/fields no longer in separate files
On 1/02/2015 4:31 a.m., Kiith-Sa wrote: Harbored-mod (https://github.com/kiith-sa/harbored-mod) is a documentation generator based on Brian Schott's Harbored that supports both DDoc and Markdown in documentation comments. -- Examples of generated docs -- * Public imports in a package.d: http://defenestrate.eu/docs/tharsis-core/api/tharsis/entity.html * Class with a template parameter, member functions and aliases: http://defenestrate.eu/docs/tharsis-core/api/tharsis/entity/entitymanager/EntityManager.html * Simple DDoc See_Also: section: http://defenestrate.eu/docs/tharsis-core/api/tharsis/entity/componenttypeinfo/ImmutableRawComponent.html * Note: DDoc section with some markdown: http://defenestrate.eu/docs/tharsis-core/api/tharsis/entity/processtypeinfo.html#prioritizeProcessOverloads -- Release highlights -- * Automatic cross-referencing in code blocks and inline code * New (and now default) output format: aggregated HTML; generate documentation files only for aggregates (modules, structs, classes, etc.) and document non-aggregate members (functions, variables, etc.) in these files. The previous, DDox compatible format, where a separate file is generated for every symbol, is still supported through the `--format=html-simple` option. * Various style and usability improvements * Major refactoring * Many bugfixes Full changelog: https://github.com/kiith-sa/harbored-mod/releases/tag/v0.2.0 Atleast on chrome win7 the font is absolutely awful. Otherwise, I LOVE!
Re: Harbored-mod (doc generator) 0.2: Cross-referencing, methods/fields no longer in separate files
On 1/02/2015 1:02 p.m., Rikki Cattermole wrote: On 1/02/2015 4:31 a.m., Kiith-Sa wrote: Harbored-mod (https://github.com/kiith-sa/harbored-mod) is a documentation generator based on Brian Schott's Harbored that supports both DDoc and Markdown in documentation comments. -- Examples of generated docs -- * Public imports in a package.d: http://defenestrate.eu/docs/tharsis-core/api/tharsis/entity.html * Class with a template parameter, member functions and aliases: http://defenestrate.eu/docs/tharsis-core/api/tharsis/entity/entitymanager/EntityManager.html * Simple DDoc See_Also: section: http://defenestrate.eu/docs/tharsis-core/api/tharsis/entity/componenttypeinfo/ImmutableRawComponent.html * Note: DDoc section with some markdown: http://defenestrate.eu/docs/tharsis-core/api/tharsis/entity/processtypeinfo.html#prioritizeProcessOverloads -- Release highlights -- * Automatic cross-referencing in code blocks and inline code * New (and now default) output format: aggregated HTML; generate documentation files only for aggregates (modules, structs, classes, etc.) and document non-aggregate members (functions, variables, etc.) in these files. The previous, DDox compatible format, where a separate file is generated for every symbol, is still supported through the `--format=html-simple` option. * Various style and usability improvements * Major refactoring * Many bugfixes Full changelog: https://github.com/kiith-sa/harbored-mod/releases/tag/v0.2.0 Atleast on chrome win7 the font is absolutely awful. Otherwise, I LOVE! Also any chance that it could output json to represent modules instead of html?
Re: 2015 H1 Vision
On 1/02/2015 2:17 p.m., Andrei Alexandrescu wrote: Hello, Walter and I have been mulling for a while on a vision for the first six months of 2015. http://wiki.dlang.org/Vision/2015H1 This is stuff we consider important for D going forward and plan to work actively on. We encourage the D community to focus contributions along the same lines. We intentionally kept the document short and high-level as opposed to discussing tactical details. Such discussions are encouraged in the appropriate forums. Thanks, Walter and Andrei I'm personally slightly concerned about libraries into phobos. Not so much libraries in general. But frameworks. This is how we do x, kind. Can we please keep opinionated libraries of how to do things away from phobos? An ORM is a great example of this. But a client library to e.g. Mysql is fine. Anyway enough about that, the plan is definitely looking good!
Re: Harbored-mod (doc generator) 0.2: Cross-referencing, methods/fields no longer in separate files
On 2/02/2015 2:36 a.m., Kiith-Sa wrote: Atleast on chrome win7 the font is absolutely awful. Could you post a screenshot? I mostly just use the default sans which can result in any font being used based on the OS, http://imgur.com/JvbjN9o
Re: NEW asm.dlang.org site
On 27/01/2015 12:46 p.m., Iain Buclaw wrote: Hi, It is my pleasure to release a new site onto the community. An Interactive DMD compiler. http://asm.dlang.org/ Inspired by Matt Godbolt's GCC Explorer[1], and my own hosted version that uses GDC[2]. I was asked by Andrei to fork and make a working protoype that uses DMD. All work is hosted on Github[3], and we are planning on moving it to part of the D-Programming-Language repositories. Please share, contribute, and destroy! Regards Iain. [1]: http://gcc.godbolt.org/ [2]: http://explore.dgnu.org/ [3]: https://github.com/ibuclaw/gcc-explorer/ 1) can we get e.g. ldc ext. on there as well? 2) can it be renamed e.g. paste/pastebin? 3) login ext. integrated with code.dlang.org would be nice for full pastebin features
Re: We're looking for a Software Developer! (D language)
On 9/01/2015 4:20 p.m., John Carter via Digitalmars-d-announce wrote: If you email me at john DOT carter AT taitradio DOT com we can take this conversation out of the D forum as it is going way off topic. On Fri, Jan 9, 2015 at 4:05 PM, Rikki Cattermole via Digitalmars-d-announce digitalmars-d-announce@puremagic.com mailto:digitalmars-d-announce@puremagic.com wrote: On 9/01/2015 2:53 p.m., John Carter via Digitalmars-d-announce wrote: Whilst we are not currently using D at Tait Electronics I am certainly trying to make it happen. So if this job fits you... http://www.taitradio.com/__about-us/careers/new-zealand/__jobs-in-new-zealand/embedded-__software-engineer2 http://www.taitradio.com/about-us/careers/new-zealand/jobs-in-new-zealand/embedded-software-engineer2 You can help me try! Part of the problem with getting a new language accepted in a company, is to develop a critical mass of willing and capable programmers in that language. On Fri, Jan 9, 2015 at 2:20 AM, Rikki Cattermole via Digitalmars-d-announce digitalmars-d-announce@__puremagic.com mailto:digitalmars-d-announce@puremagic.com mailto:digitalmars-d-__annou...@puremagic.com mailto:digitalmars-d-announce@puremagic.com wrote: On 9/01/2015 12:10 a.m., Johanna Burgos wrote: Your Mission Support our team in the development of our event-based infrastructure Development of high-performance applications and services Writing applications to work with our distributed DHT database system You will be coding in the D-language Your Track Record Degree in Computer Science, or closely-related Knowledge of Github Strong interest in distributed architectures Experienced in C, C++ or D (you’ll be programming in D) Fluency in written and spoken English Your Style You don’t like being thrown in at the deep end. You like to jump yourself You live and breathe globalization and love to work and travel internationally You mesmerize people with a friendly and open-minded, yet trustworthy and reliable personality You think in achievements, not in departments, responsibilities or hierarchy As a quick learner, first mover and fast thinker you can keep pace with one of the fastest growing technology start ups You are driven by curiosity and innovation, and always up for a good challenge Our Promise Employment in Berlin, full-time and full of fun challenges, with flexible working hours Access to a high-profile professional network of international Internet companies Possibility to show your excellent competence and your creative ideas to a broad audience A competitive compensation and incentive plan that rocks when you rock Personal development and training that will help you evolve from the pro you are right now to the champ you’re destined to be Basic German language courses for non-native speakers Help with residence permit processing for non-EU citizens Daily adrenalin rushes while working and learning in one of the fastest growing sectors in online advertising Access to an international high-profile network A company culture driven by pioneer-thinking and talent that exceeds departments and hierarchies The challenge is on. If you think it’s you we’re looking for, send us your battle plan along with a certificate of your super powers at care...@sociomantic.com mailto:care...@sociomantic.com mailto:careers@sociomantic.__com mailto:care...@sociomantic.com. Alternatively, a motivational cover letter and resume in English will do, too. For now. Unfortunately I half wish you guys had a New Zealand office. As I am in need of a job. -- John Carter Phone : (64)(3) 358 6639 Tait Electronics PO Box 1645 Christchurch New Zealand
Re: We're looking for a Software Developer! (D language)
On 9/01/2015 2:53 p.m., John Carter via Digitalmars-d-announce wrote: Whilst we are not currently using D at Tait Electronics I am certainly trying to make it happen. So if this job fits you... http://www.taitradio.com/about-us/careers/new-zealand/jobs-in-new-zealand/embedded-software-engineer2 You can help me try! Part of the problem with getting a new language accepted in a company, is to develop a critical mass of willing and capable programmers in that language. On Fri, Jan 9, 2015 at 2:20 AM, Rikki Cattermole via Digitalmars-d-announce digitalmars-d-announce@puremagic.com mailto:digitalmars-d-announce@puremagic.com wrote: On 9/01/2015 12:10 a.m., Johanna Burgos wrote: Your Mission Support our team in the development of our event-based infrastructure Development of high-performance applications and services Writing applications to work with our distributed DHT database system You will be coding in the D-language Your Track Record Degree in Computer Science, or closely-related Knowledge of Github Strong interest in distributed architectures Experienced in C, C++ or D (you’ll be programming in D) Fluency in written and spoken English Your Style You don’t like being thrown in at the deep end. You like to jump yourself You live and breathe globalization and love to work and travel internationally You mesmerize people with a friendly and open-minded, yet trustworthy and reliable personality You think in achievements, not in departments, responsibilities or hierarchy As a quick learner, first mover and fast thinker you can keep pace with one of the fastest growing technology start ups You are driven by curiosity and innovation, and always up for a good challenge Our Promise Employment in Berlin, full-time and full of fun challenges, with flexible working hours Access to a high-profile professional network of international Internet companies Possibility to show your excellent competence and your creative ideas to a broad audience A competitive compensation and incentive plan that rocks when you rock Personal development and training that will help you evolve from the pro you are right now to the champ you’re destined to be Basic German language courses for non-native speakers Help with residence permit processing for non-EU citizens Daily adrenalin rushes while working and learning in one of the fastest growing sectors in online advertising Access to an international high-profile network A company culture driven by pioneer-thinking and talent that exceeds departments and hierarchies The challenge is on. If you think it’s you we’re looking for, send us your battle plan along with a certificate of your super powers at care...@sociomantic.com mailto:care...@sociomantic.com. Alternatively, a motivational cover letter and resume in English will do, too. For now. Unfortunately I half wish you guys had a New Zealand office. As I am in need of a job. -- John Carter Phone : (64)(3) 358 6639 Tait Electronics PO Box 1645 Christchurch New Zealand This email, including any attachments, is only for the intended recipient. It is subject to copyright, is confidential and may be the subject of legal or other privilege, none of which is waived or lost by reason of this transmission. If you are not an intended recipient, you may not use, disseminate, distribute or reproduce such email, any attachments, or any part thereof. If you have received a message in error, please notify the sender immediately and erase all copies of the message and any attachments. Unfortunately, we cannot warrant that the email has not been altered or corrupted during transmission nor can we guarantee that any email or any attachments are free from computer viruses or other conditions which may damage or interfere with recipient data, hardware or software. The recipient relies upon its own procedures and assumes all risk of use and of opening any attachments. Wow there is actually somebody working right round the corner of me! I did not expect this. Out of curiosity how do you guys consider CPIT's Degree in ICT keep in mind that it doesn't cover c/c++. Well until I pushed for D(native) anyway.
Re: Anyone interested in embedding a JVM in their D app?
On 14/01/2015 3:00 p.m., james wrote: I've been playing with jni.h and D. I think I've got a fully working jni.d and I have the start of a nicer D wrapper around it with djvm.d. https://github.com/jamesmahler/djvm There is an example usage in the README.md. There's also why I'd do such a thing in there. I'm not sure if anyone else would be interested in this. I'm open to help and merge requests if anyone wants to join in. In the short term, I still have several low level things to wrap with the more D interfaces. In the longer term, I want to have D interfaces around JDBC. Definitely need to get JNI support first class. It definitely will help with getting D on Android.
Re: Heady House Hunting with D
On 14/01/2015 4:46 p.m., Philpax wrote: Hey everyone, I recently wrote a blog post about how I used D/vibe.d to help find a new house. I haven't publicized it anywhere else yet, so I'm looking forward to what the D community has to say! You can check it out here: http://philpax.me/blog/heady-house-hunting-with-d D made it easy to model the problem and quickly crunch through it; I'm pretty happy with how quickly I was able to get decent results. It's not the most idiomatic of code, but D's flexibility meant that I could concentrate on the concept instead of the implementation details. Thanks, Philpax When I first saw this thread I thought it was spam. Nope! Definitely would be interesting to see this as a full blown comparison site, like there is for flight.
Re: DMD's lexer available on code.dlang.org
On 5/01/2015 2:07 a.m., Daniel Murphy wrote:
I've created a dub package for the D version of DMD's lexer, generated
automatically from the C++ source.
github: https://github.com/yebblies/ddmd
dub: http://code.dlang.org/packages/ddmd
There are a few annoying limitations, such that it uses dmd's error
printing and allocation functions, and requires configuration through
'global'.
Here is an example program that uses the lexer:
==
import std.stdio;
import std.file;
import ddmd.tokens;
import ddmd.lexer;
/
void main()
{
Lexer.initLexer();
string data = void blah() {} // stuff;
auto l = new Lexer(myfile, data.ptr, 0, data.length, 0, 0);
l.nextToken();
do
{
printf(token: %s\n, l.token.toChars());
}
while (l.nextToken() != TOKeof);
}
==
Prints:
token: void
token: blah
token: (
token: )
token: {
token: }
I saw that. I'm really looking forward to getting my teeth into it and
doing some good old refactoring. Although that will be a while because
of the auto generated thing.
Re: DMD's lexer available on code.dlang.org
On 5/01/2015 2:39 a.m., Daniel Murphy wrote: Rikki Cattermole wrote in message news:m8be2m$1dlp$1...@digitalmars.com... I saw that. I'm really looking forward to getting my teeth into it and doing some good old refactoring. Although that will be a while because of the auto generated thing. There's plenty of refactoring to be done on the C++ side too. What I want to do is D side unfortunately. I just hate to see large lists in e.g. globals with constructors. When they can be dealt with a simple array and a bit of CTFE magic.
Re: We're looking for a Software Developer! (D language)
On 9/01/2015 12:10 a.m., Johanna Burgos wrote: Your Mission Support our team in the development of our event-based infrastructure Development of high-performance applications and services Writing applications to work with our distributed DHT database system You will be coding in the D-language Your Track Record Degree in Computer Science, or closely-related Knowledge of Github Strong interest in distributed architectures Experienced in C, C++ or D (you’ll be programming in D) Fluency in written and spoken English Your Style You don’t like being thrown in at the deep end. You like to jump yourself You live and breathe globalization and love to work and travel internationally You mesmerize people with a friendly and open-minded, yet trustworthy and reliable personality You think in achievements, not in departments, responsibilities or hierarchy As a quick learner, first mover and fast thinker you can keep pace with one of the fastest growing technology start ups You are driven by curiosity and innovation, and always up for a good challenge Our Promise Employment in Berlin, full-time and full of fun challenges, with flexible working hours Access to a high-profile professional network of international Internet companies Possibility to show your excellent competence and your creative ideas to a broad audience A competitive compensation and incentive plan that rocks when you rock Personal development and training that will help you evolve from the pro you are right now to the champ you’re destined to be Basic German language courses for non-native speakers Help with residence permit processing for non-EU citizens Daily adrenalin rushes while working and learning in one of the fastest growing sectors in online advertising Access to an international high-profile network A company culture driven by pioneer-thinking and talent that exceeds departments and hierarchies The challenge is on. If you think it’s you we’re looking for, send us your battle plan along with a certificate of your super powers at care...@sociomantic.com. Alternatively, a motivational cover letter and resume in English will do, too. For now. Unfortunately I half wish you guys had a New Zealand office. As I am in need of a job.
Re: Release Candidate D 2.067.0-rc1
On 17/03/2015 10:38 a.m., Martin Nowak wrote: Release Candidate for 2.067.0 http://downloads.dlang.org/pre-releases/2.x/2.067.0/ http://ftp.digitalmars.com/ You can get the binaries here until they are mirrored. https://dlang.dawg.eu/downloads/dmd.2.067.0-rc1/ We fixed the few remaining issues. https://github.com/D-Programming-Language/dmd/compare/v2.067.0-b4...v2.067.0-rc1 https://github.com/D-Programming-Language/phobos/compare/v2.067.0-b4...v2.067.0-rc1 Unless any new issue pops up, we'll make the release on friday. -Martin I've been waiting since before 2.066 for another review on [0] or to be pulled. [0] https://github.com/D-Programming-Language/dmd/pull/3921
Re: DTanks Alpha
On 21/03/2015 10:55 a.m., Kingsley wrote: In preparation for the London D meetup I have got the DTanks robot battle framework into the first alpha release state - good enough to use at the meetup anyway. https://github.com/masterthought/dtanks --K Are you aware of what turtles are? Because this looks pretty close api wise, to be used for it.
Re: DTanks Alpha
On 21/03/2015 7:46 p.m., sclytrack wrote: On Saturday, 21 March 2015 at 02:39:23 UTC, Rikki Cattermole wrote: On 21/03/2015 10:55 a.m., Kingsley wrote: In preparation for the London D meetup I have got the DTanks robot battle framework into the first alpha release state - good enough to use at the meetup anyway. https://github.com/masterthought/dtanks --K Are you aware of what turtles are? Because this looks pretty close api wise, to be used for it. Logo? Yes that's the originating language.
Re: Streaming, making a book!
On 10/03/2015 1:09 a.m., Ondra wrote: Would you consider streaming on twitch.tv too? I have done so in the past. But they are a game streaming site. The only development streams meant to take place there is for games. So no I won't be.
Streaming, making a book!
I'm starting a live stream[1] for making a book. The book is The way to program - Lets think like a D(eveloper) For now I will only commit to Mondays 12pm UTC+0. I may stream at random times beyond that. Check my Twitter as to when that might be[2]. The book I am making is available at[0]. For published versions of it[3]. Published version will not be free, but the raw resources used to create it are under a creative commons license. The book's purpose is to not teach D. Instead it focuses on teaching programming concepts and ideas using D as a base. Assuming the book creation is a success I have a few other books in the pipeline. The second book will be covering sockets and threading via IRC/XMPP. Third would be Web development. Fourth UI's. There has already been a few streams, so content has already got a good start. If there is interest, I may stream some of Devisualization project development. Usually the stream will last 2-3 hours depending upon how many watch and interact. A couple days ago livecoding.tv came out of closed beta. Feel free to join! Disclaimer: I am not affiliated with livecoding.tv. Although the devs are great. [0] https://github.com/rikkimax/twp-d [1] http://livecoding.tv/alphaglosined [2] https://twitter.com/alphaglosined [3] https://leanpub.com/twp-d
Re: Streaming, making a book!
On 9/03/2015 10:34 p.m., Israel wrote: On Sunday, 8 March 2015 at 02:52:41 UTC, Rikki Cattermole wrote: I'm starting a live stream[1] for making a book. The book is The way to program - Lets think like a D(eveloper) For now I will only commit to Mondays 12pm UTC+0. I may stream at random times beyond that. Check my Twitter as to when that might be[2]. The book I am making is available at[0]. For published versions of it[3]. Published version will not be free, but the raw resources used to create it are under a creative commons license. The book's purpose is to not teach D. Instead it focuses on teaching programming concepts and ideas using D as a base. Assuming the book creation is a success I have a few other books in the pipeline. The second book will be covering sockets and threading via IRC/XMPP. Third would be Web development. Fourth UI's. There has already been a few streams, so content has already got a good start. If there is interest, I may stream some of Devisualization project development. Usually the stream will last 2-3 hours depending upon how many watch and interact. A couple days ago livecoding.tv came out of closed beta. Feel free to join! Disclaimer: I am not affiliated with livecoding.tv. Although the devs are great. [0] https://github.com/rikkimax/twp-d [1] http://livecoding.tv/alphaglosined [2] https://twitter.com/alphaglosined [3] https://leanpub.com/twp-d That's pretty cool. I didn't know a service like this existed. I hope all goes well... Yeah, thanks. I'll be starting in about half an hour. What will be your development environment? The streaming machine is pretty complex so: Host machine Mac book pro ~ half a year to a year old (extremely good specs) Host OS: OSX 10.10 Streaming software: OBS (the new cross platform version) Music playing software: VLC on host Now playing text exporter for VLC: https://gist.github.com/rikkimax/39b46f7ff3aa0c93b5cf VLC to OBS: http://rogueamoeba.com/freebies/soundflower/ VM system: Parallels 10 VM OS: Linux Mint 17.1 Cinnamon Other software: Remarkable[0], git Nothing really big difference between fresh install of the distro. The font size is a bit off. What with the Retina resolution. But generally I have increased the font size up enough that people can see it well. [0] http://remarkableapp.net/
Re: DDT 0.11.0 released
On 25/03/2015 2:24 a.m., Bruno Medeiros wrote: On 23/03/2015 15:35, Ben Boeckel via Digitalmars-d-announce wrote: Running a Python script to generate D code? Yes, in DUB you can run arbitrary external commands before and after the D sources compilation. But not in between? Basically, can you have a tool written in D built with the project and then used to generate code in the same project? --Ben That should be possible if you split it into two bundles or so, if I understood that case correctly. The external commands run before and after a compilation of a bundle (known in DUB as package). So you could have: 1. bundleA - pre external commands 2. bundleA - D sources compilation 3. bundleA - post external commands 4. bundleB - pre external commands 5. bundleB - D sources compilation and so on.. (if bundleA is set as a dependency of bundleB) Actually I was thinking along the lines of using sub packages to do this. package: depends on subPackage2 subPackage1: pre: do stuff compile D post: do stuff subPackage2: depends on subPackage1 pre: do stuff compile D post: do stuff Of course you could chain this as long as you want.
Re: dsq-1: open-source software synthesizer
On 30/03/2015 7:14 p.m., ketmar wrote: On Mon, 30 Mar 2015 18:54:42 +1300, Rikki Cattermole wrote: On 30/03/2015 6:35 p.m., ketmar wrote: On Mon, 30 Mar 2015 18:23:11 +1300, Rikki Cattermole wrote: Although I'm a little concerned because dub is meant to validate and tell you conflicts in licenses. O_O Hey hey hey, context matters! i'm speechless 'cause it's a great idea (let machine do it work!), but i'm not sure how this can be done with wide broad of licenses out here. and i definetely want to see std.license.compare in Phobos! ;-) I agree, I'm concerned about this as well. But hey, its one of the features the dub developers want to have.
Re: dsq-1: open-source software synthesizer
On 30/03/2015 6:35 p.m., ketmar wrote: On Mon, 30 Mar 2015 18:23:11 +1300, Rikki Cattermole wrote: Although I'm a little concerned because dub is meant to validate and tell you conflicts in licenses. O_O Hey hey hey, context matters!
Re: dsq-1: open-source software synthesizer
On 30/03/2015 7:26 p.m., ketmar wrote: On Mon, 30 Mar 2015 19:17:35 +1300, Rikki Cattermole wrote: On 30/03/2015 7:14 p.m., ketmar wrote: On Mon, 30 Mar 2015 18:54:42 +1300, Rikki Cattermole wrote: On 30/03/2015 6:35 p.m., ketmar wrote: On Mon, 30 Mar 2015 18:23:11 +1300, Rikki Cattermole wrote: Although I'm a little concerned because dub is meant to validate and tell you conflicts in licenses. O_O Hey hey hey, context matters! i'm speechless 'cause it's a great idea (let machine do it work!), but i'm not sure how this can be done with wide broad of licenses out here. and i definetely want to see std.license.compare in Phobos! ;-) I agree, I'm concerned about this as well. But hey, its one of the features the dub developers want to have. what i really want to have is libdub. i.e. turning dub to library, so it can be easily integrated in any D project (rdmd comes to mind first). i don't want D building abilities, for example, but i really like to use it's package management part (and get list of files and compiler flags for that packages). sure, i can do this by parsing dub jsons and execing dub itself to do package management work, but libdub is better... maybe someday i'll wrote such thing. ;-) Yeah, the vibe.d/dub guys are amazing at getting stuff working. But horrible at abstraction's especially with library code.
Re: dsq-1: open-source software synthesizer
On 30/03/2015 6:02 a.m., D. Martinez wrote: I am releasing today a first version of dsq-1: a software synthesizer modeled after some great 80's hybrid synths, Ensoniq ESQ-1 and SQ-80. The 'd' in the project's name stands for the author's first name, as well as, you know. ;) The source code for the project is currently located on github: https://github.com/martinez/dsq1 This project is a huge work in progress and is far for complete; the sound output is not very interesting in the current state and needs a lot of work. Most of the architecture is implemented according to reverse-engineered information, some done by me, but mostly from Rainer Buchty which has done an extensive amount of work on this machine (cf. his website). My progress is not going fast on this project, because I am currently busy with my Ph.D and other work. I share it because it will interest whoever wants to hack on this machine, because it implements the proprietary formats used (patch, waverom, etc..), or whoever wants to help on synthesis. I happily accept contributions. Working with D has been generally a joy (coming from a C++ background), but there have been a number of annoyances to me, be it bugs or lack of features. I have kept a list of observations, into the project's TODO file. Most importantly: 1. My main grief so far has been the compilers. LDC has failed on me with a stack trace and no other information. This is reproducible on the latest commit, when there exists a dependency to the tkd library. Last time I checked this bug was reported on the issue tracker but not fixed yet. On the other hand the dmd compiler however has been very stable for me. 2. The function attributes: @nogc nothrow. These relate to my realtime audio thread because I want neither of these things to occur; my thread runs unmanaged by the D runtime and I appreciate the static checking. But I don't use it: why? I use writefln a lot to debug my implementations, which is incompatible with either assumption. I wish it were possible to bypass @nogc nothrow in debug mode, only to emit a warning. To change dozens of functions to set @nogc on/off depending on usage context is not practical. I hope D can provide a better solution, than systematic use of sed scripts. :) --- About the project itself for the interested: See TODO.txt for a (non-exhaustive) list of things missing. It has many subprojects, organized as such: - synth: it implements the various parts of the softsynth (EG, OSC, LFO, ...) - jack: softsynth for Linux implemented as a jack client - synthui: user interface (nothing is done right now). not to be used directly, the process is instantiated by the softsynth and communicates via OSC protocol. - synthlib: components that relate to the internal proprietary structures: patches and waves. relevant if one is implementing a librarian for instance - liblo: binding to a OSC client/server library with C API - util: various stuff for implementing and testing. math routines, plotting, fixed point. The fixed-point implementation math.fp is intended as a drop-in replacement for float and is a template for various precisions on 32-bit ints (ie. 16/16, 24/8 etc). - fptest: a playground project for testing fixed-point math - esqtest: a playground project for independently testing internal components of the softsynth (wavetable synth, LFOs...) - banker: what could be a bank management (aka. librarian) application in the future. it can current open and display banks stored on disk (sysex/mdx), but no write support. GUI is horrible. - to appear in the future: vstplug. a vst implementation, which should not be hard to do, possibly using the dplug library. I make this project in the hope to port it to embedded ARM, if it ever gets somewhere. I have some analog CEM VCF chips to use in this project from one of these dead units. The bad thing is that because the unit's dead I don't have a good basis for comparison. So I am aiming for good results, not 100% fidelity with the original. I am not myself very good in math nor DSP programming, so again I welcome the work of contributors. The porting to ARM, specifically STM32F4, will be hopefully an opportunity for me to extend on the work of others on embedded D. link for reference: http://wiki.dlang.org/Minimal_semihosted_ARM_Cortex-M_%22Hello_World%22 That's a rather interesting license. Maybe add a TLDR into your readme? As I doubt most people here have seen it before.
Re: dsq-1: open-source software synthesizer
On 1/04/2015 10:28 p.m., Sönke Ludwig wrote: Am 30.03.2015 um 08:34 schrieb Rikki Cattermole: snip Yeah, the vibe.d/dub guys are amazing at getting stuff working. But horrible at abstraction's especially with library code. Okay. Nobody can be the best at everything. So it was a compliment :) You've done an excellent job with them. And by the looks of things, you are now splitting up e.g. vibe.d So again its mostly past tense observation on that front. I'm kinda the opposite. Great at abstractions. Horrible at getting the damn thing working.
Re: dsq-1: open-source software synthesizer
On 1/04/2015 11:07 p.m., Sönke Ludwig wrote: Am 01.04.2015 um 11:33 schrieb Rikki Cattermole: On 1/04/2015 10:28 p.m., Sönke Ludwig wrote: Am 30.03.2015 um 08:34 schrieb Rikki Cattermole: snip Yeah, the vibe.d/dub guys are amazing at getting stuff working. But horrible at abstraction's especially with library code. Okay. Nobody can be the best at everything. So it was a compliment :) You've done an excellent job with them. And by the looks of things, you are now splitting up e.g. vibe.d So again its mostly past tense observation on that front. I'm kinda the opposite. Great at abstractions. Horrible at getting the damn thing working. I personally usually stay away from using overly strong terms like horrible for online conversations, because it's just far too likely that someone gets offended (I'm usually a fan of good irony for example, but almost never use it online). I agree, I was quite extreme. In reality we're only talking in shades of grey with a difference of maybe 5 (0 .. 255). There is a reason why most people IRL think I'm a jerk. Always take stuff like this with a grain of salt. It's only meant to make people think about the subject, not as a factoid. On topic, I don't think that splitting up the library or not does necessarily have anything to do with abstraction. The library is built in a modular way, so that splitting it up mainly just becomes an issue of the build configuration. If you have other examples of where you think the abstractions are lacking, I'd be interested to know of course. If I was to start doing it, Vibe.d would be next to useless. No you guys are doing a wonderful job. I really can't stress that enough. I generally value good abstraction as important, but that doesn't always mean that the most extreme abstraction is the best one. Abstraction comes at the cost of added complexity (on the library side, but more importantly on the user side) and sometimes at the cost of performance, so it's always a trade-off. There are more types of abstractions than just classes vs interfaces. What goes into a module for example is a prime example of an abstraction. A purpose.
Re: GSoC 2015 - Application Rejected
On 3/03/2015 8:08 a.m., CraigDillabaugh wrote: Unfortunately our organizational proposal for the 2015 Google Summer of Code was rejected. Thanks to everyone who helped out on this, especially to those who volunteered to mentor. I've asked Google to provide me with feedback, and I will post that here once/if I get something from them. If I am not asked to resign I am happy to volunteer for this post again next year. Hopefully I can learn something from this year and any feedback they provide. Cheers, Craig You did a good job. I don't think it was your fault. But as others have mentioned, maybe we should run our own.
Re: Dgame revived
On 23/02/2015 8:01 p.m., Namespace wrote: On OSX you can load either legacy version of OpenGL so 1.x/2.x or 3.x+. Not both. I found this out for Devisualization.Window. Most likely dgame by default is loading it in legacy mode. Derelict GL is loading in legacy mode. You have to call 'reload' after creating a valid GL Context to update your OpenGL to the highest possible version. Maybe that doesn't work on Mac? This does work on OSX. Again Devisualization.Window supports OpenGL context creation for both legacy and non legacy. It is just dependent upon what you specify as the version to load when creating the context that matters.
Re: Dgame revived
On 23/02/2015 11:33 a.m., Gan wrote: On Sunday, 22 February 2015 at 22:32:44 UTC, Gan wrote: On Sunday, 22 February 2015 at 22:29:53 UTC, Namespace wrote: On Sunday, 22 February 2015 at 22:24:59 UTC, Gan wrote: On Sunday, 22 February 2015 at 21:58:13 UTC, John Colvin wrote: On Sunday, 22 February 2015 at 21:34:03 UTC, Foo wrote: I think you need to install the ogg libraries. Derelict, which Dgame uses, only provides bindings to the C/C++ libraries. You still need to get the those libraries for things to work. Sorry I cannot help more. On linux it's just a matter of using the pkg manager (apt, pacman, yum etc.) On MAC I have not idea. I can confirm Dgame 0.4.1 is now working on Linux (Debian x86_64) after I did a dub upgrade. Thanks, amber That is nice to hear. It works for me on Windows 8.1. Someone with a Mac here? I'll try tomorrow if no-one else has. I have a Mac. OS Yosemite 10.10. Macbook Pro 2011. Intel HD 3000, 16gb of ram, i5 CPU. When I run one of your Dgame tutorials I get this error: Derelict loaded GL version: GL21 (GL21), available GL version: 2.1 INTEL-10.0.22 object.Exception@../.dub/packages/dgame-0.4.1/Window/Window.d(144): Your OpenGL version (21) is too low. Need at least GL 3.0. That is strange. Every PC should be be capable to launch at least OpenGL 3.0. Did you try to update your graphic driver? You can't really upgrade your graphics driver on a mac. Stackoverflow says it is possible. One guy's fix was something like: glfwWindowHint(GLFW_CONTEXT_VERSION_MAJOR, 3); glfwWindowHint(GLFW_CONTEXT_VERSION_MINOR, 3); glfwWindowHint(GLFW_OPENGL_PROFILE, GLFW_OPENGL_CORE_PROFILE); glfwWindowHint(GLFW_OPENGL_FORWARD_COMPAT, GL_TRUE); Cause apparently it supports it. On OSX you can load either legacy version of OpenGL so 1.x/2.x or 3.x+. Not both. I found this out for Devisualization.Window. Most likely dgame by default is loading it in legacy mode.
Re: Reloaded for dub
On 21/02/2015 3:00 a.m., Kingsley wrote: Hi Just thought I would share this in case anyone else finds it useful. I wrote a tiny utility that detects changes to D files and then rebuilds and re-executes the main binary using dub. I use for developing with vibe.d and other dub D project that have an executable binary. The code is here: https://github.com/kingsleyh/reloaded essentially you just run dub in the root and it builds the reloaded binary. Then you just copy that binary to the root of your dub project and ./reloaded and then as soon as you make a change to a D file your code will be built and executed. --K *whistles* https://github.com/rikkimax/livereload
Re: Dgame revived
On 26/02/2015 3:57 p.m., Gan wrote:
On Thursday, 26 February 2015 at 02:32:51 UTC, stewarth wrote:
I'd also try hacking in Window.d directly to see if even basic gl
commands work, e.g. immediately after window and context creation, try
rendering a triangle then tweak the context initialisation to see if
it affects anything.
It may help you track down exactly which part of the GL setup is
causing problems.
Cheers,
Stew
I know almost nothing about OpenGL but using your method(sorta):
void reportGLErrors() {
GLenum errCode;
const GLubyte *errString;
if ((errCode = glGetError()) != GL_NO_ERROR)
{
writeln(OPEN GL ERROR: , errCode);
}
}
I get error code 1282 repeatedly.
From a google search someone says:
First, glGetError() will return 1282 - invalid operation if the GL
context is not current (or not yet created). So, create your context
first, then call glGetError. And, verify that any parent class or member
class does not call GL functions in their constructors or prior to
context being created.
Can someone with more OpenGL knowledge clarify what this means?
1. Program starts
2. Window gets created
3. Context gets created
4. Context is activated
5. Profit???
Basically before the context is created and activated you cannot call
any OpenGL functions. If you do, they will error out.
The bit about constructors ext. don't worry about it. Its just about
e.g. where the calls to OpenGL can exist.
Re: dsq-1: open-source software synthesizer
On 2/04/2015 8:42 a.m., Joseph Rushton Wakeling wrote: On Monday, 30 March 2015 at 05:23:18 UTC, Rikki Cattermole wrote: This is a primarily a french license. It took me a good while to understand that it was compatible with e.g. MIT. Compatible in what way? Isn't CeCILL a copyleft license? (It's not 100% obvious to me whether strong or weak copyleft is implied, because their definition of an 'External Module' is unclear: I'm not sure if something is rendered non-external by linking, or merely by static linking, or something else again.) As far as I remember, it should just be ok. The only real issue is with lgpl ext. But again, you can see why I want this clarified.
Re: dsource.org moved
On 25/04/2015 3:33 p.m., Jonathan M Davis wrote: On Friday, 24 April 2015 at 21:48:30 UTC, Stewart Gordon wrote: On 22/04/2015 08:20, Jacob Carlborg wrote: snip If you're forking a project on Github you get your own copy of the project. The projects are linked but the repositories are not. What I mean by that is on your fork you'll see that it is a fork with a link back to the original project. From the original project you can also view all forks. The repositories are not linked in the sense that there's no automatic syncing of code between them. The fork needs to manually pull from the original repository to get the latest changes. I guess the word link has too many meanings. :p So a fork is really a working copy of the master repository, and the code that the user will typically edit is in turn a working copy of this. And commit and push in Git terms basically mean to commit to the local fork and to commit the fork to the master repo respectively. So if pull means to update one's fork, what is a pull request requesting exactly? With git, technically, no repo is more important than another, since it's a distributed source control system rather than a centralized one. Everyone gets their own, independent repo, with its own commit history. Pushing and pulling and whatnot don't care about which repo is the primary repo or anything like that. It's just taking a set of commits from one repo and putting them in the other repo. Committing is _always_ to your local repo. You never commit to another repo. Pushing is when you control both repo A and repo B, and from the machine with repo A on it, you push a set of commits into repo B. It therefore requires that you have the permissions to manipulate repo A directly on the machine that it's on (since you're doing the operation on that machine) and that you have write permissions for repo B (since you're commanding repo B to take your commits from repo A). Pulling is when you do the commands from the machine with repo A on it and take the code from repo B and put it in repo A. You only need read permissions for repo B in that case (so it could be a public repo that you have no control over whatsoever). The typical workflow with github is that you create a branch on your local machine and make commits with whatever changes you're making. You then push that branch into your github repo for that project. So, you've created a branch there which then matches your local branch (and if you need to make further commits, those would have to be pushed separately). Then you create a pull request from your github repo for the target repo (typically the primary repo for the project, but it could be the repo of someone else you're working with). Typically, it's targeting the master branch of the target repo, but it could be for any branch in that repo. Whoever controls the target repo is notified of your pull request. They can then look over the code, suggest changes, etc. Once they're satisfied with it, they can hit the merge button on github. That tells github to pull the code from the branch in your github repo into the target repo. After that, anyone who pulls from the target repo will get your changes. And normally, you'd delete the branch that you used for that pull request and create a new one for whatever your next set of changes are. So, normally, you only push to your own github repo, and everything else is done via pulling. Now, you _can_ just push to the primary repo rather than your own github repo if you have the permissions for it, but then the code doesn't get reviewed, and only folks who have push permissions for that repo can do that (which most folks won't have). Operating that way is basically operating how svn operates, which pretty much everyone using git will tell you not to do. Hopefully, that explanation helps, but you really should read some of the guides out there for this, since they'll have pretty pictures (which can help considerably) and probably explain it better than I do. e.g. https://guides.github.com/introduction/flow/index.html http://nvie.com/posts/a-successful-git-branching-model/ https://blogs.atlassian.com/2014/01/simple-git-workflow-simple/ https://sandofsky.com/blog/git-workflow.html - Jonathan M Davis Also if you are on Windows or OSX, use SourceTree[0]. I cannot recommend this enough. It'll install git, wrap it up nicely for you and even show pretty imagery regarding the current state of the repo! [0] http://www.sourcetreeapp.com/
Re: dsource.org moved
On 28/04/2015 12:56 a.m., Kagamin wrote: On Saturday, 25 April 2015 at 03:36:24 UTC, Rikki Cattermole wrote: [0] http://www.sourcetreeapp.com/ Git got a proper visualization of commit tree? :) Better then anything else out there!
Re: This Week in D #15: hackathon, mem management, ARM, tip for C coders
On 5/05/2015 7:01 a.m., Adam D. Ruppe wrote: On Monday, 4 May 2015 at 03:50:57 UTC, Rikki Cattermole wrote: A pet peeve from the community section might be a great idea! If you ever want to rant, type it up and email it to me, I'll work it in! BTW I also have a window open on my browser somewhere to chat with you about audio stuff. Been pretty busy lately but want you to know that I haven't forgotten! Awesome sweet!
Re: The hackathon week roundup
On 3/05/2015 1:27 p.m., Walter Bright wrote: On 5/2/2015 5:12 PM, Andrei Alexandrescu wrote: On 5/2/15 4:50 PM, Ilya Yaroshenko wrote: * Tutorial: http://d.readthedocs.org (btw should we link that from the homepage?) May I transfer the repositories (both GitHub and RTD) to the D-Programming-Language community? That'd be a fine idea. Thoughts from Walter, Martin et al? -- Andrei I think it's a great idea. It'd have to be Boost licensed, though. Shouldn't it be creative commons because it is more a creative work aka documentation?
Re: dsource.org moved
On 16/04/2015 11:25 a.m., Stewart Gordon wrote: On 08/04/2015 03:21, Rikki Cattermole wrote: On 8/04/2015 9:44 a.m., Stewart Gordon wrote: snip Yes, a set of bindings to eventually put into Phobos/druntime was the aim of the WindowsAPI project from the beginning. But unfortunately, progress has been slow. Instead of moving to Github, this should be done instead. Thanks to package.d files it shouldn't be too hard to up and replace into core.sys.windows.windows. How would we go about committing updates to it when this is done? Stewart. Let's say there is a new function in gdi.h added. You would look for the file: core/sys/windows/windows/gdi.d And add the function declaration. Or if it is a whole new file: Add: core/sys/windows/windows/newFile.d Add line: public import core.sys.windows.windows.newFile; To: core/sys/windows/windows/package.d Basically the same process as now, except spread out across more files.
Re: Sciter, D language SDK port
On 18/04/2015 10:28 p.m., lafoldes wrote: Just found this: http://www.terrainformatica.com/2015/04/sciter-d-language-sdk-port/ s/port/bindings/ But anyway, it looks cool. Although a little tied to WinAPI.
Re: EMSI is hiring a D developer
On 15/04/2015 4:17 a.m., Justin Whear wrote: EMSI is hiring for an Engineer II to work on D codebases: https:// emsi.bamboohr.com/jobs/view.php?id=30 Hum, I think I'll try and see if they don't mind remote workers ;)
Re: dsource.org moved
On 8/04/2015 9:44 a.m., Stewart Gordon wrote: snip Yes, a set of bindings to eventually put into Phobos/druntime was the aim of the WindowsAPI project from the beginning. But unfortunately, progress has been slow. Instead of moving to Github, this should be done instead. Thanks to package.d files it shouldn't be too hard to up and replace into core.sys.windows.windows.
Re: OpenVG bindings
On 4/04/2015 11:53 a.m., ddos wrote: Hi folks, today i've created my first dlang library ^_^ a binding to the OpenVG library standard. The referenced implementation is ShivaVG which allows to draw vector graphics within an OpenGL context (similar to cairo). A small demo application is included, using derelict gl3 and glfw3 https://github.com/oggs91/OpenVG_D http://code.dlang.org/packages/dopenvg Could you please add an example using Devisualization.Window? That way its one less external to D library that is a dependency. https://github.com/Devisualization/window
Re: Coedit version 1 rc1 released
On 5/06/2015 10:34 p.m., extrawurst wrote:
On Friday, 5 June 2015 at 10:24:10 UTC, Rikki Cattermole wrote:
On 5/06/2015 7:43 p.m., Basile Burg wrote:
Coedit, the small IDE for the DMD D compiler is about to become 'gold'.
There 's not much to say since it's been promoted here already 3 or 4
times.
https://github.com/BBasile/Coedit/releases/tag/1_rc1
beta 2 3 had not been announced officialy, so don't forget to read the
previous change logs. This version is distributed, as previously, in a
simple archive but also with an installer. I encourage you to test it
and to report any problem.
version 1 'gold' should be released the 10 of June, exactly 1 year after
the first commit.
Ideas:
- Put background shading/box around highlighted {}. To make open/close
be more prominent.
- For pointers, have the type highlighted one level darker then the *.
So e.g. type** would be [[[type]*]*] where [] indicate shading level
when the last * is highlighted over.
* Make source file close have a button. Its not obvious enough to use
the keyboard shortcut. I accidentally closed the widget thinking I was
going bye bye to the file.
Bugs:
* Message widget was very temperamental to the point of erroring out
when resizing (as it took up the entire middle area).
* When e.g. source code widget is external to main window it will open
in the most minimalistic form if the main window gets minimized and
reopened.
* __gshared, @nogc, @property not highlighted.
Atleast for me, without dub support I can't use it. Although if
debugging support existed on Windows that would be a massive plus.
https://github.com/BBasile/Coedit/issues/10
I was just reiterating that point.
Oh and if compiler cannot be found, make it a LOT easier to configure
it. As in I have compiler e.g. dmd here. Now use it.
One thing, perhaps for atleast Windows, support e.g. ldc out of the
box. As a seperate no install package.
Re: Coedit version 1 rc1 released
On 5/06/2015 7:43 p.m., Basile Burg wrote:
Coedit, the small IDE for the DMD D compiler is about to become 'gold'.
There 's not much to say since it's been promoted here already 3 or 4
times.
https://github.com/BBasile/Coedit/releases/tag/1_rc1
beta 2 3 had not been announced officialy, so don't forget to read the
previous change logs. This version is distributed, as previously, in a
simple archive but also with an installer. I encourage you to test it
and to report any problem.
version 1 'gold' should be released the 10 of June, exactly 1 year after
the first commit.
Ideas:
- Put background shading/box around highlighted {}. To make open/close
be more prominent.
- For pointers, have the type highlighted one level darker then the *.
So e.g. type** would be [[[type]*]*] where [] indicate shading level
when the last * is highlighted over.
* Make source file close have a button. Its not obvious enough to use
the keyboard shortcut. I accidentally closed the widget thinking I was
going bye bye to the file.
Bugs:
* Message widget was very temperamental to the point of erroring out
when resizing (as it took up the entire middle area).
* When e.g. source code widget is external to main window it will open
in the most minimalistic form if the main window gets minimized and
reopened.
* __gshared, @nogc, @property not highlighted.
Atleast for me, without dub support I can't use it. Although if
debugging support existed on Windows that would be a massive plus.
Oh and if compiler cannot be found, make it a LOT easier to configure
it. As in I have compiler e.g. dmd here. Now use it.
One thing, perhaps for atleast Windows, support e.g. ldc out of the box.
As a seperate no install package.
