| Age | Commit message (Collapse) | Author | |
|---|---|---|---|
| 2013-01-15 | Implement ./otp_build configure --enable-silent-rules | Anthony Ramine | |
| With silent rules, the output of make is less verbose and compilation warnings are easier to spot. Silent rules are disabled by default and can be disabled or enabled at will by make V=0 and make V=1. | |||
| 2012-11-14 | Merge branch 'vd/jinterface_epmd_localhost' | Henrik Nord | |
| * vd/jinterface_epmd_localhost: OtpEpmd.lokupNames() may hang if network is badly configured OTP-10579 | |||
| 2012-10-18 | Merge branch 'nk/jinterface-fix_compressed_binary' | Henrik Nord | |
| * nk/jinterface-fix_compressed_binary: add (de)compress roundtrip tests with larger values fix reading compressed binary terms from Java OTP-10505 | |||
| 2012-10-01 | OtpEpmd.lokupNames() may hang if network is badly configured | Vlad Dumitrescu | |
| On some machines with weird network configurations, InetAddress.getLocalHost() hangs. Searching for "localhost" works (at least in the cases I met). The difference is that the loopback address will be returned, instead of the real IP address, but for the local machine this should not be a problem. | |||
| 2012-08-31 | Update copyright years | Björn-Egil Dahlberg | |
| 2012-06-13 | fix reading compressed binary terms from Java | Nico Kruber | |
| Larger compressed binary could not be decoded inside JInterface. - applied a patch posted on erlang-questins in September 2009 http://erlang.org/pipermail/erlang-patches/2009-September/000478.html -> extended this patch as it alone was not enough to fix the bug Problem was that when reading from an InputStream, you can only specify a maximum number of bytes to read. Java doesn't quarantee that it actually reads this many bytes - it could be less! This patch now reads up until the expected size bytes. If there are more than expected, the actual number of available bytes is not printed (we probably shouldn't read the additional bytes, security-wise - the erlang external byte representation is broken in this case though). | |||
| 2012-06-05 | Update to work with whitespace in exec path | Lukas Larsson | |
| OTP-10106 OTP-10107 | |||
| 2012-03-30 | Update copyright years | Björn-Egil Dahlberg | |
| 2012-02-16 | Merge branch 'vd/jinterface-atom-message' into maint | Henrik Nord | |
| * vd/jinterface-atom-message: Improve error message when creating a too long OtpErlangAtom OTP-9928 | |||
| 2012-02-16 | Merge branch 'vd/java-string-bug' into maint | Henrik Nord | |
| * vd/java-string-bug: add test for Java string bug workaround for Java bug http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6242664 OTP-9927 | |||
| 2012-02-16 | Merge branch 'rc/spell-registered' into maint | Henrik Nord | |
| * rc/spell-registered: Correct spelling of "registered" in various places in the source code OTP-9925 | |||
| 2012-01-03 | Fix some broken links in documentation | Lukas Larsson | |
| 2012-01-03 | Correct spelling of "registered" in various places in the source code | Richard Carlsson | |
| 2011-12-09 | Update copyright years | Björn-Egil Dahlberg | |
| 2011-12-09 | restore Java5 compatibility | Nico Kruber | |
| 2011-12-09 | JInterface: improve OtpOutputStream buffer allocation | Nico Kruber | |
| Previously, the buffer was increased linearly by 2048 bytes. I now propose to use an exponential increase function (similar to Javas ArrayList, e.g. always at least +50%). This significantly increases performance of e.g. doRPC for large parameters as the following comparison illustrates (shown is the buffer size after each time, the buffer has reached its limit): n n*2048 (n*3)/2+1 (n*3)/2+1 (at least +2048) 1 2,048 2,048 2,048 2 4,096 3,073 4,096 3 6,144 4,610 6,145 4 8,192 6,916 9,218 5 10,240 10,375 13,828 6 12,288 15,563 20,743 7 14,336 23,345 31,115 8 16,384 35,018 46,673 9 18,432 52,528 70,010 10 20,480 78,793 105,016 11 22,528 118,190 157,525 12 24,576 177,286 236,288 13 26,624 265,930 354,433 14 28,672 398,896 531,650 15 30,720 598,345 797,476 16 32,768 897,518 1,196,215 17 34,816 1,346,278 1,794,323 18 36,864 2,019,418 2,691,485 19 38,912 3,029,128 4,037,228 20 40,960 4,543,693 6,055,843 21 43,008 6,815,540 9,083,765 22 45,056 10,223,311 13,625,648 23 47,104 15,334,967 20,438,473 24 49,152 23,002,451 30,657,710 25 51,200 34,503,677 45,986,566 26 53,248 51,755,516 68,979,850 27 55,296 77,633,275 103,469,776 28 57,344 116,449,913 155,204,665 29 59,392 174,674,870 232,806,998 30 61,440 262,012,306 349,210,498 Actually, ArrayList uses the (n*3)/2+1 strategy. In order not to decrease performance for messages <10k, we could keep the (public) OtpOutputStream#defaultIncrement constant and let the buffer always increase by at least this much (third column). In order to create a buffer of 1MB, now only 16 array copies are needed vs. (1024*1024/2048)=512 array copies for the linear increase function. If a user sends a message of 10MB size, this is 22 vs. 5120 copies. NOTE: the meaning of the "public static final int defaultIncrement" member has changed a bit with this implementation (API compatibility?) - why was this public in the first place? | |||
| 2011-11-24 | workaround for Java bug ↵ | Vlad Dumitrescu | |
| http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6242664 Java 1.5 has a bug where detecting codepoint offsets in strings that are created by String.substring() gives wrong results. The new implementation uses a different method, avoinding the issue. The following code will crash without the fix: final String s = "abcdefg"; final String ss = s.substring(3, 6); final int[] cps = OtpErlangString.stringToCodePoints(ss); | |||
| 2011-11-15 | Improve error message when creating a too long OtpErlangAtom | Vlad Dumitrescu | |
| Also print the value that we tried to use for the atom. This helps a lot when debugging and doesn't affect anything when the length is normal. | |||
| 2011-10-13 | Allow noncharacter code points in unicode encoding and decoding | Björn Gustavsson | |
| The two noncharacter code points 16#FFFE and 16#FFFF were not allowed to be encoded or decoded using the unicode module or bit syntax. That causes an inconsistency, since the noncharacters 16#FDD0 to 16#FDEF could be encoded/decoded. There is two ways to fix that inconsistency. We have chosen to allow 16#FFFE and 16#FFFF to be encoded and decoded, because the noncharacters could be useful internally within an application and it will make encoding and decoding slightly faster. Reported-by: Alisdair Sullivan | |||
| 2011-08-08 | jinterface: Use otp_subdir.mk instead of homebrewed solution | Björn Gustavsson | |
| There once was a reason to have a "Makefile.otp" makefile, but it doesn't apply any longer. Rename it to "Makefile" so that the standard otp_subdir.mk file can be used for recursion into sub directories. | |||
| 2011-08-08 | otp_subdir.mk: Remove support for clearmake | Björn Gustavsson | |
| 2011-03-11 | Update copyright years | Björn-Egil Dahlberg | |
| 2010-12-15 | Remove ancient distribution message DOP_NODE_LINK from all code | Patrik Nyblom | |
| 2010-09-20 | add OtpMbox.hash() method | Vlad Dumitrescu | |
| The OtpMbox class was missing the hash() method while overriding equals(). This can cause problems when using jinterface in a larger Java application. | |||
| 2010-08-31 | Remove all support for ancient EPMD protocol | Patrik Nyblom | |
| 2010-06-28 | Generate pom.xml during jinterface build | Gabor Liptak | |
| 2009-11-20 | The R13B03 release.OTP_R13B03 | Erlang/OTP | |
 |
index : otp.git | |
| Mirror of Erlang/OTP repository. | OTP Team |
| aboutsummaryrefslogtreecommitdiffstats |