Commits
-------
814cefd improve test coverage and support negative int for random function
Discussion
----------
improve test coverage and support negative int for random function
Commits
-------
a15e8f7 typo again
2561aa2 typo
faa90c9 updated doc for random function
fe66358 added tests for random function
6f5ceee Made the random function more versatile
Discussion
----------
Made the random function more versatile
The point is to meet user expectations and to make it more versatile, so it works under more circumstances.
At the moment the random function does only return the supplied parameter when it's not an array. That is not very useful. With this PR it will behave like
random() => integer as with mt_rand()
random(5) => integer between 0 and 5 as with mt_rand(0, 5)
random('foobar') => random character from 'foobar'
random(array(...)) => random element
I will add tests and documentation if you accept this PR.
---------------------------------------------------------------------------
by fabpot at 2012-01-26T07:29:35Z
Looks good to me. Can you update the docs and add some unit tests?
---------------------------------------------------------------------------
by Tobion at 2012-01-26T11:50:17Z
ready
Commits
-------
e81a9e2 Improved random function
Discussion
----------
Improved random function
- dealing with empty array (otherwise PHP warning is raised)
- using array_rand() and thus saving the $keys variable
---------------------------------------------------------------------------
by Tobion at 2012-01-25T12:41:32Z
How about allowing `mt_rand ( int $min , int $max )` with optional parameters to be used when the $values ist not an array?
This would solve use case #612
Commits
-------
0d656f5 Add comments
0255764 Updated CHANGELOG
b327a48 Protect the Parser against recursive parsing issues
Discussion
----------
Make the parser Inception-Proof
Spent half a day debugging before I realized what happened, but I'll try to keep a long story short:
When the cache is empty, and the first template containing an assetic `{% javascripts %}` or similar tag is parsed, it will build up the assetic "assets" or recipes cache, this in turn will tokenize and parse all your templates to find assetic tags and cache that information.
At this point the parser is parsing something else in the middle of a parse() call, and since there is a single instance in the environment, it means all the instance vars are messed up and contain incorrect references to the latest TokenStream that was parsed by assetic, etc.
This had two effects on my application, both appearing seemingly randomly because it highly depends on the order of things, the state of your cache and probably other factors:
- The first thing that happened is that a template was compiled using the wrong template filename, which means I had a `__TwigTemplate_abcd` in the file named `dcba.php`, and it would never find the right class.
- The second issue (could not reproduce but I assume it was caused by this as well) is that the parse tree is completely broken and you end up with a parse error because it thinks it's at the end when it's not, or similar problem.
The proposed fix basically pushes/pops all the vars into a stack whenever the parser starts/stops, which worked very effectively here and does not introduce much breakage or complexity.
---------------------------------------------------------------------------
by stof at 2012-01-24T17:28:06Z
@Seldaek are you able to create a reproducible testcase for this (which should be failing before this fix) ? It would avoid further regressions
---------------------------------------------------------------------------
by Seldaek at 2012-01-24T17:45:37Z
I'll try to improve on this according to feedback tomorrow. I saw this enough for today :)
---------------------------------------------------------------------------
by fabpot at 2012-01-24T17:45:49Z
I'm writing some unit tests
---------------------------------------------------------------------------
by Seldaek at 2012-01-24T17:47:02Z
Ok then I'll add @dzuelke's comments real quick.
Commits
-------
43ebae1 Reset parsers, visitors, filters, tests, functions when a new one or new extension is added
3db62da Reset globals when a new global is added
Discussion
----------
Reset globals when a new global is added
if getGlobals() is called before adding a new global, it is never taken into account
---------------------------------------------------------------------------
by fabpot at 2012-01-16T14:27:02Z
Is it related to #594?
---------------------------------------------------------------------------
by Seldaek at 2012-01-16T14:30:08Z
Seems like it yes. It means that reading globals + writing + reading again will call getGlobals on all extensions again though.
A slight improvement would be to cache the extension globals in another var that can be re-applied at once over the staged globals.
The fastest would be to just set directly in ->globals if it's already initalized, but that means addGlobal can override extension globals. Not sure if that is a problem, but it creates a somewhat non-deterministic factor.
I can adjust as required.
---------------------------------------------------------------------------
by stof at 2012-01-16T14:45:49Z
@Seldaek shouldn't the same be done for other methods (filters, functions, tags, tests and operators) ?
---------------------------------------------------------------------------
by Seldaek at 2012-01-16T14:53:28Z
Indeed, I was just focused on my crazy issue here :) Once @fabpot decides which way he prefers I can apply it to everything.
---------------------------------------------------------------------------
by fabpot at 2012-01-16T21:05:19Z
+1 for the the approach in this PR. @Seldaek: Can you apply it to everything else as well? Thanks.
---------------------------------------------------------------------------
by Seldaek at 2012-01-17T00:54:08Z
Done, also did it for adding and removing extensions since they potentially override stuff.
Commits
-------
fa2501f Added a link to the documentation site
Discussion
----------
Added a link to the documentation site
Now, on the github project page, there is a link to http://twig.sensiolabs.org/documentation. (like silex)
Fabien Potencier
Tobias Schultze
Jordi Boggiano
Sergey Linnik
Julien Brochet
Grégoire Pineau