aboutsummaryrefslogtreecommitdiffstats
path: root/lib/stdlib/src/eval_bits.erl
AgeCommit message (Collapse)Author
2018-01-09stdlib: Improve erl_eval's stacktracesHans Bolinder
The call "erlang:get_stacktrace()" is not handled explicitly. If there are issues, they can probably be ignored since erlang:get_stacktrace/1 will be deprecated and removed.
2016-08-04Move expansion of strings in binaries to v3_coreJosé Valim
This speeds up the compilation of binary literals with string values in them. For example, compiling a file with a ~340kB binary would yield the following times by the compiler: Compiling "foo" parse_module : 0.130 s 5327.6 kB transform_module : 0.000 s 5327.6 kB lint_module : 0.011 s 5327.8 kB expand_module : 0.508 s 71881.2 kB v3_core : 0.463 s 11.5 kB Notice the increase in memory and processing time in expand_module and v3_core. This happened because expand_module would expand the string in binaries into chars. For example, the binary <<"foo">>, which is represented as {bin, 1, [ {bin_element, 1, {string, 1, "foo"}, default, default} ]} would be converted to {bin, 1, [ {bin_element, 1, {char, 1, $f}, default, default}, {bin_element, 1, {char, 1, $o}, default, default}, {bin_element, 1, {char, 1, $o}, default, default} ]} However, v3_core would then traverse all of those characters and convert it into an actual binary, as it is a literal value. This patch addresses this issue by moving the expansion of string into chars to v3_core and only if a literal value cannot not be built. This reduces the compilation time of the file mentioned above to the values below: Compiling "bar" parse_module : 0.134 s 5327.6 kB transform_module : 0.000 s 5327.6 kB lint_module : 0.005 s 5327.8 kB expand_module : 0.000 s 5328.7 kB v3_core : 0.013 s 11.2 kB
2016-03-15update copyright-yearHenrik Nord
2015-06-18Change license text to APLv2Bruce Yinhe
2013-06-05Forbid unsized fields in patterns of binary generatorsAnthony Ramine
It makes no sense to be able to do `<<...,Rest/binary>> <= ...` in a comprehension. The related Dialyzer test is removed.
2013-02-07[stdlib] Fix bugs in eval_bitsHans Bolinder
Unicode related.
2011-09-29Merge branch 'dev' into majorBjörn-Egil Dahlberg
* dev: Update copyright years
2011-09-29Update copyright yearsBjörn-Egil Dahlberg
2011-09-01Merge branch 'dev' into majorHenrik Nord
2011-08-18fix broken edoc annotationsRichard Carlsson
2011-08-16Fix binary matching in the debuggerBjörn Gustavsson
'eval_bits' is a common utility module used for evaluting binary construction and matching. The functions that do matching (match_bits/{6,7} and bin_gen/6) are supposed to treat the bindings as an abstract data type, but they assume that the bindings have the same representation as in the erl_eval module. That may cause binary matching to fail in the debugger, because the debugger represents the bindings as an unordered list of two-tuples, while the erl_eval modules uses an ordered list of two-tuple (an ordset). One way to fix the problem would be to let the debugger to use ordered lists to represent the bindings. Unfortunately, that would also change how the bindings are presented in the user interface. Currently, the variable have most been recently assigned is shown first, which is convenient. Fix the matching problem by mending the leaky abstraction in eval_bits. The matching functions needs to be passed two additional operations: one for looking up a variable in the bindings and one for adding a binding. Those operations could be passed as two more funs (in addition to the evaluation and match fun already passed), but the functions already have too many arguments. Therefore, change the meaning of the match fun, so that the first argument is the operation to perform ('match', 'binding', or 'add_binding') and second argument is a tuple with arguments for the operation.
2010-09-10Remove warnings for clashes with new autoimported BIFsPatrik Nyblom
2009-11-20The R13B03 release.OTP_R13B03Erlang/OTP