« first day (267 days earlier)      last day (3594 days later) » 

00:00
RELOAD!
[Cardshifter/Cardshifter] 17 commits. 1 closed issue.
[retailcoder/Rubberduck] 7 commits. 1 closed issue. 23 issue comments.
[rolfl/MicroBench] 5 closed issues.
[skiwi2/Calculator] 3 commits.
[Vogel612/JavaBot] 3 commits.
 
9 hours later…
09:00
@Simon, don't forget to fix Facebook Graph 2.0 in Minesweeper for Android!
 
1 hour later…
10:29
hey
 
2 hours later…
12:07
> Split the tokenize method into a tokenize and an to_rpn method.
The tokenize method splits the input into a lists of token, which also takes care of the unary/binary minus/plus issue.
The to_rpn method puts a list of tokens into RPN form.
Added operators, supported operators now are -, +, * and /.
@Duga But I don't want to!
TTQW!!
@SimonAndréForsberg So you just kill @Duga here ^^... nice :P
12:22
@SimonAndréForsberg You have to!
@skiwi just had to restart it apparently...
13:02
Hey all! @SimonAndréForsberg if you look at the update-css branch, I've made some minor changes to the website. You could look when you had time to see if you like thoses changes. In fact, anybody can give feedback I would gladly take it
13:21
And now that I'm doing some rails, it's amazing how you can test almost everything! Bang out of the box you can do integration tests with your code without much trouble.
13:43
@Marc-Andre Ruby on Rails?
14:05
Time to go have a nice day all!
 
2 hours later…
15:35
hey again
 
