Hi Brandon -- It's fine to touch any of the code and submit patches for consideration as you've done here. We're conferring internally to determine who should review this patch.
As you may have read in other threads, Chapel's handling of strings is currently fairly impoverished though we're interested in improving them (and working in this direction ourselves, though primarily in their memory management). One issue that's come up in other conversations is differences in string semantics if we use ASCII vs. UTF-8 strings, but I'll let others chime in on that topic. Ultimately, in order to accept patches, we'll need some sort of sign off from you on the code -- it's currently done via a legal agreement which you can find in the doc/developer/contributorAgreements/ directory if you're using the SourceForge repository (rather than a release download). We're in the process of moving to something a bit more open/unilateral/less Cray-centric, but still working through the details, so if you find the current scheme at all off-putting, you might just drag your feet a bit. -Brad On Mon, 2 Dec 2013, Brandon Ross wrote: > Hello, all. Forgive me if I'm doing something wrong; I'm not familiar > with the patch submission procedure, or which parts of the code are OK > to touch. > > I added a compiler primitive for finding the index of a substring within > a string. I didn't see any other way of doing the same thing > efficiently. It's basically just a wrapper around strstr. It returns 0 > if the substring couldn't be found. I didn't add a method to the string > type (outside of the module I'm working on) for calling it, but I'm > using it in the module for simple parsing procedures. > > I also changed string.substring to more gracefully handle unbounded and > out-of-bounds range limits by taking the intersection of the passed > range and the bounding range of the string (e.g., > "hello".substring(-5..30) == "hello"). Ranges that don't overlap the > string at all will return an empty string (e.g., > "hello".substring(50..100) == ""). It takes striding into account as > well. I also made string_index (single character substrings) return an > empty string if the index is out of range. I don't see the danger in > handling substrings like this instead of crashing, and other languages > (e.g., Python) do this as well. All in all I think it makes string > handling a little friendlier. > > Also, for edge cases that return empty strings, I simply returned an > empty string literal. I have no idea how safe that is or how it affects > garbage collection. Let me know if it's better practice to allocate a > new string instead. > > I put a test case in /test/trivial/bwross/string_index.chpl. > > -- Brandon > ------------------------------------------------------------------------------ Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk _______________________________________________ Chapel-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/chapel-developers
