ID:133580
 
Regex support or I'll start shooting this place up. >:O
CaptFalcon33035 wrote:
Regex support or I'll start shooting this place up. >:O

Perhaps you could put your $5 worth of bullets to better use.

Lummox JR
In response to Lummox JR (#1)
No offense to you personally (I even used an "S" so you'd be happy ;-)), I think regex is a critical language feature that should be built into the program itself. Requiring people to download a library, not to mention a pay-for library, is a huge liability to BYOND.

Worse, I don't think the Hub really clarifies that the "subscription" still allows you to keep your copy even after the subscription expires, so I imagine most people are instantly turned off by that.
In response to Jtgibson (#2)
Jtgibson wrote:
No offense to you personally (I even used an "S" so you'd be happy ;-)), I think regex is a critical language feature that should be built into the program itself. Requiring people to download a library, not to mention a pay-for library, is a huge liability to BYOND.

I agree here; if there are readily available c++ RegEx libraries, I don't see a reason not to have it as a language feature. Its enough of a feature to deserve its own mention as being an integrated part of the language, which certainly helps with advertising.
In response to Alathon (#3)
"BYOND -- Comes packed with quick and powerful Perl-like RegEx functions!"

That'd make me join BYOND!
Drop your weapon you have within 3 posts to comply.
In response to CaptFalcon33035 (#6)
GRETA appears to rely on the standard template library. For maintenance purposes, we avoid STL in BYOND's code. I don't know what the licensing is for this one. Assuming it can be made to work without STL and it doesn't involve selling our kidneys to Microsoft, it could have potential.

PCRE had to be ported to Windows, which is odd because a basic regex library really should already be portable--indeed it'd have to be for us to use it. The Windows version is a few versions behind. It uses the BSD license which I believe is one we can live with--anything with copyleft is absolutely out of the question.

I've seen Regex++ and Boost before, and frankly still don't understand them. I don't know what to make of the Boost license or what would be involved in using any of that, but my general feeling is that tacking on this whole other big library would not be a good thing for BYOND.

Lummox JR
In response to Lummox JR (#7)
Lummox JR wrote:
For maintenance purposes, we avoid STL in BYOND's code.

Unless there is some back-end reason not to use the STL this statement is just a paradox. I found that switching over to the STL not only improved the readability but also increased maintainability.

I've seen Regex++ and Boost before, and frankly still don't understand them. I don't know what to make of the Boost license or what would be involved in using any of that, but my general feeling is that tacking on this whole other big library would not be a good thing for BYOND.

Boost is a little hazy about their license in my opinion. I can contact them about the specifics though.

George Gough
In response to Lummox JR (#7)
Would you have trouble with LPGL? Naturally full GPL is a total no-no here.
In response to Lummox JR (#7)
It is my understanding that the ported versions of PCRE are for Microsoft Windows DLL generation. I think the the standard library will work fine as a static library. precpp.h is the C++ wrapper for the library.

Boost Software License
<pre> Boost Software License - Version 1.0 - August 17th, 2003 Permission is hereby granted, free of charge, to any person or organization obtaining a copy of the software and accompanying documentation covered by this license (the "Software") to use, reproduce, display, distribute, execute, and transmit the Software, and to prepare derivative works of the Software, and to permit third-parties to whom the Software is furnished to do so, all subject to the following: The copyright notices in the Software and this entire statement, including the above license grant, this restriction and the following disclaimer, must be included in all copies of the Software, in whole or in part, and all derivative works of the Software, unless such copies or derivative works are solely in the form of machine-executable object code generated by a source language processor. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE COPYRIGHT HOLDERS OR ANYONE DISTRIBUTING THE SOFTWARE BE LIABLE FOR ANY DAMAGES OR OTHER LIABILITY, WHETHER IN CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. </pre>

Regular Expression Component Library
Info: http://www.tropicsoft.com/Components/RegularExpression/
Download: http://www.tropicsoft.com/Components/RegularExpression/

C++ Regex Engine (Uses STL vector and string)
Info: http://freshmeat.net/projects/cpp_regex/
Download: http://jeff.bleugris.com/journal/projects/

RE_Lib Platform Independent
Info: http://www.geocities.com/SiliconValley/Peaks/8778/ pubdom.html#re_lib
Download: http://www.geocities.com/SiliconValley/Peaks/8778/relib.zip

Str Library Portable String Library
Info: http://www.utilitycode.com/str/default.aspx
Download: http://www.utilitycode.com/str/download.aspx
Note: Requires purchase of license; unlimited unrestricted evaluation.




In response to Lummox JR (#7)
How could I forget MinGW Regex?
http://sourceforge.net/project/ showfiles.php?group_id=2435&package_id=73286&release_id=1409 57

Readme:
<pre> This is the regex functionality from glibc 2.5 extracted into a separate library, for Win32. It may be built, from the sources provided, using the command sequence:-- ./configure [--options...] && make For a list of available configuration options, run:-- ./configure --help After building, as above, the resultant DLL, and optionally the associated development kit, may be installed by:-- make install while redistributable binary DLL and development library kits may be created by:-- make dist The original sources, on which this port is based, remain copyright of their respective authors, or of the Free Software Foundation Inc., as indicated in individual file headers; all are redistributed with permission, as granted by the GNU Lesser General Public License. This is free software. It is provided AS IS, in the hope that it may be useful, but WITHOUT WARRANTY OF ANY KIND, not even an IMPLIED WARRANTY of MERCHANTABILITY, nor of FITNESS FOR ANY PARTICULAR PURPOSE. Permission is granted to redistribute this software, either "as is" or in modified form, under the terms of the GNU Lesser General Public License, as published by the Free Software Foundation; either version 2.1, or (at your option) any later version. You should have received a copy of the GNU Lesser General Public License along with this software; see the file COPYING.LIB. If not, write to the Free Software Foundation, 51 Franklin St - Fifth Floor, Boston, MA 02110-1301, USA. The original port of this functionality was implemented by Tor Lillqvist; I've adapted his work, to make it somewhat more MinGW friendly. I have *not* modified any of the `C' sources provided by Tor; nor have I changed the naming conventions he adopted for generated distributables. I *have*:-- 1) Replaced Tor's original `Makefile' with an autoconf generated configure script, and a backwardly compatible `Makefile.in'; this provides a more flexible build procedure, which I find more convenient, when cross-compiling on a GNU/Linux host. 2) Added VPATH support, for `out of tree' builds. 3) Adapted the build procedure, to avoid a dependency on the `lib' program from Microsoft's MSVC tool chain. This is achieved by providing an option to configure, which is disabled by default; it may by activated by specifying `--enable-msvc-implib' on the configure command line. If this option is not activated, or if the MSVC `lib' tool is not present, the Makefile is configured without binding the rule for building an MSVC compatible import library, to the default target, (although the rule is left in place for explicit use). If the `--enable-msvc-implib' option is specified, but `lib' is not present, then configure will issue a warning message, and will again configure the Makefile without binding this rule to the default target. Only if the `--enable-msvc-implib' option is specified, *and* the `lib' tool is present, will building of an MSVC compatible import library be configured as a default deliverable. 4) Added `install', `install-dll' and `install-dev' targets, to support direct installation of the DLL, and its associated development kit. 5) Changed the default packaging format for distributables, from Tor's exclusive choice of `zip', to my own preferred `tar.gz'; `zip' format remains available, as an option, by configuring with `--enable-dist=zip'. 6) Added `bindist', `devdist' and `srcdist' targets, for greater flexibility in building distribution kits. The original text of Tor's README file will be found below. --Keith Marshall <keithmarshall@users.sourceforge.net> I call the DLL libgnurx-0.dll which hopefully should be unique. At least it isn't "regex.dll" which has been used by the gnuwin32.sourceforge.net site for *two* incompatible DLLs. (That mess, and the mess with their build of Henry Spencer's regex library, was what lead me to build my own GNU regex library. See the gnuwin32-users mailing list archives from December 2006.) The "-0" is so that if at some point I build a release that isn't binary compatible, I can then increment that and use a different name. The import library for gcc is called libgnurx.dll.a, but I also distribute a copy of it called libregex.a so that configure scripts that look for -lregex will work. Note that none of the wide-character and i18n functionality which is built when this is part of glibc gets compiled. Thus things like character classes most probably work only for single-byte codepages. Compiling that stuff would drag in lots of glibc's locale handling stuff which is completely incompatible with Microsoft's C library's locale handling anyway. Also, I am not sure whether the GNU regex code is prepared to handle a two-byte wchar_t, or does it assume that wchar_t is int as it is on Linux? Hmm, actually there is lots of sizeof(wchar_t) in glibc, so maybe it *is* prepared? Maybe later... But anyway, it would presumably mean we should have not just the regex functionality but a larger subset of glibc that would include all locale, ctype, wchar, mbs, etc stuff, presumably ending up with a very large part of glibc (not the system calls, obviously). Indeed, something to save for later, or never... --Tor Lillqvist <tml@iki.fi>, <tml@novell.com> </pre>
In response to KodeNerd (#8)
KodeNerd wrote:
Lummox JR wrote:
For maintenance purposes, we avoid STL in BYOND's code.

Unless there is some back-end reason not to use the STL this statement is just a paradox. I found that switching over to the STL not only improved the readability but also increased maintainability.

When I first implemented the DD ban system, the backend handled it all via STL. However, this adds a layer of complexity to BYOND's code because so much is done without STL, and it's just one more thing to deal with from a maintenance standpoint. Per Tom's request I replaced the STL with more familiar stuff.

I'm all on board with STL being elegant and performing some tasks (like handling strings) very well--it's just that it complicates code that is already especially complicated.

I've seen Regex++ and Boost before, and frankly still don't understand them. I don't know what to make of the Boost license or what would be involved in using any of that, but my general feeling is that tacking on this whole other big library would not be a good thing for BYOND.

Boost is a little hazy about their license in my opinion. I can contact them about the specifics though.

It doesn't seem worth it to me to implement Regex++ since this whole other library comes with it as baggage. More baggage is the last thing BYOND needs. A relatively simple regex engine on the other hand that didn't have to have a zillion other things with it in order to compile, that'd be handy.

Lummox JR
In response to Stephen001 (#9)
Stephen001 wrote:
Would you have trouble with LPGL? Naturally full GPL is a total no-no here.

I'm not terribly familiar with a lot of the licenses but my limited understanding of LGPL is that it's still not acceptable to us. As I recall it contains just enough copyleft to render it toxic.

Lummox JR
In response to CaptFalcon33035 (#11)
Sounds like that one is easier to build, but being under LGPL I don't think it's suitable. Any copyleft whatsoever is anathema. Or to put it another way, no GNUs is good news.

Lummox JR
In response to Lummox JR (#12)
Lummox JR wrote:
I'm all on board with STL being elegant and performing some tasks (like handling strings) very well--it's just that it complicates code that is already especially complicated.

At least you have a good reason for not using the STL.

George Gough
In response to Lummox JR (#14)
Lummox JR wrote:
Sounds like that one is easier to build, but being under LGPL I don't think it's suitable. Any copyleft whatsoever is anathema. Or to put it another way, no GNUs is good news.

I believe LGPL is ok, but we'd of course want to review it before jumping in.

And for the record (before this turns into an open-source debate), I'm not actually against open-source for BYOND, but if we did it I'd want to do it correctly, with a clean API and documentation, and that is just too big of an effort to deal with at the moment.
In response to Lummox JR (#13)
My understanding is libc is LGPL-2, which the Linux package of BYOND uses.