2 hours later…
17:06
> Simple solution for now: Retrieve comments once every minute instead of every two minutes. Works fine for now.
> This is not fixed. It is confirmed to not be because of the comment scanning though.
[Zomis/Duga] Zomis pushed commit 66a381db to master
> added truncation of very long issue descriptions and comments
[Zomis/Duga] build #35 for commit 66a381db on branch master fixed
[Zomis/Duga] Zomis pushed commit 5eda00f2 to master
> added repository to ping event, fixes #72
[Zomis/Duga] Zomis pushed commit b977b301 to master
[Zomis/Duga] build #36 for commit b977b301 on branch master passed
17:23
in Duga's Playground, 10 secs ago, by Duga
[Zomis/test] Ping: Avoid administrative distraction.
in Duga's Playground, 16 secs ago, by Duga
[Zomis/test] Zomis pushed commit c2890771 to master: commited some stuff
@SimonAndréForsberg Yaay!
17:50
[skiwi2/Calculator] skiwi2 pushed commit d19f2c1e to master: Tokenizing now no longer needs extra whitespace characters to be able to parse properly.
[skiwi2/Calculator] skiwi2 pushed commit 81debae0 to master: Removed superfluous whitespaces from tests.
@SimonAndréForsberg Cool, huh?
Monking :D
hey @sᴉɔuɐɹɥԀ
18:07
[skiwi2/Calculator] skiwi2 pushed commit f49c3e57 to master: Cleaned up main application code and improved usage syntax hint.
18:56
@Marc-Andre Is it fairly easy to set up STS to do JavaScript?
@sᴉɔuɐɹɥԀ Why would you use STS to do JS?
Well, I use STS for most things I code, including the Cardshifter website. So I assume it can do JS just fine as well...?
@sᴉɔuɐɹɥԀ Sure you can. But you probably won't get code completion, syntax highlighting, etc... but perhaps @Marc-Andre has some trick for that.
It has syntax-highlighting for HTML & CSS, interestingly
/**
 * Enum that represents various player resources:
 * MAX_HEALTH, SNIPER, DOUBLE_ATTACK, TAUNT, DENY_COUNTERATTACK, HEALTH, MANA, MANA_MAX, SCRAP,
 * ATTACK, MANA_COST, SCRAP_COST, ENCHANTMENTS_ACTIVE, SICKNESS, ATTACK_AVAILABLE
*/
var PhrancisResources = Java.type("net.zomis.cardshifter.ecs.usage.PhrancisGame.PhrancisResources");
@SimonAndréForsberg Do you think this JSDoc^^ is also redundant/not particularly useful?
19:15
@sᴉɔuɐɹɥԀ that is probably one of the more useful ones
\[[**Cardshifter/Cardshifter**](https://github.com/Cardshifter/Cardshifter)\] [**Phrancis**](https://github.com/Phrancis) pushed commit [**33210b35**](https://github.com/Cardshifter/Cardshifter/commit/33210b35b0cfebe0b1f54088e0d06ed8276aa891) to [**PhrancisGame-JSDoc**](https://github.com/Cardshifter/Cardshifter/tree/PhrancisGame-JSDoc): Update test.js

Cleaned up JSDoc to remove redundant code doc.
@Duga Huh, that's ugly
@SimonAndréForsberg ^^ Are you good with this being merged?
19:25
[Cardshifter/Cardshifter] build #812 for commit d8b8d464 from pull request #189 to branch js passed
@sᴉɔuɐɹɥԀ ah. I understand why that happens. You're using line feeds in your commit message....
Oh. Gotcha
@sᴉɔuɐɹɥԀ sure. Want me to merge it now or later?
Now is fine
19:28
[Cardshifter/Cardshifter] Zomis pushed 5 commits to js
\[[**Cardshifter/Cardshifter**](https://github.com/Cardshifter/Cardshifter)\] [**Zomis**](https://github.com/Zomis) pushed commit [**f83a5b9a**](https://github.com/Cardshifter/Cardshifter/commit/f83a5b9a28e926b0b27f7088f9f0bc14f75cdbe3) to [**js**](https://github.com/Cardshifter/Cardshifter/tree/js): Merge pull request #189 from Cardshifter/PhrancisGame-JSDoc

merged with PhrancisGame-JSDoc
[Cardshifter/Cardshifter] Phrancis deleted branch PhrancisGame-JSDoc
> Cleaned up JSDoc and merged in js branch.
> With #79 now implemented, if you make a multi-line git commit message, it shows up very badly in chat. For example, see http://chat.stackexchange.com/transcript/message/21313123#21313123

Two options for fixing that I can think of:

1. Strip all new-line characters from commit message when posting in chat.
2. Post multi-line commit messages as multi-line
@SimonAndréForsberg Let's just say I wanted to add to the JS branch... is there any way the code can be tested at all prior to the whole PhrancisGame.java file is "translated"?
(as in, test individual sections of the JS module)
[Cardshifter/Cardshifter] build #813 for commit f83a5b9a on branch js passed
@sᴉɔuɐɹɥԀ Run the server locally, run the client, start a game with the "JS" mod and see what happens :)
Ah, sounds fun lol. Is JS actually selectable in the client??
20:04
Microbench queued up for release to maven-central, @Simon
2
@Duga And that's exactly why I had them multi-line
Though having single-line messages on a single line is a good solution IMO
@rolfl Nice!
Somehow it feels good to actually have code that is on Maven Central.
Well, this puts ^^^
that
20:09
Even though it's not myself that is doing the actual pushing to Maven Central, I know that code that I wrote is there.
I guess I should/could have pushed it two weeks ago, but, even now, I am not happy with it. The code is not consistent'
I was going to do more before I released 0.2.0
@rolfl we still haven't put it up for review also...
I am trying to get comfortable with the "release embarrassingly early" philosophy
Everything imperfect before release 1.0.0 on Maven Central is still absolutely fine
@SimonAndréForsberg No, I put the HTML/CSS question about tables up for review.
20:10
@rolfl I don't think this is embarrassingly early
but nothing else.
Meh, I do ;-)
What's embarrassing about it?
Well, there's good reports in HTML/JS/D3 for the scaling, but nothiung like that for the performance.
there should be cool bar-charts with relative performance.
there should be histograms with spread.
there should be performance-over-time after JIT
All those are bonus-features :)
The logging in UScale is better than UBench
There are a number of things that are messy still
On the other hand, I worked with JS1 on a UBench-related problem, and it was ugly having the code I was running not the same as maven
20:14
@rolfl What you are describing there are all features that can be added at a later point
I see nothing ugly about it
Well, the release I did sort of shows that I agree.... but, it is still embarassing according to my standards.
Now if you were to do a full commercial release, then yes you do want to have a set of features supported from the release onwards, but this is just continuous software development
I just have to lower them
Release early, release often - Get small amounts of feedback as you release, and once you are satisfied with your feature set then start marketing your program
Marketing/Advertising/Promoting - Even though it's not a commercial product, you can still try to get it out to the public
Releasing early is not the same thing as embarrassingly early. If the code would have a billion bugs, that would be embarrassing.
20:20
@SimonAndréForsberg That wouldn't even pass the tests
(If you have them)
We do have some tests.
> Add support for something like 4 > 2 ? 3 : 0
@Duga That will be a challenge
20:38
@SimonAndréForsberg How do you intend to implement that?
What's the expected output of that?
[Zomis/Calculator] Zomis pushed commit b7b9a025 to master: added a method to tokenize a string into... tokens!
[Zomis/Calculator] Zomis pushed commit 2907fe85 to master: ignoring empty value tokens
[Zomis/Calculator] Zomis pushed commit 1e00d612 to master: speed up of tokenizing by skipping spaces, digits and decimal separators
@skiwi expected output is 3. Because 4 > 2. Same as if it were Java code.
[Zomis/Calculator] Zomis pushed commit 680ba9cf to master: fixed some more empty tokens
@skiwi How to implement? At this point: No freaking clue.
[Zomis/Calculator] Zomis pushed commit e66a2eea to master: added a tokenize test
20:48
@SimonAndréForsberg Oh oops, I didn't fully read that one then...
How does that make sense in a calculator though?
@skiwi In my calculator it makes sense!
Perhaps I should find a better name for my "calculator"...
Java looks so verbose, damn it, I can't hate Java!
def test_tokenize_simple_expression(self):
    calculator = Calculator()
    expected = [
        ValueToken(Decimal(2)),
        OperatorToken('*'),
        ValueToken(Decimal(3))
    ]
    self.assertListEqual(expected, calculator.tokenize("2 * 3"))
Java is verbose. That's nothing new. But honestly, I don't think it is necessarily a bad thing.
@SimonAndréForsberg It could be less verbose on parts, but static typing is a good thing (tm)
Oh yes. Thanks for reminding me again why I like Java!
21:04
[Zomis/Calculator] Zomis pushed commit 8b6557ca to master: removed unnecessary outer while loop in tokenizing
[Zomis/Calculator] Zomis pushed commit 67678c66 to master: added ( as a stand-alone token and added another test
@SimonAndréForsberg Adding a LeftParenthesesToken instead of a LeftParenthesesToken() to a list... Nobody will care, for a while
> There have been multiple options thrown around on how to store/load card data into a game instance. Currently, we're using a custom file format (`.cards`) file stored in extra resources directory. There's also the options of using a common data format, like JSON or XML. Whichever one we end up using, I think we need to settle on one format.

With some of the game logic being moved to JavaScript, JSON seems like a natural choice. But, is it easy enough for an "outsider" (a modder, etc.) to u
[Zomis/Calculator] Zomis pushed commit 614cc089 to master: rewrote a bit of the tokenization method. Not sure if it became better or worse...
> Core Java server can handle anything you throw in its way. It is the most flexible of them all.

Personally, I don't think XML is a good choice.

The main 'problem' about the data format is that it somehow needs to be able to define effects in it. The `.cards` format handles this by calling Java methods with reflection, which is not a very flexible approach. Although that cards format can be enhanced to support such features somehow, I think JSON might be the best option here.

I do not
> Referencing Issue #183
> @Zomis Do you think JSON along with JS could be an effective way to define effects? Or do the effects necessarily need to remain in the Java core code?
[Zomis/Calculator] Zomis pushed commit 66a16e18 to master: added different Token classes, passing along the real data to them
21:34
@Duga I'm seeing ValueToken and OperatorToken, nice ;)
@Simon it's pretty abstract idea right now, but let's say we had a JS module like CardEffects.js that defined the effects, could something like that be called from JSON data?
> It should be possible to define effects externally, which is one big reason for why the JS branch exists. JSON and JS could be a solution to define these effects.

To be sure about that though, I think it is a good idea to come up with several example effects, both simple and advanced ones, and show how we would want them to be implemented with whatever format we go with.
@sᴉɔuɐɹɥԀ Nothing is impossible.
@skiwi Thanks!
@Simon on a side note, I just listened to this podcast, and I think you would find it interesting, if you find the time: npr.org/programs/ted-radio-hour/401734785/…
I got the tokenizing to work now (but I am suspecting it can be done in a cleaner way), so now I have to pass it through the Shunting-yard algorithm and then let's see what we end up with...
@sᴉɔuɐɹɥԀ TED? Tends to be good quality stuff. Only 9-10 minutes? I could surely give it a listen.
21:40
> Do you think it would be a good start to try to implement currently existing effects using another format? Or come up with something completely new?
@SimonAndréForsberg The full show is about an hour
But it is, indeed, very good quality content
@Duga @sᴉɔuɐɹɥԀ By "something completely new", do you mean new format or new effects?
> When a websocket loses connection without being marked as offline, big fat error happens causing all other clients that connect receive an error message because the server cannot send a message to this websocket:

[2015-04-26 23:39:52,721] INFO ClientWebSocket [WebsocketSelector21] ( ClientWebSocket.java: 44) - Sending to client: com.cardshifter.api.outgoing.ClientDisconnectedMessage@2abbd36a - [0, 0, 0, 42, 0, 0, 0, 10, 0, 100, 0, 105, 0, 115, 0, 99, 0, 111, 0, 110, 0, 110, 0, 101, 0,
> The current existing effects are quite simple. I think we pretty much only are using "At the end of your turn, heal 1 hp". Coming up with new effects and coming up with examples for how we would want those to look in JSON/JS format would be good.
22:00
@SimonAndréForsberg New effects

« first day (267 days earlier)      last day (3594 days later) »