Re: Better watch out! D runs on watchOS!

2015-12-31 Thread Jacob Carlborg via Digitalmars-d-announce

On Wednesday, 30 December 2015 at 20:55:44 UTC, Dan Olson wrote:

I'm going to start with Plan B.1 though because LLVM does nice 
optimizations for TLS.


What is Plan B.1?

--
/Jacob Carlborg


Re: Better watch out! D runs on watchOS!

2015-12-31 Thread Joakim via Digitalmars-d-announce
On Thursday, 31 December 2015 at 10:10:20 UTC, Jacob Carlborg 
wrote:

On Wednesday, 30 December 2015 at 20:55:44 UTC, Dan Olson wrote:

I'm going to start with Plan B.1 though because LLVM does nice 
optimizations for TLS.


What is Plan B.1?

--
/Jacob Carlborg


Getting it into llvm:

http://forum.dlang.org/post/m237um75x7@comcast.net


Re: Better docs for D (WIP)

2015-12-31 Thread Andrei Alexandrescu via Digitalmars-d-announce

On 12/30/2015 10:07 PM, bachmeier wrote:

On Thursday, 31 December 2015 at 02:40:17 UTC, Andrei Alexandrescu wrote:

I agree and I'm sorry we're not moving faster with reviews, but really
that's not ddo(c|x)'s fault.


Any chance you can respond to this question that I posted two days ago?

http://forum.dlang.org/post/pdjfvsmvdewwtjoic...@forum.dlang.org

It doesn't require a review and only needs an answer of "yes" or "no".
One of the nice things about Adam's site is that it has his email
address on the front page.


Yes, linking from the official site to the wiki is perfectly fine and 
recommended. Thanks! -- Andrei




Re: Better docs for D (WIP)

2015-12-31 Thread Adam D. Ruppe via Digitalmars-d-announce

On Thursday, 31 December 2015 at 06:39:27 UTC, Israel wrote:
This is what hits me the most. Thats why we suggested "user 
contributed examples". PHP docs is the only place ive seen 
this. What is your stance on this and if you agree, how would 
you implement it? How would it work?


I do not agree with comments, but I do agree with making user 
submissions easy.


What I am envisioning right now is a kind of suggestion box thing 
on an individual page, where you can write up a bug report, an 
example, a comment, whatever, and have it emailed to me for 
further consideration. I'll do a quick fact-check editing then 
add it to the page.


