Re: [RFC] Replacing our regex implementation
--- On Sun, 5/8/11, Bakul Shah wrote: ... > > C++ may be an impediment for it to go into libc but one > can certainly put a C interface on a C++ library. > I wouldn't think it's very consistent to use C++ in libc. Perhaps we could have the best of both worlds by using libtre as the libc regex replacement and re2 for grep and diff? As an extra benefit using Re2 would make it easier to support --perl-regex in grep. cheers, Pedro. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [RFC] Replacing our regex implementation
On Mon, 09 May 2011 17:51:46 EDT David Schultz wrote: > On Sun, May 08, 2011, Bakul Shah wrote: > > On Sun, 08 May 2011 21:35:04 CDT Zhihao Yuan wrote: > > > 1. This lib accepts many popular grammars (PCRE, POSIX, vim, etc.), > > > but it does not allow you to change the mode. > > > http://code.google.com/p/re2/source/browse/re2/re2.h > > > > The mode is decided when an RE2 object is instantiated so this > > is ok. You can certainly instantiate multiple objects with > > different options if so desired. > > > > > 2. It focuses on speed and features, not stability and standardization. > > > > Look at the open issues. Seems stable enough to me. re2 has a > > posix only mode. It also does unicode. s/posix only mode/posix only mode as well/ > > > > > 3. It uses C++. We seldom accepts C++ code in base system, and does > > > not accept it in libc. > > > > This is the show stopper. > > Use of C++ is a clear show-stopper if it introduces new runtime > requirements, e.g., dependencies on STL or exceptions. Aside from > that, however, I can't think of any fundamental, technical reasons > why a component of libc couldn't be written in C++. (Perhaps the > toolchain maintainers could name some, and they'd be the best > authority on the matter.) You can expect some resistance > regardless, however, so make sure the technical merits of RE2 are > worth the trouble. Ok, I just verified there are no additional runtime requirements by running a simple test, where I added a C wrapper around an RE2 C++ call, compiled it with c++, then compiled the client C code with cc, and linked everything with cc. This works (tested on on x86_64, under 8.1). I do think RE2 is very well done (see swtch.com/~rsc/regexp articles) and it is actively maintained, has a battery of pretty exhaustive tests. Seems TRE's author also likes re2: http://hackerboss.com/is-your-regex-matcher-up-to-snuff/ So if we want to consider this, it is a real possibility. > IIRC, some of the prior discussions on using more C++ in the base > system got derailed by tangents on multiple inheritance, operator > overloading, misfeatures of STL, and what subset of C++ ought to > be considered kosher in FreeBSD. You don't have to get involved > in any of that because you'd only be proposing to import a > self-contained third-party library. Indeed; we would just use it via a C wrapper API. But I can see someone thinking this is the camel's nose in the tent :-) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [UPDATE] New Boot-Loader Menu -- version 1.4
On Mon, 9 May 2011, Alexander Leidinger wrote: IMO it's either - change now or - no change, never ever or - change if special variable is set In case it hasn't already been suggested... Just make the loader read a template file that defines the menu. The port or base system can include a standard menu file, and everyone else can set it up however they want. As an example, see syslinux or grub or any number of similar boot menus. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [RFC] Replacing our regex implementation
On Sun, May 08, 2011, Bakul Shah wrote: > On Sun, 08 May 2011 21:35:04 CDT Zhihao Yuan wrote: > > 1. This lib accepts many popular grammars (PCRE, POSIX, vim, etc.), > > but it does not allow you to change the mode. > > http://code.google.com/p/re2/source/browse/re2/re2.h > > The mode is decided when an RE2 object is instantiated so this > is ok. You can certainly instantiate multiple objects with > different options if so desired. > > > 2. It focuses on speed and features, not stability and standardization. > > Look at the open issues. Seems stable enough to me. re2 has a > posix only mode. It also does unicode. > > > 3. It uses C++. We seldom accepts C++ code in base system, and does > > not accept it in libc. > > This is the show stopper. Use of C++ is a clear show-stopper if it introduces new runtime requirements, e.g., dependencies on STL or exceptions. Aside from that, however, I can't think of any fundamental, technical reasons why a component of libc couldn't be written in C++. (Perhaps the toolchain maintainers could name some, and they'd be the best authority on the matter.) You can expect some resistance regardless, however, so make sure the technical merits of RE2 are worth the trouble. IIRC, some of the prior discussions on using more C++ in the base system got derailed by tangents on multiple inheritance, operator overloading, misfeatures of STL, and what subset of C++ ought to be considered kosher in FreeBSD. You don't have to get involved in any of that because you'd only be proposing to import a self-contained third-party library. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [UPDATE] New Boot-Loader Menu -- version 1.4
On Sun, 8 May 2011 13:45:55 -0700 Devin Teske wrote: > On May 8, 2011, at 12:13 PM, Alexander Leidinger wrote: > > > On Sun, 8 May 2011 10:48:55 -0700 Devin Teske > > wrote: > > > >> I would like to see general consensus from the community for > >> separating the items before moving ahead with such a non-trivial > >> change. > > > > IMO: > > - I agree that there are two different types of actions > > - having 2 distinct blocks looks like a good idea to me > > (I didn't had a look at the code, if you only have the text > >in the variables and the numbers get added automatically, > >maybe you can add variables for inbetween items which > >are pure text and do not get a number, and they are not > >displayed if the variable is empty) > > - I do not think that we need two different namespaces here > > -> reorder the items, use incrementing numbers no matter > > which type it is (ACPI would be number 4 in the example then) > > > All-in-all, I love the suggestion. > > A few notes: > - I also agree that there are two different types of actions > - Significant changes would need to be made. > - I'd like to take the gradual approach > - You're right, it could be done without two different namespaces > > However, there's one very important fact... > > The current menu is "numbers only" which means that people that use > the menu often will be impacted in a non-trivial way if we re-order > the numbers. > > The gradual approach would have us accept a new menu (such as > loader_menu-1.4) that enables the use of hotkeys. Get people used to > using the hotkeys for awhile before re-ording (or perhaps even > taking-away) the numbers. > > What do you think of the gradual approach? If you want to spend some years... IMO it's either - change now or - no change, never ever or - change if special variable is set I do not think it is really an option to change it only for new installs but keep the numbers for installed ones as they are (if there is a way to do this). I also think that there will always be some people which never switch to hotkeys. FYI: I never got the numbers into my brain, I always use SPACE to pause and then read which number to press. This could be because I do not (re)boot systems much, but I expect/hope that there are more people which do the same. With the hotkeys this may change, as they are easy to associate with the English word for the action. I'm all for gradual improvements, but there are things which can not be done gradually. This usability improvement is one of the later ones IMO. If nobody complains that such a separation is very hard to get and that it is too hard to press SPACE and that the ordering of the new entries can only be provided by someone with a twisted brain, I would do it, as it looks like very good and better understandable usability improvement which should get new users (to FreeBSD but maybe not to the Unix way) to better get suited with FreeBSD. Maybe an explicit variable to set to go back to the old order if there are too much voices which tell it would violate POLA? Bye, Alexander. -- http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
RE: [UPDATE] New Boot-Loader Menu -- version 1.4
> -Original Message-
> From: Lars Engels [mailto:lars.eng...@0x20.net]
> Sent: Monday, May 09, 2011 2:19 AM
> To: Devin Teske
> Cc: FreeBSD Hackers
> Subject: Re: [UPDATE] New Boot-Loader Menu -- version 1.4
>
> On Thu, May 05, 2011 at 01:20:43AM -0700, Devin Teske wrote:
> > Hello fellow -hackers,
> >
> > I'm so very proud to offer the latest update to my new boot loader
> > menu -- version 1.4 -- addressing ACPI detection, bringing it in-line
> > with HEAD.
> >
> > It took some work and a few days, but I got it! Have a look below for
> > six different displays (three different scenarios -- i386 w/ ACPI,
> > i386 w/o ACPI, and non-i386 -- each in both B&W and Color).
> >
>
> Hi Devin,
>
> PC-BSD also has a slightly patched loader menu compared to the stock FreeBSD
> version.
Does PC-BSD have CVSweb that I can browse? Link?
> I.E. you can also set unset verbose mode and ACPI with it.
> Some days ago there was a proposal on a PC-BSD list to add an option to boot a
> different kernel if one is found in /boot.
> Would it be possible to addi this function to your boot menu?
No need. The basic constructs are there already, we just need to expand on them.
Here's how I've implemented a hard-coded list of kernels to choose from for our
systems (to be implemented in /boot/menu.rc):
\ Set kernel paths (see menu_caption[2] below)
set kernel_prefix="/kernels/"
\ NOTE: We like to keep our kernels in `/kernels'
set kernel[0]="FIS-i386-8.1p1"
set kernel[1]="GENERIC-i386-8.1p1"
set kernel_suffix=".kgz"
\ NOTE: This is on our CD/DVD, so kernels are kgzip(8)'d
\ Set default boot kernel
set kernel="${kernel_prefix}${kernel[0]}${kernel_suffix}"
\ Initialize main menu constructs (variables are read by `menu.4th')
set menu_caption[1]="Boot [ENTER]"
set menu_command[1]="boot"
set menu_caption[2][0]="Kernel: ${kernel[0]} (1of2)"
set menu_caption[2][1]="Kernel: ${kernel[1]} (2of2)"
set menu_caption[2]="${menu_caption[2][0]}"
set menu_command[2]="cycle_kernel"
\ ... rest of menu ...
The magic is the "cycle_kernel" command (see `/boot/menu.4th'). The
`cycle_kernel' command is a wrapper to the `cycle_menuitem' command (similar to
how `toggle_verbose', `toggle_acpi', and `toggle_singleuser' are wrappers to
the `toggle_menuitem' command). Like the `toggle_menuitem' command, the
`cycle_menuitem' command uses a system of internal state variables to track
which menuitem text is to be displayed for that individual menuitem. Whereas
the `toggle_menuitem' command automatically toggles the text of a menuitem
between the `menu_caption[x]' and `toggled_text[x]' variables, the
`cycle_menuitem' command automatically cycles through the `menu_caption[x][y]'
variables, cycling back to y=0 when it gets to an undefined `y' value.
However, hard-coding an alternate kernel choice is something that I wouldn't
condone for an actual release. Instead, what I would recommend is to
dynamically allocate the kernel menu if/when multiple kernels are
discovered/configured. That's something that is currently not coded (dynamic
detection of kernels in /boot).
> Or even better
> work together with Kris Moore so we don't have two solutions for the same
> task?
I'd like to open a discussion with Kris Moore on how we could go about
detecting additional kernels.
Off the top of my head, here's a couple thoughts:
a. We could test a battery of different kernel names (kernel, kernel.bak,
kernel.orig, etc.)
b. We could allow the user to set kernel1, kernel2, kernel3, etc. in
loader.conf(5)
c. We could allow the user to set kernel="kernel1;kernel2;kernel3;..." in
loader.conf(5)
d. Some combination of the above.
--
Devin
P.S. I think it'd also be nice to someday offer the user a choice of booting
into a memory filesystem for rescue purposes. We've offered this to our users
for years with the following configuration:
set root[0]=""
set root[1]="rescue_mfsroot"
set menu_caption[7][0]="Root Image: Default (1of2)"
set menu_caption[7][1]="Root Image: Rescue (2of2)"
set menu_caption[7]="${menu_caption[7][0]}"
set menu_command[7]="cycle_root"
_
The information contained in this message is proprietary and/or confidential.
If you are not the intended recipient, please: (i) delete the message and all
copies; (ii) do not disclose, distribute or use the message in any manner; and
(iii) notify the sender immediately. In addition, please be aware that any
message addressed to our domain is subject to archiving and review by persons
other than the intended recipient. Thank you.
_
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [UPDATE] New Boot-Loader Menu -- version 1.4
On Thu, May 05, 2011 at 01:20:43AM -0700, Devin Teske wrote: > Hello fellow -hackers, > > I'm so very proud to offer the latest update to my new boot loader > menu -- version 1.4 -- addressing ACPI detection, bringing it in-line > with HEAD. > > It took some work and a few days, but I got it! Have a look below for > six different displays (three different scenarios -- i386 w/ ACPI, > i386 w/o ACPI, and non-i386 -- each in both B&W and Color). > Hi Devin, PC-BSD also has a slightly patched loader menu compared to the stock FreeBSD version. I.E. you can also set unset verbose mode and ACPI with it. Some days ago there was a proposal on a PC-BSD list to add an option to boot a different kernel if one is found in /boot. Would it be possible to addi this function to your boot menu? Or even better work together with Kris Moore so we don't have two solutions for the same task? Lars pgpTDrYVktqJU.pgp Description: PGP signature
