gren

"Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away."

Antoine de Saint-Exupery

Nope this is not what happened. Play team made the decision months before to start moving to Scala when experimenting the play-scala module of Play1.

This is a technical decision to build a web framework to the JVM. And even if the core is written in Scala, it doesn't mean you can't use it in Java. Give a try!

Making stronger apps?

Let's take the Play 1 vs Play 2 example:

How many times I got a 500 pages in the face due to a basic NullPointerException in Play 1 groovy templates...

In new play 2 templates, because they are type-safe, they guarantee that you will not have those basic errors.

Of-course, it doesn't guarantee everything, but it's way less error-prone. You actually CANNOT make this kind of NPE errors with type-safe scala code.

where in java you do something like:

user.address.town // oops I forgot to test if user.address is not null

in scala:

// user.address.town wouldn't work, because address is represented as an Option[Address]

user.address.map(_.town).getOrElse("")

My two cents:

- non-blocking IO with the powerful iteratee concepts (a nice approach to play with streams (EventSource/WebSockets/*) which is not only an event-based approach like in NodeJS, but more a "reactive" approach)

- functional approach of things with Scala

- everything is much more type-safe (especially templates) which make apps stronger (not prone to simple error like NPE in templates) but also faster (templates are compiled)

I don't really like this dark header in contrast with the body. Also the dropdown menu dark border looks horrible IMHO.

The rest is quite ok! :-)

aha! same for me ;)

Brilliant!

"Teleportation turns out to be extremely useful." <= lol! Who doubts it?

Thanks!

you can refresh / bookmark / share the page URL at any time and you will retrieve your work.

And also I don't have to store anything on my server, bit.ly like services are the new way of storing the information :)

you are right! For sure it would be more efficient, and shaders are incredibly powerful. I have considered that, but it wouldn't work everywhere today. So for now I have this implementation I will use for my web games ;)

Thanks for that, it was always unclear in my mind, now it's clear!

ok so I'll move it to LGPL soon then ;)

Yep, This is what I want for Illuminated.js. I prefer to have benefits of the library modifications. It's a bit more restrictive coming from MIT (I used to use it for some projects) but it's not as restrictive as a "non-commercial only" license, so IMO it's quite ok, it's a minimum of thanks to the library.

Regards

Thanks.

Yeah, I need to fix that, this is link to my wrong sampling implementation.

If you use only 1 sampling you will see it is fixed.

This is what I do except I use drawImage.

You think using getImageData and putImageData is more performant that drawImage(canvas, 0, 0) ?

BTW i'm not sure it will works for combining images together with special composite operation.

AFAIK, with GPL you are allow to use the library in a proprietary project but if you modify it, you must publish the library modification, not the whole project.

Am I wrong?

eah I think the default scene use too much samples, like 51 for the right light.

Now my technique of combining shadow samples together is probably not the most efficient, I draw them with source-over and an alpha which is also a wrong hacky current implementation... but maybe using the CanvasData would be less efficient (technically I need to make the average of shadow samples' grayscales) - well we never know, I haven't tried yet ;)

I would be happy to have any contribution in the library :)

Sorry for that, I though having this

    history.replaceState({}, title, "#"+hash);

would have fixed it.

( https://github.com/gre/illuminated.js/blob/master/demo.js#L1... )

Any idea?

you are right, I ignore the light if its center is inside an object, it was before I implement these samples. I should still fix it, maybe it's just by removing this check but I remember having some strange effects.

Mmh unfortunately requestAnimationFrame() seems to be very "greedy", it seems its strategy is to consume as much resource as possible (if the render() is not enough fast).

Performance has been my focus on this work, I use a lot a cache canvas to not redraws gradient and path things but just copy caches. But i'm stuck on Canvas and requestAnimationFrame performances. Let's hope it will continue to improve, otherwise I could try to use WebGL but it will not be supported by every browsers for today.

Do you use a lot of sampling in the lights? I reach good fps on my macbook pro, especially on Chrome (but also on my home computer under Linux).

I hope we can use it with less sampling and less compute() calls for our games :)

This is a bug for me, it seems we have a discontinuous function in the Code Du Travail !

It seems not to work on Linux.

I like CoffeeScript but I see it as a temporary language providing cool syntax features on top of Javascript.

no offense but IMHO, we should focus on releasing the next Javascript and make it possible instead of writing better CoffeeScript compilers.

give Play 2.0 a try guys, it's a fresh new framework, more robust than ever, and with awesome concept for handling Input/Output.

Hi rkalla and thanks for your feedback.

The idea behind Play2 is to have a framework written in Scala (the core) but providing a full API for both Scala and Java languages. Hence, users can choose their preferred language to write web applications.

Mmh sorry for that, that's strange I thought Youtube has HTML5 video support - moreover i've encoded my video in WebM format.

so true. public is public. Anyone could have data mined all these twitts... But the difficult question that may rise is the "right to delete". IMO it's a hard dilemma: history VS privacy. Can someone decide to delete all its trace and destroy everything he built? On the other hand, we need to keep trace of what's happened in the past, don't you think?

totally agreed. I've been listening to di.fm and Armin Van Buuren week shows for 5 years.

What about this one: https://github.com/search?type=Code&language=JavaScript&...

I would love to have this system for documentations and articles. Imagine if you let people easily improve texts, fix spelling mistakes, or translate pages, for documentation you wrote.

More generally, this would be awesome to use on a wiki.

This makes editing even more accessible.