Of course, you can also continue to submit pull requests through 
github (and I'd encourage this for bigger contributors), but just 
emailing your thoughts to me has a lower barrier of entry.


If we do a good job with the actual docs, you won't need 
comments. And better yet, you won't have to read through dozens 
of old ones to find the thing you need. On PHP, I find the 
comments list is too long and of too low of an average quality to 
be worth reading most the time.



The other important thing is being able to add new pages with 
ease. I just dreamed up this plan while in bed last night: a new 
page would be a D file with a huge leading comment and a bunch of 
documented unit tests. (Why a regular D file? Because then we can 
reference it by its name, it can be listed in the package listing 
automatically, and you can actually compile it to test the code 
without any extra extraction work!)


A comment at the top of "// just docs: Some Page Title" tells the 
generator to format it as a page rather than a normal module 
(this means the title in the comment will be used instead of the 
module name and it will have a table of contents of text sections 
instead of D classes, structs, and other members.)




I'll make a web service where you can upload your .d file and get 
an instant preview. This way, you can render it without needing 
to figure out how to install my doc generator and build the 
website on your own computer. Just submit the form.


Then, if you like it, you can either email the file to me and 
I'll take it from there, or submit a pull request to add your 
file.


The PR will only need to do:

git checkout -b my_new_file
git add my_new_file.d
git commit my_new_file.d -m 'add my new file!'
git push


No need to edit other macro files, build files, TOC files, 
whatever. My infrastructure takes care of that automatically. 
(via build **/*.d. It isn't rocket science and it baffles me that 
the official D system is so convoluted.)



What do the files look like? Well, I'm still working on nailing 
this down, but it is basically a hybrid of markdown and ddoc, but 
it does NOT support ddoc's custom macros. First off, I think they 
are a mess with everyone defining the same all over (look at 
Phobos, it gets confusing) and secondly it makes doing semantic 
analysis of the text harder since a ddoc macro is freeform. With 
unlimited macros, any $ or comma in the text might be significant 
syntax! That's a pain.


And it leads to bugs. Take a look at the References section here:

http://dlang.org/phobos/std_base64.html

It says "RFC 4648 - The Base16". The title is actually longer 
than that... it just had a comma in it and ddoc thought that 
meant end of argument.


There *are* ways to handle this in ddoc, of course, and they 
aren't even really hard. I deal with it every week in the TWID 
source. But it is just one little example of a bigger problem 
that limits how much automatic processing we can do. Not worth it.



Anyway, this is what contributed article file might look like. It 
continues to the end of this email:


// just docs: Introduction to my new doc system
/++

This is the intro line.

An intro paragraph. This is seen on the article listing too. Then 
leave two blank lines gap for the table of contents.



Now you start writing details. You can have headers, code 
examples, and so on like in any other doc.


$(H2 The headers look like ddoc macros)

They translate to the corresponding HTML and are parsed to form a 
table of contents which is automatically inserted in the blank 
area you left above.


$(H3 You can descend in with headers)

This section would be a sub-section of the H2 above.

$(H2 References and code)

You reference items with $(REF std.xml) and write code with 
`markdown style` or


---
ddoc style
---

More to come as it develops.

+/
module mydocs.intro; // you give it a D name to refer to in refs

/// you can also include documented unittests as full examples
/// that will be attached. I need to think of some way to
/// reference them in the text. If only D had named unittests!
unittest {
   // this code can actually be compiled with dmd -unittest
   // right out of the box to keep your examples working well.
}

// all done.


Damage Control: An homage to Rampart (Alpha)

2015-12-31 Thread rcorre via Digitalmars-d-announce
"Damage Control" is a game inspired by one of my old favorite 
SNES games, Rampart (ok, technically an arcade game, but I had it 
on SNES).


The project is on Github: https://github.com/rcorre/damage_control

Its very incomplete, but if you don't mind spending a few minutes 
trying it out I'd really appreciate it.
You can grab a binary from the Github releases page  or try to 
build it yourself. The content building is a bit involved, but if 
you just want to build the source you can copy the content folder 
from a release package.


It is made with Allegro using the DAllegro bindings. The linux 
build is statically linked to Allegro so you shouldn't to install 
it, but the rest of the dependencies are shared. Let me know if 
any are problematic.


The Windows build just comes packaged with a few dlls, including 
allegro-monolith.


Any feedback is appreciated -- either drop a comment here or file 
an issue on Github.


It will write save data and settings to 
"~/.config/damage_control" or "%APPDATA%\local\damage_control". 
You can change this using the --savedir flag.


There's no included tutorial as I'm hoping the gameplay will be 
pretty self-evident (let me know if it isn't!).


Re: Damage Control: An homage to Rampart (Alpha)

2015-12-31 Thread Ivan Kazmenko via Digitalmars-d-announce

On Thursday, 31 December 2015 at 16:43:53 UTC, rcorre wrote:
"Damage Control" is a game inspired by one of my old favorite 
SNES games, Rampart (ok, technically an arcade game, but I had 
it on SNES).


The project is on Github: 
https://github.com/rcorre/damage_control


Its very incomplete, but if you don't mind spending a few 
minutes trying it out I'd really appreciate it.
You can grab a binary from the Github releases page  or try to 
build it yourself. The content building is a bit involved, but 
if you just want to build the source you can copy the content 
folder from a release package.


It is made with Allegro using the DAllegro bindings. The linux 
build is statically linked to Allegro so you shouldn't to 
install it, but the rest of the dependencies are shared. Let me 
know if any are problematic.


The Windows build just comes packaged with a few dlls, 
including allegro-monolith.


Any feedback is appreciated -- either drop a comment here or 
file an issue on Github.


It will write save data and settings to 
"~/.config/damage_control" or "%APPDATA%\local\damage_control". 
You can change this using the --savedir flag.


There's no included tutorial as I'm hoping the gameplay will be 
pretty self-evident (let me know if it isn't!).


Nice to see someone use D + Allegro for a game.  Did that too but 
have made only few Speedhack-level pieces from scratch so far.


The windows binary works for me, at least for the few minutes I 
had to try it.


The game flow is not obvious in multiple respects:
1. Shoot: why only six bullets?
2. Rebuild: huh, what's the plan?
3. If the base is not completely enclosed by walls after rebuild, 
the game ends, giving a ?!?!? impression.  Took me a few attempts 
to guess the requirement to proceed.


Crashed it :) with S-S-J-J-J-Esc pressed at start (controls -> 
keyboard -> make an action with an unassigned key and press Esc).


Thanks for sharing!



Re: Damage Control: An homage to Rampart (Alpha)

2015-12-31 Thread rcorre via Digitalmars-d-announce
On Thursday, 31 December 2015 at 17:16:32 UTC, Ivan Kazmenko 
wrote:


The game flow is not obvious in multiple respects:
1. Shoot: why only six bullets?
2. Rebuild: huh, what's the plan?
3. If the base is not completely enclosed by walls after 
rebuild, the game ends, giving a ?!?!? impression.  Took me a 
few attempts to guess the requirement to proceed.


1. I was hoping the animation of sending ammo from the bases to 
turrets would make it obvious that bases grant 6 ammo each. In 
Rampart, enclosing bases just let you place more turrets, and 
there was no concept of ammo, which is probably easier to 
understand.


2. Yeah, this is probably what needs the most explaining, 
because...


3. It's probably not obvious why you lose the first few times. I 
guess a 'you have no enclosed territory' message on the failure 
screen might help a lot.


I'll probably try to include some sort of quick tutorial. Thanks 
for the feedback!




Crashed it :) with S-S-J-J-J-Esc pressed at start (controls -> 
keyboard -> make an action with an unassigned key and press 
Esc).


Yup, that sure does crash it :)
Whenever you map a key that's already assigned, its supposed to 
jump to the previously assigned action so you can reassign it. 
Esc was actually mapped to 'menu' (opens the pause menu in-game), 
but I forgot to include that in the controls menu (so maybe it 
wasn't even obvious there _was_ a pause menu).


Thanks!