java8 stream findfirst().get()空指针

最新推荐文章于 2024-03-31 11:13:24 发布
最新推荐文章于 2024-03-31 11:13:24 发布
阅读量1.3w 收藏 9
点赞数 6
文章标签： java
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_38098608/article/details/106092247
版权

java8 stream findfirst().get()空指针

		List<Integer> a = Arrays.asList(1, 2, 3);
        Integer b = a.stream().filter(x -> x.equals(4)).findFirst().get();
        System.out.println(b);

Exception in thread “main” java.util.NoSuchElementException: No value present
at java.util.Optional.get(Optional.java:135)

解决方法：将.get()替换为.orElse(null)，这样就会返回null值了。

夜晨丶
关注
  • 6
    点赞
  • 踩
  • 9
    收藏
    觉得还不错? 一键收藏
  • 2
    评论
java stream
12-02
java stream doc.
uhdd.sys源码
03-03
XMGR RDISK and UIDE DOS Device Drivers 1 Description XMGR RDISK and UIDE are a group of DOS device drivers for a PC system with an 80386+ CPU and using MS DOS V5 0+ or equivalent XMGR is a DOS driver which works as an "XMS manager" and provides up to 4 GB of XMS memory XMGR has direct support for V3 70+ UMBPCI by Uwe Sieber After UMBPCI enables upper memory XMGR loads there and will provide both upper and XMS memory to a DOS system XMGR uses an "I O Catcher" with UMBPCI Disk diskette I O above 640K is trapped by XMGR and done using a low memory area as UMBPCI "Shadow RAM" cannot do DMA XMGR also runs with JEMM386 or MS DOS EMM386 With EMM drivers XMGR using its B switch first boots in temporary space When upper memory gets enabled by the EMM driver XMGR loads there with no B copies all its boot data and takes over XMS work For a small XMS only system XMGR can also run entirely in low memory RDISK is a DOS RAM disk driver It creates a "fast" disk drive using 2 Megabytes to 2 GIGABYTES of XMS memory It loads as a system driver in CONFIG SYS or it can load later in AUTOEXEC BAT or by user command DOS can copy critical programs and data to the RAMdisk where they will be read or written at memory speed If loaded after CONFIG SYS RDISK files can be assigned to any free DOS drive letter using its : switch RDISK runs with V2 0 or V3 0 XMS managers 60 MB maximum for V2 0 XMS It uses only 656 to 752 bytes of upper memory depending on the system and it can also load in 640K DOS memory RDISK is a simple and small RAMdisk driver for use when resizing or other features are not needed UIDE is a DOS "Universal IDE" caching driver It intercepts "Int 13h" BIOS I O requests and caches data for up to 30 BIOS disks including A: or B: diskettes and including hard disks of any size UIDE can handle 48 bit LBA or 24 bit CHS I O calls by new or old DOS systems It will handle up to 10 "Legacy" or "Native PCI" IDE controllers UIDE "calls the BIOS" for diskettes and intercepts I O for "Int 13h" drivers loaded first thus UIDE caches ALL drives on a DOS system "ASPI" and other "non Int 13h" drivers are unsupported UIDE also detects and runs up to 8 SATA IDE and old "PIO mode" CD DVD drives It can cache CD DVD data and directories for MUCH greater speed and it will play audio CDs and handle "raw" trackwriter input audio and "raw" input is uncached UIDE caches 5 Megabytes to 4 GIGABYTES of data It can set up to four separate caches of its own "Common" User 1" "User 2" and "CD DVD" and it also permits caching requests from user drivers to "bring along" their OWN caches See the UIDE TXT file for full details UIDE uses 4816 bytes of upper DOS memory for 1 to 4 caches of any size All its data or cache tables use XMS memory A "stand alone" UIDE B switch no cache or diskettes can be used in test or diagnostic work and takes 3664 bytes of upper DOS memory If its N2 switch is given UIDE will omit all CD DVD logic saving 1744 bytes Its "CD DVD" cache can then become a 3rd user driver cache if needed UIDE"s H switch will load most of the driver into "free HMA" thus using only 928 bytes of memory 832 "stand alone" The small UHDD and UDVD2 drivers are also available for those who want only non caching drivers or a smaller size driver set for use on "boot" diskettes etc UHDD can cache 26 SATA IDE disks of any size on up to 10 controllers A: or B: diskettes included It now has all four UIDE caches takes 3280 bytes for caching and it can set a 1408 byte "stand alone" driver no cache with its B switch UHDD can put most of its code in HMA space with its H switch taking only 832 bytes 640 "stand alone" UDVD2 handles up to 6 SATA IDE or old PIO mode CD DVD drives it tests up to 10 controllers on loading and takes 2000 bytes or 144 with its H switch Caching by UHDD adds 96 bytes and UDVD2 "shares" UHDD"s I O buffer in XMS for input unsuited to UltraDMA If UHDD is not used UDVD2 will take 128K of XMS as its buffer or it handles such input in PIO mode if XMS is not available UHDD + UDVD2 require only 10K of disk file space and provide most UIDE features The small RDISKON COM program can "re enable" a DOS drive used by RDISK if a "format" command is accidentally issued to it This disables the drive on some systems Entering RDISKON L at a DOS command prompt where L is the desired drive letter A to Z will re enable the drive The small CC COM "Clear Cache" program can help verify files written by UIDE Entering CC at the DOS command prompt sends a BIOS "reset" to all disks making UIDE flush its "Common" cache Data from the disk NOT data still in cache can then be compared to the original output 2 NO Warranties XMGR RDISK and UIDE are offered at no cost "as is" "use at your own risk" and with NO warranties not even the implied warranty of FITNESS for any particular purpose nor of MERCHANTABILITY Driver questions and comments may be addressed to the E Mail of Johnson Lam <johnsonlam hk@gmail com> 3 Revision Summary 19 Oct 14 UHDD now "overlaps" cache work during UltraDMA disk output and the disk sector "gap" at I O end for greater speed UHDD M switch deleted 256 byte binary search buffer is now permanent Other drivers unchanged re dated only 27 Sep 14 UHDD now sets all 4 UIDE caches New UHDD M switch sets a 512 byte binary search buffer for more speed 26 Jan 14 UIDE error handling CD DVD media changes for "stand alone" mode is fixed UHDD offers "Common" & "CD DVD" caches 12 Jan 14 UIDE UD switch deleted many problems UIDE now offers "User 1" and "User 2" caches "Stand alone" UHDD UDVD2 re added for use as needed 12 Dec 13 UHDD UDVD2 deleted low use UIDE N2 dismisses CD DVD logic UIDE C switch added user caching improved 21 Nov 13 UHDD old style "stand alone" driver re added 14 Nov 13 UHDD UDVD2 "private" caches deleted unneeded and unused 25 Sep 13 BAD error fixed in UDVD2 re: locating UHDD MANY Thanks to Japheth for his tests and exact analysis 9 Sep 13 Possible but unlikely UHDD exit errors corrected UDVD2 UIDE now use all 32 CD DVD LBA bits in caching calls 2 Sep 13 Possible UDVD2 "media change" error fixed UHDD N1 size reduced 26 Aug 13 UHDD now has its "Common" cache and handles "private" user driver caches UDVD2 etc can now set a private cache 28 Jul 13 UHDD UIDE binary search buffer and F switch deleted 30 Apr 13 UHDD UDVD2 can now run without XMS lower speed for tests and FreeDOS "scripts" UDVD2 can now do "raw" input 15 Oct 12 UHDD UIDE again detect A: and B: diskettes from BIOS data NOT from "Int 13h" calls that FAIL with an LS 120 drive 2 Aug 12 UHDD "disk only" caching driver added UDVD2 caches CD DVD data if UHDD is also loaded UIDEJR deleted New UD switch in UDVD2 UIDE for CD DVD directory caching 9 Jul 12 UIDE UIDEJR device select error for master + slave CD DVD units on one IDE channel is corrected Many Thanks to Doug Beneway for finding this error 25 Jun 12 UIDE2 deleted: Not enough added speed complex to use 17 Jun 12 UIDE UIDE2 UIDEJR A switch init of 2 "Old IDE" channels and CD audio "Q" status data corrected Many Thanks to Japheth for his research and audio test program 29 May 12 UIDE and UIDE2 check for diskettes via Int 13h avoid DPTE tests if no PCI BIOS let the BIOS do I O for disks with bad DPTE data all re: VirtualBox BUGS 24 Feb 12 UIDE UIDE2 "64K DMA boundary error" fixed may affect only year 2000 chips or older 16 Oct 11 UIDE M switch deleted search buffer is always 512 bytes UIDE SYS back to 7 5K UIDE S dropped UIDE2 improved 7 Oct 11 All UIDE drivers updated to avoid BIOS "DPTE" ERRORS: Bad DPTE data for USB sticks Many Thanks to Daniel Nice 9 Sep 11 UIDE2 re added UIDE S and UIDE2 handle 6 CD DVD drives 22 Jul 11 UIDE E switch added for DOS emulators VirtualBox etc 20 May 11 UIDE S "short" UIDE added for systems with limited HMA 25 Apr 11 BAD "code mods" init error corrected for UIDE UIDEJR and RDISK XMGR not affected 5 Dec 10 UIDE UIDEJR R15 and R63 switches added to handle old DOS "games" Thanks Guillermo Grana Gomez 28 Nov 10 Minor updates: UIDEJR audio track number error corrected XMGR faster in protected mode Added XMGR and UIDE Z 15 Aug 10 UIDE audio track number error corrected Thanks Nagatoshi Uehara 10 Aug 10 UIDE binary search buffer added Using $ in CD DVD names fixed in UIDE UIDEJR Thanks Japheth 4 Jul 10 README file update XMGR UIDE can use "Native IDE" mode same as "Legacy" "Compatibility" for AHCI mainboards 28 Jun 10 XMGR updated for AHCI see the README sec 7 for details 10 Jun 10 UIDE now ignores "removable HARD disks" size reduced 16 Nov 09 UIDE now caches 4 GIGABYTES of data 6 Oct 09 UIDE and UIDEJR H requests HMA use "at the user"s risk" 2 Sep 09 README file updated FreeDOS users who desire full upper memory must omit UMBPCI and load JEMM386 JEMMEX only 23 Jun 09 RDISK now a COM file RDISK : switch RDISKON program added Corrected UIDE CD DVD handling of VDS errors 9 Jun 09 UIDE UIDEJR N3 switch added for no XMS memory Override of D: name by UIDE$ UIDEJR$ added for no CD DVD drives 15 May 09 Added RDISK 6 May 09 Added UIDEJR 1 May 09 Fixed XMGR "Port 92h" logic error Added XMGR PA and PN switches to control use of "Port 92h" 25 Apr 09 XMGR UIDE license and FreeDOS prohibition deleted drivers and sources are again available to all 4 Switch Options XMGR usually needs only its B switch if "booting" with an EMM driver All XMGR switch options are as follows: B Specifies "boot" mode XMGR loads in temporary memory until upper memory is enabled Without B XMGR loads stand alone in low memory or direct to upper memory with UMBPCI See the CONFIG SYS examples in section 5 Mn Specifies a temporary area for loading XMGR in "boot" mode or for UMBPCI upper memory I O before DOS posts a "workspace" buffer Values are: M1 64K M3 192K M5 320K M7 448K M2 128K M4 256K M6 384K M8 512K Without M M5 is assumed and the 320K area will be used NOTE: DOS systems may NOT load at address 0 and may leave temporary data anywhere in memory Mn helps to find a "safe" area for XMGR to use M is ignored if XMGR loads stand alone Nnn Specifies how many XMS "Handles" can be used by DOS programs The value nn may be 48 80 or 128 If N is omitted 48 "Handles" are used A big system doing much XMS work may need 80 or 128 "Handles" PA Specifies use or non use of PS 2 Port 92h logic to handle the PN system"s "A20" line PA indicates "Always" use Port 92h logic PN indicates "Never" use it and handle "A20" via normal keyboard port logic If P is omitted XMGR "asks the BIOS" if the system has Port 92h logic If not XMGR will use normal "A20" logic NOTE: If "A20" was enabled by DOS before XMGR loads XMGR does not handle it at all Tn Specifies the BIOS requests to use in getting extended memory as follows: T0 No "E820h" nor "E801h" requests T1 Memory list requests only Int 15h AX E820h T2 A dual area request only Int 15h AX E801h T3 "E820h" requests first then an "E801h" request T can usually be omitted causing T3 to be assumed In addition XMGR always uses an old 64 MB request to get T0 memory or if the requests denoted by T1 thru T3 are not successful Users may need to test T1 or T2 separately to see if their BIOS takes them A pre 1994 BIOS may not ignore T1 thru T3 correctly and may require T0 instead For old "QHIMEM" users T4 thru T7 may still be used and work the same as T0 thru T3 W Specifies use of the DOS "workspace" buffer for upper memory I O if loading with UMBPCI If W is omitted or if the DOS system does not have proper workspace logic XMGR sets its own buffer in low memory With PC DOS or EDR DOS W must be omitted Without UMBPCI W is ignored Z See Z for UIDE below RDISK uses only S size and : drive letter switches: Sn Specifies a desired RAM disk size in megabytes of XMS memory Values may be any number from 2 to 2047 S1024 or more creates a 1 to 2 GIGABYTE RAM disk If S is omitted or invalid a 25 MB RAM disk is created by default For old V2 0 XMS managers ROM DOS etc only S2 through S60 may be used See section 5 below for more details :L Specifies the DOS drive letter desired to access RDISK files L may be any available drive letter from A to Z e g :N assigns drive N: to all RDISK files If the drive letter is too high or already in use RDISK will abort and users may need "LASTDRIVE " in CONFIG SYS to set up more drives If RDISK is loaded by CONFIG SYS or if : is omitted the next free drive letter will be used UIDE usually needs only a H switch to use HMA space and a S switch to specify its cache size All UIDE switches are as follows: A Specifies ALTERNATE addressing for "legacy IDE" controllers The first legacy controller uses 01E8h 0168h addresses and a second if present uses 01F0h 0170h addresses A is only for "odd" mainboards with REVERSED addressing for the two legacy IDE controllers Without A the first legacy controller uses 01F0h 0170H and a second uses 01E8h 0168h as is normal for most PC mainboards B Requests a "basic" UltraDMA driver for disks and CDs DVDs no caching or diskette handling This may help for tests or diagnostics The B driver can request 128K of XMS as an UltraDMA I O buffer and it can load in the HMA The N2 switch can be given with B to "dismiss" all CD DVD logic Cnn Sets a separate "CD DVD" cache for higher CD DVD performance Values for nn are the same as for the S switch and permit up to 4 GB caches The "CD DVD" cache can be used by any user driver devices on systems with no SATA or IDE CD DVD drives If C is omitted data for requests addressed to the "CD DVD" cache shall go into UIDE"s "Common" cache D: Specifies the "device name" used by the CD DVD Redirector to access CD DVD drives For example: D:CDROM1 D:SANYO1 etc If D: is not given or the name following a D: is missing invalid UDVD1 is set by default If no CD DVD drives were found UIDE$ overrides any D: name for use with FreeDOS autoloader scripts E Makes the driver call the BIOS for any hard disk I O request E avoids setup trouble on some DOS emulators VirtualBox etc that do not emulate all PC hardware logic E also allows using hard disks on 1994 or older PCs which have no PCI EDD BIOS E still caches disk data unlike N1 that removes ALL disk support If B is given E is ignored NOTE Use of E on protected mode systems JEMM386 etc may run VERY slow Many BIOS programs omit DOS "VDS" support for hard disks and in protected mode they must do "PIO mode" transfers not UltraDMA If E is required a PC should be run in real mode UMBPCI etc whenever possible H Loads most of the driver in "free HMA" space UIDE will use only 928 bytes of upper DOS memory 832 when B is given H must not be used with ROM DOS which has no HMA NOTE MS DOS kernels have ERRORS in posting free HMA space which can give CRASHES Specifying H is "At the user"s risk" No such crashes are noted with other DOS systems also HMA usage by UIDE is under 4K bytes Users should still test a PC system before H is given for any serious tasks with these drivers N1 Requests NO hard disk handling by the driver N2 Requests NO CD DVD handling by the driver N2 will dismiss all CD DVD routines and save 1744 bytes N3 Requests no XMS memory N3 sets UIDE"s B "basic" driver N3 requires loading in low memory or UIDE aborts N3 can LOSE much speed as misaligned or other I O not suited to UltraDMA requires "calling the BIOS" for disks or using "PIO mode" for CD DVD drives N4 See Z below Q Awaits a "data request" before doing UltraDMA disk transfers Q is for "old" systems and may be used only if the driver loads O K but seems unable to transfer data Q must be OMITTED with SATA to IDE adapters from Sabrent and others since they may not emulate "data request" from SATA disks Q does not affect CD DVD drives R15 Sets the driver"s XMS memory at 16 or 64 MB R15 reserves R63 15 MB of XMS and R63 reserves 63 MB of XMS for DOS game programs that require XMS memory below 16 or 64 MB The drivers must be able to reserve this memory reserve their own XMS above that and "free" the 15 63 MB XMS If not the drivers display "XMS init error" and abort R15 or R63 need the drivers to load after the XMS manager XMGR HIMEMX etc so another driver cannot take any XMS first and the reserved XMS is just beyond the HMA See section 7 below for further details Snn Specifies the desired "Common" cache size in megabytes of XMS memory UIDE"s "Common" cache holds data for hard disks diskettes and CD DVD drives when C above is not given Values for S can be 5 15 25 40 50 or any number from 80 to 4093 S1024 and up sets a 1 to 4 GIGABYTE cache Suggested S values are Below 128 MB memory: Use S5 S15 S25 or S40 With 128 MB memory: Use S25 S40 S50 or S80 With 256 MB memory: Use S80 up to S127 With 512 MB memory: Use S160 up to S255 With 1 GB memory: Use S320 up to S511 With 2 GB memory: Use S640 up to S1023 With 4 GB memory: Use S1280 up to S3072 Small systems may prefer S25 or S50 which set 1600 cache blocks and are more efficient If S is omitted invalid an 80 MB cache is set Except for 25 or 50 values below 80 are cut to 40 15 or 5 MB The drivers display "XMS init error" and abort when not enough XMS memory is free If so a smaller cache must be requested For older V2 0 XMS managers ROM DOS etc only S5 to S50 may be used UX Disables all CD DVD UltraDMA even for drives that can do it "PIO mode" then handles all CD DVD I O Except for a few unusual drives by Sony etc which do not follow all ATAPI "rules" UX is rarely needed UX does not affect hard disks Xnn Sets a separate "User 1" cache for user drivers Values for nn are the same as for S above If X is omitted data for requests addressed to the "User 1" cache shall go into UIDE"s "Common" cache Ynn Sets a separate "User 2" cache for user drivers Values for nn are the same as for S above If Y is omitted data for requests addressed to the "User 2" cache shall go into UIDE"s "Common" cache Z For XMGR UIDE UHDD limits XMS moves to 2K byte sections not 64K when in protected mode Z is unneeded for JEMM386 JEMMEX MS DOS EMM386 or real mode UMBPCI If other EMM VCPI or DPMI drivers are used systems must be tested to see if Z is required BAD schemes that allow not enough interrupts during XMS moves can still be in use UIDE"s old N4 switch works the same and can still be used The "stand alone" UHDD ignores N4 or Z and will call the XMS manager to do its XMS moves UHDD usually needs only a H switch to load in HMA space also C S X or Y switches to specify cache sizes A summary of all UHDD switches is as follows: A Sets ALTERNATE addressing for "Legacy" IDE controllers same as UIDE A above Rarely necessary B Requests a 1408 byte "stand alone" driver no caching same as UIDE B above Cnn Sets a "CD DVD" cache size for UDVD2 use same values as for UIDE S above If C is omitted or invalid CD DVD data will go in UHDD"s "Common" cache E Makes the driver "call the BIOS" for hard disk I O requests same as UIDE E above E dismisses UltraDMA disk logic and saves 496 bytes H Loads all but 832 bytes of the driver 640 with B into HMA space See the note for UIDE H above Q Awaits "data request" before beginning UltraDMA I O with old controllers same as UIDE Q above Rarely necessary R15 Reserves 15 MB or 63 MB of XMS for old DOS "game" programs R63 same as UIDE R above Rarely necessary Snn Sets a "Common" cache size same values as UIDE S above Xnn Sets the "User 1" cache size same values for UIDE S above If X is omitted invalid "User 1" data will go in UHDD"s "Common" cache Ynn Sets the "User 2" cache size same values for UIDE S above If Y is omitted invalid "User 2" data will go in UHDD"s "Common" cache Z See Z above UDVD2 normally needs only a H switch to use HMA space and a D: switch to specify a driver "device name" A summary of all UDVD2 switches is as follows: A Sets ALTERNATE addressing for "Legacy" IDE controllers same as UIDE A above Rarely necessary D: Sets a "device name" used by the CD DVD Redirector to access CD DVD drives same as UIDE D: above H Puts all but 144 bytes of the driver in HMA space See the note for UIDE H above Rnn Reserves 15 MB or 63 MB of XMS for old DOS "game" programs same as UIDE R above Rarely necessary UX Disables CD DVD UltraDMA same as UIDE UX above Rarely necessary For all switches in each driver a dash may replace the slash and lower case letters may be used if desired 5 Setup and Configuration XMGR RDISK and UIDE are all loaded using the CONFIG SYS file Your CONFIG SYS should have command lines similar to the following examples: DEVICE C: DOSDVRS XMGR SYS N128 B DEVICEHIGH C: DRIVERS RDISK COM S500 DEVICEHIGH C: SYSTEM UIDE SYS D:TOSHIBA1 S511 H DEVICEHIGH C: USERDVRS UHDD SYS S500 C80 H DEVICEHIGH C: MYDVRS UDVD2 SYS D:BLURAY1 H Note that "Int 13h" BIOS drivers must be loaded first so UIDE UHDD can intercept and cache their DOS Int 13h calls Also note that any user drivers that call UIDE to do caching must be loaded after UIDE so they will "find" UIDE in memory and can "link" to it This also applies if UHDD followed by UDVD2 are used in place of UIDE See the CONFIG SYS examples below With V3 70+ UMBPCI and XMGR a "boot" procedure is not needed UMBPCI loads first to enable upper memory then XMGR loads to offer it and XMS to DOS then other drivers may load For V6 22 V7 10 MS DOS JEMM386 can also be loaded to offer extra upper memory in the "video graphics" areas or if other JEMM386 features are desired NOTE: FreeDOS and some other DOS variants will NOT "add up" the memory found by both UMBPCI and JEMM386 like MS DOS does FreeDOS users who want extra upper memory or other items must omit UMBPCI and load JEMMEX or HIMEMX JEMM386 per their instructions or load XMGR JEMM386 as shown in the 3rd example below An example CONFIG SYS file using V3 70+ UMBPCI and XMGR is as follows: SHELL C: DOS COMMAND COM C: DOS E:512 P DEVICE C: BIN UMBPCI SYS DEVICE C: BIN XMGR SYS W DOS HIGH UMB DEVICE C: BIN JEMM386 EXE I B000 B7FF X C800 EFFF NOEMS ;Optional Int 13h drivers cached by UIDE load now DEVICEHIGH C: BIN UIDE SYS D:CDROM1 S511 C250 H ;Or UHDD plus ; UDVD2 here User drivers that call UIDE load now DEVICEHIGH C: BIN RDISK COM S250 ;Optional Etc XMGR can be used "stand alone" on a small XMS only system It must be the first DOS system driver to load and it must load in LOW memory as in the following example: SHELL C: DOS COMMAND COM C: DOS E:512 P DEVICE C: BIN XMGR SYS DOS HIGH Int 13h drivers cached by UHDD load now DEVICE C: BIN UHDD SYS S80 C15 ;Or UIDE in place DEVICE C: BIN UDVD2 SYS ; of UHDD + UDVD2 User drivers that call UHDD load now DEVICE C: BIN RDISK COM S20 ;Optional Etc With JEMM386 and XMGR XMGR loads first in "boot" mode then JEMM386 and then XMGR finally loads in upper memory JEMMEX can also be used and if so XMGR can be omitted An example CONFIG SYS file which uses the XMGR "boot" procedure is shown below Note that in this example UIDE sets a 2 GIGABYTE disk cache plus a 700 Megabyte CD DVD cache SHELL C: DOS COMMAND COM C: DOS E:512 P DEVICE C: BIN XMGR SYS B ; B for "boot" DOS HIGH UMB DEVICE C: DOS JEMM386 EXE I B000 B7FF NOEMS ;Or JEMMEX here DEVICEHIGH C: BIN XMGR SYS ;No "boot" here Int 13h drivers cached by UIDE load now DEVICEHIGH C: BIN UIDE SYS D:MYDVD S2047 C700 H ;Or UHDD plus ; UDVD2 here User drivers that call UIDE load now DEVICEHIGH C: BIN RDISK COM S500 ;Optional Etc After the above drivers are loaded further CONFIG SYS drivers SETVER ANSI SYS etc can then load in any desired order When a specific RDISK drive letter is required RDISK can now be loaded by AUTOEXEC BAT and its : switch can specify any "free" drive letter e g :Q assigns drive Q: for RDISK files Whenever RDISK is used AUTOEXEC BAT should also include commands which copy all RDISK programs and data up to the RAM disk This is required each time DOS loads as XMS memory is LOST when a system shuts down Such copies usually take little time If RDISK and UIDE UHDD are used users must balance how much XMS memory the drivers use RDISK must take no more XMS than its files may need UIDE UHDD can take most remaining XMS for its caches Some XMS memory must be saved for other programs needing it As an example on a 4 GB system RDISK might use 500 MB UIDE UHDD might use 3 GB and 500 MB is free for other programs These values can be adjusted so RDISK holds programs and "fast" data files while UIDE UHDD cache "ordinary" files Properly balanced use of XMS will give a VERY high speed DOS system Please be sure to set each hard disk"s geometry correctly in your BIOS Set it to "Auto" "LBA" or "LBA Assisted" but NOT to "None" "Normal" "CHS" "ECHS" "User Cylinders Heads Sectors" "Revised ECHS" or "Bit Shift" should run but are NOT preferred If a BIOS has a setting like "UltraDMA" or "UDMA Capable" for a disk enable it "Laptop" power saving items like a "drive spin down timeout" should run O K but must be TESTED before use All these drivers allow 7 seconds for a disk or CD DVD drive to spin up after being idle More DRASTIC power saving items like a "drive SHUTDOWN timeout" may require "extra" logic to restart the drive should be DISABLED or driver I O requests may time out Also be sure to use an 80 connector cable for any UltraDMA drive using "mode 3" ATA 44 44 MB sec or higher When cabling a single drive to an IDE channel note that you MUST use both "ends" of the cable NOT an "end" and the middle connector This prevents ERRORS since an unused cable end can pick up "noise" like a RADIO antenna Be sure to enable all CD DVD drive s through the BIOS set up routines A drive that is "disabled" may cause the BIOS to clear all its UltraDMA flags and force the drive into "PIO mode" zero which is terribly SLOW 6 Error Reporting XMGR and UIDE UHDD UDVD2 will return normal XMS and CD DVD error codes as needed They are listed in the "V3 0 XMS Specification" and in the Microsoft "MS DOS CD ROM Extensions 2 1" document Both are available from Microsoft or from other Internet sources UIDE and UHDD work as "BIOS drivers" and return whichever codes are set for diskettes and hard disks handled by the BIOS For their SATA and IDE hard disks UIDE UHDD can post the following error codes: Code 0Fh DMA error CCh Disk is FAULTED 20h Controller busy E0h Hard I O error AAh Disk not ready FFh XMS memory error Many DOS programs display only "Disk Error" messages with NO code thus disk errors may require running a diagnostic to get better information 7 Technical Notes In all of the following notes "UIDE" also applies to UHDD or UDVD2 as necessary The JEMMEX or JEMM386 drivers are now recommended for use with UIDE if using a DOS system that needs their extra upper memory DPMI VCPI logic etc Other EMM drivers are essentially "abandoned" some with never corrected ERRORS and they should NOT be used The "VirtualBox" emulator as of 15 Oct 2012 does not set a "change line available" bit in BIOS byte 0:48Fh for A: and B: diskettes UIDE will IGNORE diskette drives without a "change line" normally 1985 or older as they cannot declare "media changes" i e a NEW diskette was loaded Until "VirtualBox" gets corrected UIDE will NOT run A: or B: diskettes in such an environment UIDE"s R15 or R63 switches DOS "game" programs are for a real mode system using UMBPCI and XMGR Game players like real mode as it gives more speed If protected mode JEMM386 EMM386 is desired UIDE using a R switch must load prior to the "EMM" driver so the XMS reserved by UIDE is just beyond the HMA If using UMBPCI XMGR UIDE and then an EMM driver this works fine But FreeDOS users and others whose DOS systems permit only one XMS provider i e UMBPCI cannot be used must load XMGR HIMEMX first UIDE second into low memory upper memory isn"t yet enabled then JEMM386 EMM386 last Using JEMMEX with UIDE and a R switch is unrecommended JEMMEX must load first and takes some XMS itself which pushes the reserved XMS above its intended 16 64 MB area and a few DOS "games" programs may CRASH UIDE shall NOT include any huge AHCI logic and will run hard disks in "Legacy" "Compatibility" "Native IDE" mode when using AHCI controllers If a "new" AHCI BIOS has no such settings UIDE with a E switch should be able to call the BIOS and use its logic to handle AHCI disks NOTE that much "DOS driver" code is now being omitted in AHCI BIOS programs Thus UIDE should be TESTED before normal use with an AHCI mainboard Also note that CD DVD drives are not supported by an AHCI BIOS for file I O only for "boot" CDs On a system whose AHCI chips can be set for "Legacy" "Compatibility" "Native IDE" mode CD DVD drives should be run from AHCI ports using such modes On mainboards with no such settings UIDE can run CD DVD drives only on the parallel IDE port 80 pin cable or IDE capable "add on" cards from Promise etc that UIDE can "detect" using normal PCI bus logic UIDE handles only "Legacy" or "Native PCI" IDE controllers RAID only chipsets Via VT6420 etc "port multiplier" chips and ADMA chipsets are not currently supported AHCI is supported only through "Legacy" "Compatiblity" or "Native IDE" controller settings or by UIDE "calling the BIOS" as noted above To use UIDE a mainboard BIOS must set SATA and IDE controllers to some form of "IDE" mode not RAID ADMA AHCI for best speed If no "Legacy" "Compatibility" "Native IDE" BIOS setting for disk controllers is provided a Sabrent converter card or similar will let UIDE handle SATA hard disks or CD DVD drives from the parallel port IDE controller channel using full UltraDMA speeds Except if necessary for AHCI it is NOT RECOMMENDED for UIDE to run any DOS disk using only the BIOS Many BIOS programs have no DOS "Virtual DMA" logic If so when an EMM driver JEMM386 etc enables its "V86 protected mode" the BIOS can do only PIO mode transfers and LOSES much speed If needed get SATA to IDE adapters for SATA disks as above or get "Int 13h" disk drivers for SCSI or other disk models UIDE can then handle such disks at full DMA speeds XMGR loads in UMBPCI upper memory BEFORE that memory is declared to the DOS system Memory displays using UMBPCI may not list XMGR since its memory is not part of the DOS memory lists Such memory displays will begin with a block having a 00A7h offset or greater if using 80 or 128 XMS "Handles" The upper memory skipped by this offset contains XMGR The UMBPCI upper memory manager uses system "Shadow RAM" that CANNOT do DMA Newer BIOS programs may use UltraDMA to load programs into upper memory If this is UMBPCI "Shadow RAM" a CRASH will occur To stop this and handle new BIOS programs users should follow these two RULES for running UMBPCI together with XMGR and UIDE UHDD: A The loading "order" for V3 70+ UMBPCI and XMGR shown in section 5 above MUST be used This lets the XMGR "I O Catcher" intercept and process upper memory disk I O until UIDE UHDD loads and takes over disk UltraDMA Old UMBPCI versions or other UMBPCI loading schemes are NOT recommended B When CHS I O is done MS DOS V6 22 or older every disk MUST have valid CHS parameters Otherwise UIDE UHDD and the "I O Catcher" let the BIOS deal with CHS I O If BIOS UltraDMA is not disabled a similar "Shadow RAM" CRASH will occur Some "CD ROM boot" programs handle the CD DVD as a "fake" hard disk and provide incorrect EDD BIOS data for it In scanning for disks to use UIDE may display "EDD BIOS error Unit ignored " then go on searching for more UltraDMA disks Users who did NOT "boot" from CD DVD need to see which disk was passed over and why Users who DID "boot" from CD DVD where all SATA UltraDMA disks were found may IGNORE this message It is caused by an ERROR in the "CD ROM boot" program NOT by a problem with UIDE or its SATA UltraDMA disks Some BIOS programs do not "configure" a mainboard controller if no user drives are on it An unconfigured controller causes UIDE to display "BAD controller" then it goes on looking for others to use If this message is displayed users should verify that each SATA UltraDMA drive was made "active" thru the BIOS set up logic If so "BAD controller" says a chip was not set to both "Bus Master" and "I O Space" modes and the BIOS should be UPDATED ">XMGR RDISK and UIDE DOS Device Drivers 1 Description XMGR RDISK and UIDE are a group of DOS device drivers for a PC system with an 80386+ CPU and using MS DOS V5 0+ or equivalent XMGR is a DOS driver w [更多]
Java——list.stream().filter(item -＞ item.getType().equals(“type”)).findFirst()报空指针
允诺@晴天的博客
08-08 5459
在Java中使用。
java8 findAny()、findFirst()空指针NullPointerException问题
weixin_42260124的博客
06-30 6395
在写代码调试时，发生空指针异常，定位代码是在使用stream()的findAny()出报错，后发现是因为结果中存在null的数据，导致可空指针，findFirst()也是如此； 所以使用前先去空
在java中，list.stream().findFirst().get()与list.get(0)哪个更快？
最新发布
RichardFreedom的博客
03-31 170
在java中，list.stream().findFirst().get()与list.get(0)哪个更快？
JAVA 8 stream findfirst()、findAny、get() 报 null point exception 空指针异常
热门推荐
songbob的专栏
09-18 3万+
说明：JAVA8 用stream流来循环取LIST值时，如果值为空时会报 null point exception异常，解决办法为提前判断该值是否为空。 下面是决断为空的写法。   场景说明：我有一个产品LIST，我要遍历此LIST，生成一个MAP，key为id,value为name BEAN如下： @Setter @Getter public class Product { pri...
Stream 相关的使用
qq_36423978的博客
09-29 172
说实话现在 写stream 这博客有点 low 因为现在的jdk 已经更新到11这样了，而stream 却是在 jdk8的时候被标注为新特性，说实话习惯了 思维的定势，但是好东西还是应该被拿出来分享，况且 stream的使用加速了代码的创造。 Stream 的简述： Stream 是 Java8 中处理集合的关键抽象概念，它可以指定你希望对集合进行的操作，可以执行非常复杂的查找、过滤和映射数...
Lambda操作集合
weixin_45612363的博客
12-14 978
Lambda表达式操作集合的缺点 1.若不用并行计算，很多时候计算速度没有比传统的 for 循环快。 2.不容易使用debug模式调试。 3.在 lambda 语句中直接强制类型转换不方便。 4.不可以在foreach中修改foreach外面的值。 将集合转换为 String 类型，并用 ‘,’ 分割 Joiner.on(",").join(list) 取出对象集合中指定条件的对象(过滤) 最后结尾的.findFirst().get();是拿第一个值，如果想要集合结尾替换为.collect(Collecto
java8 stream findfirst().get()空指针 返回 No value present
ecba1988的专栏
06-19 2156
​No value present java8streamfindfirst().get()空指针 ​
线上问题：stream获取值抛出空指针及源码分析
天然玩家的博客
10-29 5011
1 Stream Stream获取数时抛出异常。 2 场景复现
4. Java Stream 中方法
静艺的专栏
03-21 2943
Stream 中方法的使用案例： limit、sorted、filter、count、findFirst、findAny、map、mapToInt、mapToLong、mapToDouble、flatMap、flatMapToInt、flatMapToLong、flatMapToDouble、anyMatch、allMatch、noneMatch、reduce、toArray 实例： 人员实体： package com.study.stream; import java.util.List; i
jdk1.8 lambda筛选集合中的元素，lambda应用
loney_wolf的博客
10-11 3817
lambda查找与匹配方法 lambda四大内置核心函数式接口 lambda查找与匹配方法 @Data public static class Employee { Employee(String name, String position, Integer salary) { this.name = name; ...
Java Stream 流实现合并操作示例
08-19
主要介绍了Java Stream 流实现合并操作,结合实例形式详细分析了Java Stream 流实现合并操作原理与相关注意事项,需要的朋友可以参考下
a project model for the FreeBSD Project.7z
08-21
A project model for the FreeBSD Project Niklas Saers Copyright © 2002-2005 Niklas Saers [ Split HTML / Single HTML ] Table of Contents Foreword 1 Overview 2 Definitions 2.1. Activity 2.2. Process 2.3. Hat 2.4. Outcome 2.5. FreeBSD 3 Organisational structure 4 Methodology model 4.1. Development model 4.2. Release branches 4.3. Model summary 5 Hats 5.1. General Hats 5.1.1. Contributor 5.1.2. Committer 5.1.3. Core Team 5.1.4. Maintainership 5.2. Official Hats 5.2.1. Documentation project manager 5.2.2. CVSup Mirror Site Coordinator 5.2.3. Internationalisation 5.2.4. Postmaster 5.2.5. Quality Assurance 5.2.6. Release Coordination 5.2.7. Public Relations & Corporate Liaison 5.2.8. Security Officer 5.2.9. Source Repository Manager 5.2.10. Election Manager 5.2.11. Web site Management 5.2.12. Ports Manager 5.2.13. Standards 5.2.14. Core Secretary 5.2.15. GNATS Administrator 5.2.16. Bugmeister 5.2.17. Donations Liaison Officer 5.2.18. Admin 5.3. Process dependent hats 5.3.1. Report originator 5.3.2. Bugbuster 5.3.3. Mentor 5.3.4. Vendor 5.3.5. Reviewers 5.3.6. CVSup Mirror Site Admin 6 Processes 6.1. Adding new and removing old committers 6.2. Adding/Removing an official CVSup Mirror 6.3. Committing code 6.4. Core election 6.5. Development of new features 6.6. Maintenance 6.7. Problem reporting 6.8. Reacting to misbehaviour 6.9. Release engineering 7 Tools 7.1. Concurrent Versions System (CVS) 7.2. CVSup 7.3. GNATS 7.4. Mailman 7.5. Perforce 7.6. Pretty Good Privacy 7.7. Secure Shell 8 Sub-projects 8.1. The Ports Subproject 8.2. The FreeBSD Documentation Project References List of Figures 3-1. The FreeBSD Project's structure 3-2. The FreeBSD Project's structure with committers in categories 4-1. Jørgenssen's model for change integration 4-2. The FreeBSD release tree 4-3. The overall development model 5-1. Overview of official hats 6-1. Process summary: adding a new committer 6-2. Process summary: removing a committer 6-3. Process summary: adding a CVSup mirror 6-4. Process summary: A committer commits code 6-5. Process summary: A contributor commits code 6-6. Process summary: Core elections 6-7. Jørgenssen's model for change integration 6-8. Process summary: problem reporting 6-9. Process summary: release engineering 8-1. Number of ports added between 1996 and 2005 Foreword Up until now, the FreeBSD project has released a number of described techniques to do different parts of work. However, a project model summarising how the project is structured is needed because of the increasing amount of project members. [1] This paper will provide such a project model and is donated to the FreeBSD Documentation project where it can evolve together with the project so that it can at any point in time reflect the way the project works. It is based on [Saers, 2003]. I would like to thank the following people for taking the time to explain things that were unclear to me and for proofreading the document. Andrey A. Chernov <[email protected]> Bruce A. Mah <[email protected]> Dag-Erling Smørgrav <[email protected]> Giorgos Keramidas<[email protected]> Ingvil Hovig <[email protected]> Jesper Holck<[email protected]> John Baldwin <[email protected]> John Polstra <[email protected]> Kirk McKusick <[email protected]> Mark Linimon <[email protected]> Marleen Devos Niels Jørgenssen<[email protected]> Nik Clayton <[email protected]> Poul-Henning Kamp <[email protected]> Simon L. Nielsen <[email protected]> Chapter 1 Overview A project model is a means to reduce the communications overhead in a project. As shown by [Brooks, 1995], increasing the number of project participants increases the communication in the project exponentionally. FreeBSD has during the past few year increased both its mass of active users and committers, and the communication in the project has risen accordingly. This project model will serve to reduce this overhead by providing an up-to-date description of the project. During the Core elections in 2002, Mark Murray stated “I am opposed to a long rule-book, as that satisfies lawyer-tendencies, and is counter to the technocentricity that the project so badly needs.” [FreeBSD, 2002B]. This project model is not meant to be a tool to justify creating impositions for developers, but as a tool to facilitate coordination. It is meant as a description of the project, with an overview of how the different processes are executed. It is an introduction to how the FreeBSD project works. The FreeBSD project model will be described as of July 1st, 2004. It is based on the Niels Jørgensen's paper [Jørgensen, 2001], FreeBSD's official documents, discussions on FreeBSD mailing lists and interviews with developers. After providing definitions of terms used, this document will outline the organisational structure (including role descriptions and communication lines), discuss the methodology model and after presenting the tools used for process control, it will present the defined processes. Finally it will outline major sub-projects of the FreeBSD project. [FreeBSD, 2002A, Section 1.2 and 1.3] give the vision and the architectural guidelines for the project. The vision is “To produce the best UNIX-like operating system package possible, with due respect to the original software tools ideology as well as usability, performance and stability.” The architectural guidelines help determine whether a problem that someone wants to be solved is within the scope of the project Chapter 2 Definitions 2.1. Activity An “activity” is an element of work performed during the course of a project [PMI, 2000]. It has an output and leads towards an outcome. Such an output can either be an input to another activity or a part of the process' delivery. 2.2. Process A “process” is a series of activities that lead towards a particular outcome. A process can consist of one or more sub-processes. An example of a process is software design. 2.3. Hat A “hat” is synonymous with role. A hat has certain responsibilities in a process and for the process outcome. The hat executes activities. It is well defined what issues the hat should be contacted about by the project members and people outside the project. 2.4. Outcome An “outcome” is the final output of the process. This is synonymous with deliverable, that is defined as “any measurable, tangible, verifiable outcome, result or item that must be produced to complete a project or part of a project. Often used more narrowly in reference to an external deliverable, which is a deliverable that is subject to approval by the project sponsor or customer” by [PMI, 2000]. Examples of outcomes are a piece of software, a decision made or a report written. 2.5. FreeBSD When saying “FreeBSD” we will mean the BSD derivative UNIX-like operating system FreeBSD, whereas when saying “the FreeBSD Project” we will mean the project organisation. Chapter 3 Organisational structure While no-one takes ownership of FreeBSD, the FreeBSD organisation is divided into core, committers and contributors and is part of the FreeBSD community that lives around it. Figure 3-1. The FreeBSD Project's structure Number of committers has been determined by going through CVS logs from January 1st, 2004 to December 31st, 2004 and contributors by going through the list of contributions and problem reports. The main resource in the FreeBSD community is its developers: the committers and contributors. It is with their contributions that the project can move forward. Regular developers are referred to as contributors. As by January 1st, 2003, there are an estimated 5500 contributors on the project. Committers are developers with the privilege of being able to commit changes. These are usually the most active developers who are willing to spend their time not only integrating their own code but integrating code submitted by the developers who do not have this privilege. They are also the developers who elect the core team, and they have access to closed discussions. The project can be grouped into four distinct separate parts, and most developers will focus their involvement in one part of FreeBSD. The four parts are kernel development, userland development, ports and documentation. When referring to the base system, both kernel and userland is meant. This split changes our triangle to look like this: Figure 3-2. The FreeBSD Project's structure with committers in categories Number of committers per area has been determined by going through CVS logs from January 1st, 2004 to December 31st, 2004. Note that many committers work in multiple areas, making the total number higher than the real number of committers. The total number of committers at that time was 269. Committers fall into three groups: committers who are only concerned with one area of the project (for instance file systems), committers who are involved only with one sub-project and committers who commit to different parts of the code, including sub-projects. Because some committers work on different parts, the total number in the committers section of the triangle is higher than in the above triangle. The kernel is the main building block of FreeBSD. While the userland applications are protected against faults in other userland applications, the entire system is vulnerable to errors in the kernel. This, combined with the vast amount of dependencies in the kernel and that it is not easy to see all the consequences of a kernel change, demands developers with a relative full understanding of the kernel. Multiple development efforts in the kernel also requires a closer coordination than userland applications do. The core utilities, known as userland, provide the interface that identifies FreeBSD, both user interface, shared libraries and external interfaces to connecting clients. Currently, 162 people are involved in userland development and maintenance, many being maintainers for their own part of the code. Maintainership will be discussed in the Maintainership section. Documentation is handled by The FreeBSD Documentation Project and includes all documents surrounding the FreeBSD project, including the web pages. There were during 2004 101 people making commits to the FreeBSD Documentation Project. Ports is the collection of meta-data that is needed to make software packages build correctly on FreeBSD. An example of a port is the port for the web-browser Mozilla. It contains information about where to fetch the source, what patches to apply and how, and how the package should be installed on the system. This allows automated tools to fetch, build and install the package. As of this writing, there are more than 12600 ports available. [2] , ranging from web servers to games, programming languages and most of the application types that are in use on modern computers. Ports will be discussed further in the section The Ports Subproject. Chapter 4 Methodology model 4.1. Development model There is no defined model for how people write code in FreeBSD. However, Niels Jørgenssen has suggested a model of how written code is integrated into the project. Figure 4-1. Jørgenssen's model for change integration The “development release” is the FreeBSD-CURRENT ("-CURRENT") branch and the “production release” is the FreeBSD-STABLE branch ("-STABLE") [Jørgensen, 2001]. This is a model for one change, and shows that after coding, developers seek community review and try integrating it with their own systems. After integrating the change into the development release, called FreeBSD-CURRENT, it is tested by many users and developers in the FreeBSD community. After it has gone through enough testing, it is merged into the production release, called FreeBSD-STABLE. Unless each stage is finished successfully, the developer needs to go back and make modifications in the code and restart the process. To integrate a change with either -CURRENT or -STABLE is called making a commit. Jørgensen found that most FreeBSD developers work individually, meaning that this model is used in parallel by many developers on the different ongoing development efforts. A developer can also be working on multiple changes, so that while he is waiting for review or people to test one or more of his changes, he may be writing another change. As each commit represents an increment, this is a massively incremental model. The commits are in fact so frequent that during one year [3] , 85427 commits were made, making a daily average of 233 commits. Within the “code” bracket in Jørgensen's figure, each programmer has his own working style and follows his own development models. The bracket could very well have been called “development” as it includes requirements gathering and analysis, system and detailed design, implementation and verification. However, the only output from these stages is the source code or system documentation. From a stepwise model's perspective (such as the waterfall model), the other brackets can be seen as further verification and system integration. This system integration is also important to see if a change is accepted by the community. Up until the code is committed, the developer is free to choose how much to communicate about it to the rest of the project. In order for -CURRENT to work as a buffer (so that bright ideas that had some undiscovered drawbacks can be backed out) the minimum time a commit should be in -CURRENT before merging it to -STABLE is 3 days. Such a merge is referred to as an MFC (Merge From Current). It is important to notice the word “change”. Most commits do not contain radical new features, but are maintenance updates. The only exceptions from this model are security fixes and changes to features that are deprecated in the -CURRENT branch. In these cases, changes can be committed directly to the -STABLE branch. In addition to many people working on the project, there are many related projects to the FreeBSD Project. These are either projects developing brand new features, sub-projects or projects whose outcome is incorporated into FreeBSD [4]. These projects fit into the FreeBSD Project just like regular development efforts: they produce code that is integrated with the FreeBSD Project. However, some of them (like Ports and Documentation) have the privilege of being applicable to both branches or commit directly to both -CURRENT and -STABLE. There is no standards to how design should be done, nor is design collected in a centralised repository. The main design is that of 4.4BSD. [5] As design is a part of the “Code” bracket in Jørgenssen's model, it is up to every developer or sub-project how this should be done. Even if the design should be stored in a central repository, the output from the design stages would be of limited use as the differences of methodologies would make them poorly if at all interoperable. For the overall design of the project, the project relies on the sub-projects to negotiate fit interfaces between each other rather than to dictate interfacing. 4.2. Release branches The releases of FreeBSD is best illustrated by a tree with many branches where each major branch represents a major version. Minor versions are represented by branches of the major branches. In the following release tree, arrows that follow one-another in a particular direction represent a branch. Boxes with full lines and diamonds represent official releases. Boxes with dotted lines represent the development branch at that time. Security branches are represented by ovals. Diamonds differ from boxes in that they represent a fork, meaning a place where a branch splits into two branches where one of the branches becomes a sub-branch. For example, at 4.0-RELEASE the 4.0-CURRENT branch split into 4-STABLE and 5.0-CURRENT. At 4.5-RELEASE, the branch forked off a security branch called RELENG_4_5. Figure 4-2. The FreeBSD release tree The latest -CURRENT version is always referred to as -CURRENT, while the latest -STABLE release is always referred to as -STABLE. In this figure, -STABLE refers to 4-STABLE while -CURRENT refers to 5.0-CURRENT following 5.0-RELEASE. [FreeBSD, 2002E] A “major release” is always made from the -CURRENT branch. However, the -CURRENT branch does not need to fork at that point in time, but can focus on stabilising. An example of this is that following 3.0-RELEASE, 3.1-RELEASE was also a continuation of the -CURRENT-branch, and -CURRENT did not become a true development branch until this version was released and the 3-STABLE branch was forked. When -CURRENT returns to becoming a development branch, it can only be followed by a major release. 5-STABLE is predicted to be forked off 5.0-CURRENT at around 5.3-RELEASE. It is not until 5-STABLE is forked that the development branch will be branded 6.0-CURRENT. A “minor release” is made from the -CURRENT branch following a major release, or from the -STABLE branch. Following and including, 4.3-RELEASE[6], when a minor release has been made, it becomes a “security branch”. This is meant for organisations that do not want to follow the -STABLE branch and the potential new/changed features it offers, but instead require an absolutely stable environment, only updating to implement security updates. [7] Each update to a security branch is called a “patchlevel”. For every security enhancement that is done, the patchlevel number is increased, making it easy for people tracking the branch to see what security enhancements they have implemented. In cases where there have been especially serious security flaws, an entire new release can be made from a security branch. An example of this is 4.6.2-RELEASE. 4.3. Model summary To summarise, the development model of FreeBSD can be seen as the following tree: Figure 4-3. The overall development model The tree of the FreeBSD development with ongoing development efforts and continuous integration. The tree symbolises the release versions with major versions spawning new main branches and minor versions being versions of the main branch. The top branch is the -CURRENT branch where all new development is integrated, and the -STABLE branch is the branch directly below it. Clouds of development efforts hang over the project where developers use the development models they see fit. The product of their work is then integrated into -CURRENT where it undergoes parallel debugging and is finally merged from -CURRENT into -STABLE. Security fixes are merged from -STABLE to the security branches. Chapter 5 Hats Many committers have a special area of responsibility. These roles are called hats [Losh, 2002]. These hats can be either project roles, such as public relations officer, or maintainer for a certain area of the code. Because this is a project where people give voluntarily of their spare time, people with assigned hats are not always available. They must therefore appoint a deputy that can perform the hat's role in his or her absence. The other option is to have the role held by a group. Many of these hats are not formalised. Formalised hats have a charter stating the exact purpose of the hat along with its privileges and responsibilities. The writing of such charters is a new part of the project, and has thus yet to be completed for all hats. These hat descriptions are not such a formalisation, rather a summary of the role with links to the charter where available and contact addresses, 5.1. General Hats 5.1.1. Contributor A Contributor contributes to the FreeBSD project either as a developer, as an author, by sending problem reports, or in other ways contributing to the progress of the project. A contributor has no special privileges in the FreeBSD project. [FreeBSD, 2002F] 5.1.2. Committer A person who has the required privileges to add his code or documentation to the repository. A committer has made a commit within the past 12 months. [FreeBSD, 2000A] An active committer is a committer who has made an average of one commit per month during that time. It is worth noting that there are no technical barriers to prevent someone, once having gained commit privileges to the main- or a sub-project, to make commits in parts of that project's source the committer did not specifically get permission to modify. However, when wanting to make modifications to parts a committer has not been involved in before, he/she should read the logs to see what has happened in this area before, and also read the MAINTAINER file to see if the maintainer of this part has any special requests on how changes in the code should be made 5.1.3. Core Team The core team is elected by the committers from the pool of committers and serves as the board of directors of the FreeBSD project. It promotes active contributors to committers, assigns people to well-defined hats, and is the final arbiter of decisions involving which way the project should be heading. As by July 1st, 2004, core consisted of 9 members. Elections are held every two years. 5.1.4. Maintainership Maintainership means that that person is responsible for what is allowed to go into that area of the code and has the final say should disagreements over the code occur. This involves involves proactive work aimed at stimulating contributions and reactive work in reviewing commits. With the FreeBSD source comes the MAINTAINERS file that contains a one-line summary of how each maintainer would like contributions to be made. Having this notice and contact information enables developers to focus on the development effort rather than being stuck in a slow correspondence should the maintainer be unavailable for some time. If the maintainer is unavailable for an unreasonably long period of time, and other people do a significant amount of work, maintainership may be switched without the maintainer's approval. This is based on the stance that maintainership should be demonstrated, not declared. Maintainership of a particular piece of code is a hat that is not held as a group. 5.2. Official Hats The official hats in the FreeBSD Project are hats that are more or less formalised and mainly administrative roles. They have the authority and responsibility for their area. The following illustration shows the responsibility lines. After this follows a description of each hat, including who it is held by. Figure 5-1. Overview of official hats All boxes consist of groups of committers, except for the dotted boxes where the holders are not necessarily committers. The flattened circles are sub-projects and consist of both committers and non-committers of the main project. 5.2.1. Documentation project manager The FreeBSD Documentation Project architect is responsible for defining and following up documentation goals for the committers in the Documentation project. Hat held by: The DocEng team <[email protected]>. The DocEng Charter. 5.2.2. CVSup Mirror Site Coordinator The CVSup Mirror Site Coordinator coordinates all the CVSup Mirror Site Admins to ensure that they are distributing current versions of the software, that they have the capacity to update themselves when major updates are in progress, and making it easy for the general public to find their closest CVSup mirror. Hat currently held by: John Polstra <[email protected]>. 5.2.3. Internationalisation The Internationalisation hat is responsible for coordinating the localisation efforts of the FreeBSD kernel and userland utilities. The translation effort are coordinated by The FreeBSD Documentation Project. The Internationalisation hat should suggest and promote standards and guidelines for writing and maintaining the software in a fashion that makes it easier to translate. Hat currently available. 5.2.4. Postmaster The Postmaster is responsible for mail being correctly delivered to the committers' email address. He is also responsible for ensuring that the mailing lists work and should take measures against possible disruptions of mail such as having troll-, spam- and virus-filters. Hat currently held by: David Wolfskill <[email protected]>. 5.2.5. Quality Assurance The responsibilities of this role are to manage the quality assurance measures. Hat currently held by: Robert Watson <[email protected]>. 5.2.6. Release Coordination The responsibilities of the Release Engineering Team are Setting, publishing and following a release schedule for official releases Documenting and formalising release engineering procedures Creation and maintenance of code branches Coordinating with the Ports and Documentation teams to have an updated set of packages and documentation released with the new releases Coordinating with the Security team so that pending releases are not affected by recently disclosed vulnerabilities. Further information about the development process is available in the release engineering section. Hat held by: the Release Engineering team <[email protected]>, currently headed by Murray Stokely <[email protected]>. The Release Engineering Charter. 5.2.7. Public Relations & Corporate Liaison The Public Relations & Corporate Liaison's responsibilities are: Making press statements when happenings that are important to the FreeBSD Project happen. Being the official contact person for corporations that are working close with the FreeBSD Project. Take steps to promote FreeBSD within both the Open Source community and the corporate world. Handle the “freebsd-advocacy” mailing list. This hat is currently not occupied. 5.2.8. Security Officer The Security Officer's main responsibility is to coordinate information exchange with others in the security community and in the FreeBSD project. The Security Officer is also responsible for taking action when security problems are reported and promoting proactive development behaviour when it comes to security. Because of the fear that information about vulnerabilities may leak out to people with malicious intent before a patch is available, only the Security Officer, consisting of an officer, a deputy and two Core team members, receive sensitive information about security issues. However, to create or implement a patch, the Security Officer has the Security Officer Team <[email protected]> to help do the work. Hat held by: the Security Officer <[email protected]>, currently headed by Colin Percival <[email protected]>. The Security Officer and The Security Officer Team's charter. 5.2.9. Source Repository Manager The Source Repository Manager is the only one who is allowed to directly modify the repository without using the CVS tool. It is his/her responsibility to ensure that technical problems that arise in the repository are resolved quickly. The source repository manager has the authority to back out commits if this is necessary to resolve a CVS technical problem. Hat held by: the Source Repository Manager <[email protected]>, currently headed by Peter Wemm <[email protected]>. 5.2.10. Election Manager The Election Manager is responsible for the Core election process. The manager is responsible for running and maintaining the election system, and is the final authority should minor unforseen events happen in the election process. Major unforseen events have to be discussed with the Core team Hat held only during elections. 5.2.11. Web site Management The Web site Management hat is responsible for coordinating the rollout of updated web pages on mirrors around the world, for the overall structure of the primary web site and the system it is running upon. The management needs to coordinate the content with The FreeBSD Documentation Project and acts as maintainer for the “www” tree. Hat held by: the FreeBSD Webmasters <[email protected]>. 5.2.12. Ports Manager The Ports Manager acts as a liaison between The Ports Subproject and the core project, and all requests from the project should go to the ports manager. Hat held by: the Ports Management Team <[email protected]>, 5.2.13. Standards The Standards hat is responsible for ensuring that FreeBSD complies with the standards it is committed to , keeping up to date on the development of these standards and notifying FreeBSD developers of important changes that allows them to take a proactive role and decrease the time between a standards update and FreeBSD's compliancy. Hat currently held by: Garrett Wollman <[email protected]>. 5.2.14. Core Secretary The Core Secretary's main responsibility is to write drafts to and publish the final Core Reports. The secretary also keeps the core agenda, thus ensuring that no balls are dropped unresolved. Hat currently held by: Joel Dahl <[email protected]>. 5.2.15. GNATS Administrator The GNATS Administrator is responsible for ensuring that the maintenance database is in working order, that the entries are correctly categorised and that there are no invalid entries. Hat currently held by: Ceri Davies <[email protected]> and Mark Linimon <[email protected]>. 5.2.16. Bugmeister The Bugmeister is the person in charge of the problem report group. Hat currently held by: Ceri Davies <[email protected]> and Mark Linimon <[email protected]>. 5.2.17. Donations Liaison Officer The task of the donations liason officer is to match the developers with needs with people or organisations willing to make a donation. The Donations Liason Charter is available here Hat held by: the Donations Liaison Office <[email protected]>, currently headed by Michael W. Lucas <[email protected]>. 5.2.18. Admin (Also called “FreeBSD Cluster Admin”) The admin team consists of the people responsible for administrating the computers that the project relies on for its distributed work and communication to be synchronised. It consists mainly of those people who have physical access to the servers. Hat held by: the Admin team <[email protected]>, currently headed by Mark Murray <[email protected]> 5.3. Process dependent hats 5.3.1. Report originator The person originally responsible for filing a Problem Report. 5.3.2. Bugbuster A person who will either find the right person to solve the problem, or close the PR if it is a duplicate or otherwise not an interesting one. 5.3.3. Mentor A mentor is a committer who takes it upon him/her to introduce a new committer to the project, both in terms of ensuring the new committers setup is valid, that the new committer knows the available tools required in his/her work and that the new committer knows what is expected of him/her in terms of behaviour. 5.3.4. Vendor The person(s) or organisation whom external code comes from and whom patches are sent to. 5.3.5. Reviewers People on the mailing list where the request for review is posted. 5.3.6. CVSup Mirror Site Admin A CVSup Mirror Site Admin has accesses to a server that he/she uses to mirror the CVS repository. The admin works with the CVSup Mirror Site Coordinator to ensure the site remains up-to-date and is following the general policy of official mirror sites. Chapter 6 Processes The following section will describe the defined project processes. Issues that are not handled by these processes happen on an ad-hoc basis based on what has been customary to do in similar cases. 6.1. Adding new and removing old committers The Core team has the responsibility of giving and removing commit privileges to contributors. This can only be done through a vote on the core mailing list. The ports and documentation sub-projects can give commit privileges to people working on these projects, but have to date not removed such privileges. Normally a contributor is recommended to core by a committer. For contributors or outsiders to contact core asking to be a committer is not well thought of and is usually rejected. If the area of particular interest for the developer potentially overlaps with other committers' area of maintainership, the opinion of those maintainers is sought. However, it is frequently this committer that recommends the developer. When a contributor is given committer status, he is assigned a mentor. The committer who recommended the new committer will, in the general case, take it upon himself to be the new committers mentor. When a contributor is given his commit bit, a PGP-signed email is sent from either Core Secretary, Ports Manager or [email protected] to both [email protected], the assigned mentor, the new committer and core confirming the approval of a new account. The mentor then gathers a password line, SSH 2 public key and PGP key from the new committer and sends them to Admin. When the new account is created, the mentor activates the commit bit and guides the new committer through the rest of the initial process. Figure 6-1. Process summary: adding a new committer When a contributor sends a piece of code, the receiving committer may choose to recommend that the contributor is given commit privileges. If he recommends this to core, they will vote on this recommendation. If they vote in favour, a mentor is assigned the new committer and the new committer has to email his details to the administrators for an account to be created. After this, the new committer is all set to make his first commit. By tradition, this is by adding his name to the committers list. Recall that a committer is considered to be someone who has committed code during the past 12 months. However, it is not until after 18 months of inactivity have passed that commit privileges are eligible to be revoked. [FreeBSD, 2002H] There are, however, no automatic procedures for doing this. For reactions concerning commit privileges not triggered by time, see section 1.5.8. Figure 6-2. Process summary: removing a committer When Core decides to clean up the committers list, they check who has not made a commit for the past 18 months. Committers who have not done so have their commit bits revoked. It is also possible for committers to request that their commit bit be retired if for some reason they are no longer going to be actively committing to the project. In this case, it can also be restored at a later time by core, should the committer ask. Roles in this process: Core team Contributor Committer Maintainership Mentor [FreeBSD, 2000A] [FreeBSD, 2002H] [FreeBSD, 2002I] 6.2. Adding/Removing an official CVSup Mirror A CVSup mirror is a replica of the official CVSup master that contains all the up-to-date source code for all the branches in the FreeBSD project, ports and documentation. Adding an official CVSup mirror starts with the potential CVSup Mirror Site Admin installing the “cvsup-mirror” package. Having done this and updated the source code with a mirror site, he now runs a fairly recent unofficial CVSup mirror. Deciding he has a stable environment, the processing power, the network capacity and the storage capacity to run an official mirror, he mails the CVSup Mirror Site Coordinator who decides whether the mirror should become an official mirror or not. In making this decision, the CVSup Mirror Site Coordinator has to determine whether that geographical area needs another mirror site, if the mirror administrator has the skills to run it reliably, if the network bandwidth is adequate and if the master server has the capacity to server another mirror. If CVSup Mirror Site Coordinator decides that the mirror should become an official mirror, he obtains an authentication key from the mirror admin that he installs so the mirror admin can update the mirror from the master server. Figure 6-3. Process summary: adding a CVSup mirror When a CVSup mirror administrator of an unofficial mirror offers to become an official mirror site, the CVSup coordinator decides if another mirror is needed and if there is sufficient capacity to accommodate it. If so, an authorisation key is requested and the mirror is given access to the main distribution site and added to the list of official mirrors. Tools used in this process: CVSup SSH 2 Hats involved in this process: CVSup Mirror Site Coordinator CVSup Mirror Site Admin 6.3. Committing code The committing of new or modified code is one of the most frequent processes in the FreeBSD project and will usually happen many times a day. Committing of code can only be done by a “committer”. Committers commit either code written by themselves, code submitted to them or code submitted through a problem report. When code is written by the developer that is non-trivial, he should seek a code review from the community. This is done by sending mail to the relevant list asking for review. Before submitting the code for review, he should ensure it compiles correctly with the entire tree and that all relevant tests run. This is called “pre-commit test”. When contributed code is received, it should be reviewed by the committer and tested the same way. When a change is committed to a part of the source that has been contributed from an outside Vendor, the maintainer should ensure that the patch is contributed back to the vendor. This is in line with the open source philosophy and makes it easier to stay in sync with outside projects as the patches do not have to be reapplied every time a new release is made. After the code has been available for review and no further changes are necessary, the code is committed into the development branch, -CURRENT. If the change applies for the -STABLE branch or the other branches as well, a “Merge From Current” ("MFC") countdown is set by the committer. After the number of days the committer chose when setting the MFC have passed, an email will automatically be sent to the committer reminding him to commit it to the -STABLE branch (and possibly security branches as well). Only security critical changes should be merged to security branches. Delaying the commit to -STABLE and other branches allows for “parallel debugging” where the committed code is tested on a wide range of configurations. This makes changes to -STABLE to contain fewer faults and thus giving the branch its name. Figure 6-4. Process summary: A committer commits code When a committer has written a piece of code and wants to commit it, he first needs to determine if it is trivial enough to go in without prior review or if it should first be reviewed by the developer community. If the code is trivial or has been reviewed and the committer is not the maintainer, he should consult the maintainer before proceeding. If the code is contributed by an outside vendor, the maintainer should create a patch that is sent back to the vendor. The code is then committed and the deployed by the users. Should they find problems with the code, this will be reported and the committer can go back to writing a patch. If a vendor is affected, he can choose to implement or ignore the patch. Figure 6-5. Process summary: A contributor commits code The difference when a contributor makes a code contribution is that he submits the code through the send-pr program. This report is picked up by the maintainer who reviews the code and commits it. Hats included in this process are: Committer Contributor Vendor Reviewer [FreeBSD, 2001] [Jørgensen, 2001] 6.4. Core election Core elections are held at least every two years. [8] Nine core members are elected. New elections are held if the number of core members drops below seven. New elections can also be held should at least 1/3 of the active committers demand this. When an election is to take place, core announces this at least 6 weeks in advance, and appoints an election manager to run the elections. Only committers can be elected into core. The candidates need to submit their candidacy at least one week before the election starts, but can refine their statements until the voting starts. They are presented in the candidates list. When writing their election statements, the candidates must answer a few standard questions submitted by the election manager. During elections, the rule that a committer must have committed during the 12 past months is followed strictly. Only these committers are eligible to vote. When voting, the committer may vote once in support of up to nine nominees. The voting is done over a period of four weeks with reminders being posted on “developers” mailing list that is available to all committers. The election results are released one week after the election ends, and the new core team takes office one week after the results have been posted. Should there be a voting tie, this will be resolved by the new, unambiguously elected core members. Votes and candidate statements are archived, but the archives are not publicly available. Figure 6-6. Process summary: Core elections Core announces the election and selects an election manager. He prepares the elections, and when ready, candidates can announce their candidacies through submitting their statements. The committers then vote. After the vote is over, the election results are announced and the new core team takes office. Hats in core elections are: Core team Committer Election Manager [FreeBSD, 2000A] [FreeBSD, 2002B] [FreeBSD, 2002G] 6.5. Development of new features Within the project there are sub-projects that are working on new features. These projects are generally done by one person [Jørgensen, 2001]. Every project is free to organise development as it sees fit. However, when the project is merged to the -CURRENT branch it must follow the project guidelines. When the code has been well tested in the -CURRENT branch and deemed stable enough and relevant to the -STABLE branch, it is merged to the -STABLE branch. The requirements of the project are given by developer wishes, requests from the community in terms of direct requests by mail, Problem Reports, commercial funding for the development of features, or contributions by the scientific community. The wishes that come within the responsibility of a developer are given to that developer who prioritises his time between the request and his wishes. A common way to do this is maintain a TODO-list maintained by the project. Items that do not come within someone's responsibility are collected on TODO-lists unless someone volunteers to take the responsibility. All requests, their distribution and follow-up are handled by the GNATS tool. Requirements analysis happens in two ways. The requests that come in are discussed on mailing lists, both within the main project and in the sub-project that the request belongs to or is spawned by the request. Furthermore, individual developers on the sub-project will evaluate the feasibility of the requests and determine the prioritisation between them. Other than archives of the discussions that have taken place, no outcome is created by this phase that is merged into the main project. As the requests are prioritised by the individual developers on the basis of doing what they find interesting, necessary or are funded to do, there is no overall strategy or priorisation of what requests to regard as requirements and following up their correct implementation. However, most developers have some shared vision of what issues are more important, and they can ask for guidelines from the release engineering team. The verification phase of the project is two-fold. Before committing code to the current-branch, developers request their code to be reviewed by their peers. This review is for the most part done by functional testing, but also code review is important. When the code is committed to the branch, a broader functional testing will happen, that may trigger further code review and debugging should the code not behave as expected. This second verification form may be regarded as structural verification. Although the sub-projects themselves may write formal tests such as unit tests, these are usually not collected by the main project and are usually removed before the code is committed to the current branch. [9] 6.6. Maintenance It is an advantage to the project to for each area of the source have at least one person that knows this area well. Some parts of the code have designated maintainers. Others have de-facto maintainers, and some parts of the system do not have maintainers. The maintainer is usually a person from the sub-project that wrote and integrated the code, or someone who has ported it from the platform it was written for. [10] The maintainer's job is to make sure the code is in sync with the project the code comes from if it is contributed code, and apply patches submitted by the community or write fixes to issues that are discovered. The main bulk of work that is put into the FreeBSD project is maintenance. [Jørgensen, 2001] has made a figure showing the life cycle of changes. Figure 6-7. Jørgenssen's model for change integration Here “development release” refers to the -CURRENT branch while “production release” refers to the -STABLE branch. The “pre-commit test” is the functional testing by peer developers when asked to do so or trying out the code to determine the status of the sub-project. “Parallel debugging” is the functional testing that can trigger more review, and debugging when the code is included in the -CURRENT branch. As of this writing, there were 269 committers in the project. When they commit a change to a branch, that constitutes a new release. It is very common for users in the community to track a particular branch. The immediate existence of a new release makes the changes widely available right away and allows for rapid feedback from the community. This also gives the community the response time they expect on issues that are of importance to them. This makes the community more engaged, and thus allows for more and better feedback that again spurs more maintenance and ultimately should create a better product. Before making changes to code in parts of the tree that has a history unknown to the committer, the committer is required to read the commit logs to see why certain features are implemented the way they are in order not to make mistakes that have previously either been thought through or resolved. 6.7. Problem reporting FreeBSD comes with a problem reporting tool called “send-pr” that is a part of the GNATS package. All users and developers are encouraged to use this tool for reporting problems in software they do not maintain. Problems include bug reports, feature requests, features that should be enhanced and notices of new versions of external software that is included in the project. Problem reports are sent to an email address where it is inserted into the GNATS maintenance database. A Bugbuster classifies the problem and sends it to the correct group or maintainer within the project. After someone has taken responsibility for the report, the report is being analysed. This analysis includes verifying the problem and thinking out a solution for the problem. Often feedback is required from the report originator or even from the FreeBSD community. Once a patch for the problem is made, the originator may be asked to try it out. Finally, the working patch is integrated into the project, and documented if applicable. It there goes through the regular maintenance cycle as described in section maintenance. These are the states a problem report can be in: open, analyzed, feedback, patched, suspended and closed. The suspended state is for when further progress is not possible due to the lack of information or for when the task would require so much work that nobody is working on it at the moment. Figure 6-8. Process summary: problem reporting A problem is reported by the report originator. It is then classified by a bugbuster and handed to the correct maintainer. He verifies the problem and discusses the problem with the originator until he has enough information to create a working patch. This patch is then committed and the problem report is closed. The roles included in this process are: Report originator Maintainership Bugbuster [FreeBSD, 2002C]. [FreeBSD, 2002D] 6.8. Reacting to misbehaviour [FreeBSD, 2001] has a number of rules that committers should follow. However, it happens that these rules are broken. The following rules exist in order to be able to react to misbehaviour. They specify what actions will result in how long a suspension the committer's commit privileges. Committing during code freezes without the approval of the Release Engineering team - 2 days Committing to a security branch without approval - 2 days Commit wars - 5 days to all participating parties Impolite or inappropriate behaviour - 5 days [Lehey, 2002] For the suspensions to be efficient, any single core member can implement a suspension before discussing it on the “core” mailing list. Repeat offenders can, with a 2/3 vote by core, receive harsher penalties, including permanent removal of commit privileges. (However, the latter is always viewed as a last resort, due to its inherent tendency to create controversy). All suspensions are posted to the “developers” mailing list, a list available to committers only. It is important that you cannot be suspended for making technical errors. All penalties come from breaking social etiquette. Hats involved in this process: Core team Committer 6.9. Release engineering The FreeBSD project has a Release Engineering team with a principal release engineer that is responsible for creating releases of FreeBSD that can be brought out to the user community via the net or sold in retail outlets. Since FreeBSD is available on multiple platforms and releases for the different architectures are made available at the same time, the team has one person in charge of each architecture. Also, there are roles in the team responsible for coordinating quality assurance efforts, building a package set and for having an updated set of documents. When referring to the release engineer, a representative for the release engineering team is meant. When a release is coming, the FreeBSD project changes shape somewhat. A release schedule is made containing feature- and code-freezes, release of interim releases and the final release. A feature-freeze means no new features are allowed to be committed to the branch without the release engineers' explicit consent. Code-freeze means no changes to the code (like bugs-fixes) are allowed to be committed without the release engineers explicit consent. This feature- and code-freeze is known as stabilising. During the release process, the release engineer has the full authority to revert to older versions of code and thus "back out" changes should he find that the changes are not suitable to be included in the release. There are three different kinds of releases: .0 releases are the first release of a major version. These are branched of the -CURRENT branch and have a significantly longer release engineering cycle due to the unstable nature of the -CURRENT branch .X releases are releases of the -STABLE branch. They are scheduled to come out every 4 months. .X.Y releases are security releases that follow the .X branch. These come out only when sufficient security fixes have been merged since the last release on that branch. New features are rarely included, and the security team is far more involved in these than in regular releases. For releases of the -STABLE-branch, the release process starts 45 days before the anticipated release date. During the first phase, the first 15 days, the developers merge what changes they have had in -CURRENT that they want to have in the release to the release branch. When this period is over, the code enters a 15 day code freeze in which only bug fixes, documentation updates, security-related fixes and minor device driver changes are allowed. These changes must be approved by the release engineer in advance. At the beginning of the last 15 day period a release candidate is created for widespread testing. Updates are less likely to be allowed during this period, except for important bug fixes and security updates. In this final period, all releases are considered release candidates. At the end of the release process, a release is created with the new version number, including binary distributions on web sites and the creation of a CD-ROM images. However, the release is not considered "really released" until a PGP-signed message stating exactly that, is sent to the mailing list freebsd-announce; anything labelled as a "release" before that may well be in-process and subject to change before the PGP-signed message is sent. [11]. The releases of the -CURRENT-branch (that is, all releases that end with “.0”) are very similar, but with twice as long timeframe. It starts 8 weeks prior to the release with announcement of the release time line. Two weeks into the release process, the feature freeze is initiated and performance tweaks should be kept to a minimum. Four weeks prior to the release, an official beta version is made available. Two weeks prior to release, the code is officially branched into a new version. This version is given release candidate status, and as with the release engineering of -STABLE, the code freeze of the release candidate is hardened. However, development on the main development branch can continue. Other than these differences, the release engineering processes are alike. .0 releases go into their own branch and are aimed mainly at early adopters. The branch then goes through a period of stabilisation, and it is not until the Release Engineering Team> decides the demands to stability have been satisfied that the branch becomes -STABLE and -CURRENT targets the next major version. While this for the majority has been with .1 versions, this is not a demand. Most releases are made when a given date that has been deemed a long enough time since the previous release comes. A target is set for having major releases every 18 months and minor releases every 4 months. The user community has made it very clear that security and stability cannot be sacrificed by self-imposed deadlines and target release dates. For slips of time not to become too long with regards to security and stability issues, extra discipline is required when committing changes to -STABLE. Figure 6-9. Process summary: release engineering These are the stages in the release engineering process. Multiple release candidates may be created until the release is deemed stable enough to be released. [FreeBSD, 2002E] Chapter 7 Tools The major support tools for supporting the development process are CVS, CVSup, Perforce, GNATS, Mailman and OpenSSH. Except for CVSup, these are externally developed tools. These tools are commonly used in the open source world. 7.1. Concurrent Versions System (CVS) Concurrent Versions System or simply “CVS” is a system to handle multiple versions of text files and tracking who committed what changes and why. A project lives within a “repository” and different versions are considered different “branches”. 7.2. CVSup CVSup is a software package for distributing and updating collections of files across a network. It consists of a client program, cvsup, and a server program, cvsupd. The package is tailored specifically for distributing CVS repositories, and by taking advantage of CVS' properties, it performs updates much faster than traditional systems. 7.3. GNATS GNATS is a maintenance database consisting of a set of tools to track bugs at a central site. It supports the bug tracking process for sending and handling bugs as well as querying and updating the database and editing bug reports. The project uses one of its many client interfaces, “send-pr”, to send “Problem Reports” by email to the projects central GNATS server. The committers have also web and command-line clients available. 7.4. Mailman Mailman is a program that automates the management of mailing lists. The FreeBSD Project uses it to run 16 general lists, 60 technical lists, 4 limited lists and 5 lists with CVS commit logs. It is also used for many mailing lists set up and used by other people and projects in the FreeBSD community. General lists are lists for the general public, technical lists are mainly for the development of specific areas of interest, and closed lists are for internal communication not intended for the general public. The majority of all the communication in the project goes through these 85 lists [FreeBSD, 2003A, Appendix C]. 7.5. Perforce Perforce is a commercial software configuration management system developed by Perforce Systems that is available on over 50 operating systems. It is a collection of clients built around the Perforce server that contains the central file repository and tracks the operations done upon it. The clients are both clients for accessing the repository and administration of its configuration. 7.6. Pretty Good Privacy Pretty Good Privacy, better known as PGP, is a cryptosystem using a public key architecture to allow people to digitally sign and/or encrypt information in order to ensure secure communication between two parties. A signature is used when sending information out many recipients, enabling them to verify that the information has not been tampered with before they received it. In the FreeBSD Project this is the primary means of ensuring that information has been written by the person who claims to have written it, and not altered in transit. 7.7. Secure Shell Secure Shell is a standard for securely logging into a remote system and for executing commands on the remote system. It allows other connections, called tunnels, to be established and protected between the two involved systems. This standard exists in two primary versions, and only version two is used for the FreeBSD Project. The most common implementation of the standard is OpenSSH that is a part of the project's main distribution. Since its source is updated more often than FreeBSD releases, the latest version is also available in the ports tree. Chapter 8 Sub-projects Sub-projects are formed to reduce the amount of communication needed to coordinate the group of developers. When a problem area is sufficiently isolated, most communication would be within the group focusing on the problem, requiring less communication with the groups they communicate with than were the group not isolated. 8.1. The Ports Subproject A “port” is a set of meta-data and patches that are needed to fetch, compile and install correctly an external piece of software on a FreeBSD system. The amount of ports have grown at a tremendous rate, as shown by the following figure. Figure 8-1. Number of ports added between 1996 and 2005 Figure 8-1 is taken from the FreeBSD web site. It shows the number of ports available to FreeBSD in the period 1995 to 2005. It looks like the curve has first grown exponentionally, and then since the middle of 2001 grown linerly. As the external software described by the port often is under continued development, the amount of work required to maintain the ports is already large, and increasing. This has led to the ports part of the FreeBSD project gaining a more empowered structure, and is more and more becoming a sub-project of the FreeBSD project. Ports has its own core team with the Ports Manager as its leader, and this team can appoint committers without FreeBSD Core's approval. Unlike in the FreeBSD Project, where a lot of maintenance frequently is rewarded with a commit bit, the ports sub-project contains many active maintainers that are not committers. Unlike the main project, the ports tree is not branched. Every release of FreeBSD follows the current ports collection and has thus available updated information on where to find programs and how to build them. This, however, means that a port that makes dependencies on the system may need to have variations depending on what version of FreeBSD it runs on. With an unbranched ports repository it is not possible to guarantee that any port will run on anything other than -CURRENT and -STABLE, in particular older, minor releases. There is neither the infrastructure nor volunteer time needed to guarantee this. For efficiency of communication, teams depending on Ports, such as the release engineering team, have their own ports liaisons. 8.2. The FreeBSD Documentation Project The FreeBSD Documentation project was started January 1995. From the initial group of a project leader, four team leaders and 16 members, they are now a total of 44 committers. The documentation mailing list has just under 300 members, indicating that there is quite a large community around it. The goal of the Documentation project is to provide good and useful documentation of the FreeBSD project, thus making it easier for new users to get familiar with the system and detailing advanced features for the users. The main tasks in the Documentation project are to work on current projects in the “FreeBSD Documentation Set”, and translate the documentation to other languages. Like the FreeBSD Project, documentation is split in the same branches. This is done so that there is always an updated version of the documentation for each version. Only documentation errors are corrected in the security branches. Like the ports sub-project, the Documentation project can appoint documentation committers without FreeBSD Core's approval. [FreeBSD, 2003B]. The Documentation project has a primer. This is used both to introduce new project members to the standard tools and syntaxes and acts as a reference when working on the project. References [Brooks, 1995] Frederick P. Brooks, 1975, 1995, 0201835959, Addison-Wesley Pub Co, The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition). [Saers, 2003] Niklas Saers, 2003, A project model for the FreeBSD Project: Candidatus Scientiarum thesis. [Jørgensen, 2001] Niels Jørgensen, 2001, Putting it All in the Trunk: Incremental Software Development in the FreeBSD Open Source Project. [PMI, 2000] Project Management Institute, 1996, 2000, 1-880410-23-0, Project Management Institute, Pennsylvania, PMBOK Guide: A Guide to the Project Management Body of Knowledge, 2000 Edition. [FreeBSD, 2000A] 2002, Core Bylaws. [FreeBSD, 2002A] 2002, FreeBSD Developer's Handbook. [FreeBSD, 2002B] 2002, Core team election 2002. [Losh, 2002] Warner Losh, 2002, Working with Hats. [FreeBSD, 2002C] Dag-Erling Smørgrav and Hiten Pandya, 2002, The FreeBSD Documentation Project, Problem Report Handling Guidelines. [FreeBSD, 2002D] Dag-Erling Smørgrav, 2002, The FreeBSD Documentation Project, Writing FreeBSD Problem Reports. [FreeBSD, 2001] 2001, The FreeBSD Documentation Project, Committers Guide. [FreeBSD, 2002E] Murray Stokely, 2002, The FreeBSD Documentation Project, FreeBSD Release Engineering. [FreeBSD, 2003A] The FreeBSD Documentation Project, FreeBSD Handbook. [FreeBSD, 2002F] 2002, The FreeBSD Documentation Project, Contributors to FreeBSD. [FreeBSD, 2002G] 2002, The FreeBSD Project, Core team elections 2002. [FreeBSD, 2002H] 2002, The FreeBSD Project, Commit Bit Expiration Policy: 2002/04/06 15:35:30. [FreeBSD, 2002I] 2002, The FreeBSD Project, New Account Creation Procedure: 2002/08/19 17:11:27. [FreeBSD, 2003B] 2002, The FreeBSD Documentation Project, FreeBSD DocEng Team Charter: 2003/03/16 12:17. [Lehey, 2002] Greg Lehey, 2002, Greg Lehey, Two years in the trenches: The evolution of a software project. Notes [1] This goes hand-in-hand with Brooks' law that “adding another person to a late project will make it later” since it will increase the communication needs Brooks, 1995. A project model is a tool to reduce the communication needs. [2] Statistics are generated by counting the number of entries in the file fetched by portsdb by April 1st, 2005. portsdb is a part of the port sysutils/portupgrade. [3] The period from January 1st, 2004 to December 31st, 2004 was examined to find this number. [4] For instance, the development of the Bluetooth stack started as a sub-project until it was deemed stable enough to be merged into the -CURRENT branch. Now it is a part of the core FreeBSD system. [5] According to Kirk McKusick, after 20 years of developing UNIX operating systems, the interfaces are for the most part figured out. There is therefore no need for much design. However, new applications of the system and new hardware leads to some implementations being more beneficial than those that used to be preferred. One example is the introduction of web browsing that made the normal TCP/IP connection a short burst of data rather than a steady stream over a longer period of time. [6] The first release this actually happened for was 4.5-RELEASE, but security branches were at the same time created for 4.3-RELEASE and 4.4-RELEASE. [7] There is a terminology overlap with respect to the word "stable", which leads to some confusion. The -STABLE branch is still a development branch, whose goal is to be useful for most people. If it is never acceptable for a system to get changes that are not announced at the time it is deployed, that system should run a security branch. [8] The first Core election was held September 2000 [9] More and more tests are however performed when building the system &
怎么break java8 stream的foreach
12-21
文章目录简介使用Spliterator自定义forEach方法总结 怎么break java8 stream的foreach 简介 我们通常需要在java stream中遍历处理里面的数据，其中foreach是最最常用的方法。 但是有时候我们并不想处理完所有的数据，或者有时候Stream可能非常的长，或者根本就是无限的。 一种方法是先filter出我们需要处理的数据，然后再foreach遍历。 那么我们如何直接break这个stream呢？今天本文重点讲解一下这个问题。 使用Spliterator 上篇文章我们在讲Spliterator的时候提到了，在tryAdvance方法中，如果返回fal
EhLib 9.1.024
10-10
EhLib 9.1.024 源码版本，自行编译 EhLib 9.1 Build 9.1.024 Professional Edition. ---------------------------------------------- The Library contains components and classes for Borland Delphi versions 7, 9, Developer Studio 2006, Delphi 2007, Embarcadero RAD Studio 2009-XE10.2, Lazarus. TABLE OF CONTENTS ----------------- Overview Installation Library Installation Help Demonstration Programs Registering and Prices Other information About author Where to start. ------------------- Start overview of the library with the main Demo project .\Demos\Bin\MainDemo.Exe. (Compiled Demo files are available in the Evaluation version of the library) If you've used previous versions of the library, then you can read a summary of the new features and changes in the file history-eng.html. More detail about new features in this version of the library can be found in the file - About EhLib 9.1 Eng.doc To install a new version of the library in the IDE, use the installation program .\Installer\EhLibInstaller.exe If, at the installation have any problems, write a letter to ehlib support address [email protected] You can also install the files in the library IDE manually, as described in Section 2. Installation Library After installation, make sure the operability of all installed components. To do this, open the IDE, compile and launch a major demonstration project .\Demos\MainDemo\Project1_XE2.dpr Read next file for full instructions of working with the library components: .\Hlp\ENG\"EhLib - Users guide.doc" Read about EhLib for Lazarus in the file - Lazarus<*>\readme.txt Overview -------- The Library contains several components and objects. TDBGridEh component TDBGridEh provides all functionality of TDBGrid and adds several new features as follows: Allows to select records, columns and rectangle areas. Special titles that can correspond to several/all columns. Footer that is able to show sum/count/other field values. Automatic column resizing to set grid width equal client width. Ability to change row and title height. Allows automatic broken of a single line long title and data row to a multiline. Title can act as button and, optionally show a sort marker. Automatically sortmarking. Ability to truncate long text with ellipsis. Lookup list can show several fields. Incremental search in lookup fields. Frozen columns. DateTime picker support for TDateField and TDateTimeField. Allows to show bitmaps from TImageList depending on field value. Allows to hide and track horizontal or vertical scrollbars. Allows to hide columns. Allows to show 3D frame for frozen, footer and data rows. Allows to draw memo fields. Multiline inplace editor. Proportional scrolling independently of sequenced of dataset. Automatically show checkboxes for Boolean fields. Allows to show checkboxes for other type of fields. Has a procedures to save and restore layout (visible columns, columns order, columns width, sortmarkers, row height) in/from registry or ini file. Allows to show hint (ToolTips) for text that don't fit in the cell. Allows to export data to Text, Csv, HTML, RTF, XLS and internal formats. Allows to import data from Text and internal formats. Can sort data in various dataset's. Can filter data in various dataset's. When DBGridEh is connected to DataSet of TMemTable type it allows: To view all data without moving active record. To display a tree-type structure of TMemTable records. To form list of values in dropdown list of SubTitle filter automatically. To create grouping records basing on the selected coulmns. TDBVertGridEh component Component to show one record from dataset in Vertical Orientation. Have a special column to show Field Captions Can customize inplace editor and data of the cell like in DBGridEh. TDBLookupComboboxEh component Provides all functionality of TDBLookupCombobox and adds several new features as follows: Can have flat style. Allows assign values as to KeyValue property just and to display Text property. Allows to type (assign) values to Text property not contained in data list (Style = csDropDownEh). Allows to hold KeyValue and Text as not affecting to each other values. Take effect when KeyField, ListField, ListSource, DataField and DataSource properties is empty. Drop down list can: Show titles, Have sizing grip, Automaticaly set width as sum of DisplayWidth of the list fields (Width = -1), Automaticaly drops on user pressed the key. Edit button can: Show DropDown, Ellipsis or Bitmap image. Have specified width. Have additional events: OnKeyValueChanged, OnButtonClick. TDBSumList component This component is intended for totaling sums and amounts of records in a TDataSet with dynamic changes. Component keeps a list of TDBSum objects, which contains types of group operations (goSum or goCount) and name sum field (goCount name of field is unnecessary). TPrintDBGridEh component TPrintDBGridEh provides properties and routines for preview and print of TDBGridEh component with several features: Ability to expand rows vertically until all text is printed. Ability to scale grid to fit it to page width. Ability to print/preview title for grid. Ability to print/preview page header and page footer where you can specify macros for current page, current date, current time and/or static text. Automatically print/preview multiselected area of TDBGridEh if it area is not empty. Ability to print/preview rich text before and after grid. TPreviewBox component TPreviewBox lets you create a customizable runtime preview. TPrinterPreview object TPrinterPreview lets you to record printable data in buffer for following output them on screen and to printer. TPrinterPreview have all functions and properties as in TPrinter object. You can use TPrinterPreview object similarly of TPrinter except some details. In TPrinter Printer.Canvas.Handle and Printer.Handle is the same but in TPrinterPreview PrinterPreview.Canvas.Handle represent the metafile in that is recored the data and PrinterPreview.Handle represent Printer.Handle. That is mean that you have to use PrinterPreview.Canvas.Handle for draw operation (DrawText, DrawTexteEx, e.t.c.) and use PrinterPreview.Handle in functions that return information about printer facilities (GetDeviceCaps, e.t.c.). Global function PrinterPreview returns default PrinterPreview object and shows data in default preview form. TDBEditEh component represents a single or multi-line edit control that can display and edit a field in a dataset or can works as non data-aware edit control. TDBDateTimeEditEh component represents a single-line date or time edit control that can display and edit a datetime field in a dataset or can works as non data-aware edit control. TDBComboBoxEh component represents a single or multi-line edit control that combines an edit box with a scrollable list and can display and edit a field in a dataset or can works as non data-aware combo edit control. TDBNumberEditEh component represents a single-line number edit control that can display and edit a numeric field in a dataset or can works as non data-aware edit control. TPropStorageEh, TIniPropStorageManEh, TRegPropStorageManEh components Components realize technology to store component properties to/from settings storage such as ini files, registry etc. TMemTableEh component dataset, which hold data in memory. Its possible consider as an array of records. Besides, it: Supports a special interface, which allows DBGridEh component to view all data without moving active record. Allows fetch data from TDataDriverEh object (DataDriver property). Allows unload change back in DataDriver, operative or postponed (in dependencies of the CachedUpdates property). Allows to create a master/detail relations on the client (filtering record) or on the external source (updating parameters [Params] and requiring data from DataDriver). Allows once-only (without the dynamic support) sort data, including Calculated and Lookup field. Allows create and fill data in design-time and save data in dfm file of the Form. Allows keep record in the manner of trees. Each record can have record elements-branches and itself be an element to other parental record. Component TDBGridEh supports to show the tree-type structure of these records. Allows to connect to the internal array of other TMemTableEh (via ExternalMemData property) and work with its data: sort, filter, edit. Has interface for requesting list of all unique values in one column of records array, ignoring local filter of the DataSet. TDBGridEh uses this property for automatic filling a list in DropDownBox of the subtitle filter cell. TDataDriverEh component carry out two tasks: Delivers data to TMemTableEh. Processes changed records of TMemTableEh (writes them in other dataset, or call events for processing the changes in program). TSQLDataDriverEh DataDriver that have four objects of the TSQLCommandEh type: SelectCommand, DeleteCommand, InsertCommand, UpdateCommand, GetrecCommand. TSQLDataDriverEh can not transfer queries to the server but it call global (for application) event which it is necessary to write to execute SQL expressions on the server. TBDEDataDriverEh, TIBXDataDriverEh, TDBXDataDriverEh and TADODataDriverEh Components. These are SQLDataDrivers that can deliver queries to the server using corresponding drivers of the access to datas. -------------------- 2. Installation Library -------------------- -------------------- 2.1 Installing library automatically -------------------- Run EhLibInstaller.exe program from "Installer" folder to install EhLib in Delphi/C++ Builder IDE. The program creates folders to keep EhLib binary and other requared files, copies requared files to created folders, compiles packages, register packages in IDE and write requared paths in registry. If you have executable installation program (for example, EhLibSetupD7Eval.exe) then you only need to run program and follow installation process. Setup automatically writes all units in necessary directory, installs packages and help files in IDE. -------------------- 2.2 Installing library manually ------------------- Follow next instructions to install files from EhLib archive: -- 2.2.1. For RAD Studio XE2 (Delphi) or higher: --------------------------------------------------------------------- Uninstall previous or evaluation version of EhLib (Old version) from Delphi IDE. Remove or copy to other directory files of old version to prevent crossing old and new version of EhLib (Including EhLib.bpl, EhLib.dcp or EhLibXX.bpl, EhLibXX.dcp, EhLibDataDriversXX, DclEhLibDataDriversXX files). These files can be located in the following folders on your computer C:\Users\All Users\Documents\RAD Studio\1X.0 C:\Users\All Users\Documents\Embarcadero\Studio\XX.0\Bpl C:\Users\All Users\Documents\Embarcadero\Studio\XX.0\Dcp Create new folder where source code and binary files will be kept (For example, C:\RAD_Studio_XE2\Components\EhLib). Hereinafter this folder will be call as "EhLib folder". Create new subfolder "Lib" in the "EhLib folder". Copy files from folders "Common", "RADStudioXE2" and "LangResources\Res" of EhLib archive into the folder "[EhLib folder]\Lib" as that all files were in one folder - "Lib". Default language resource of the library is English. If you want to change it to the other language do the next steps: - Select one of language file EhLibLangConsts.XXX.dfm - Copy this file to EhLibLangConsts.dfm file (with replacment of existing file) - In the first line of a new EhLibLangConsts.dfm file delete _XXX suffix in the name of object like this: object TEhLibLanguageConsts_ENU -> object TEhLibLanguageConsts Run RAD Studio IDE and Open EhLibProjGroup160.groupproj file from [EhLib folder]\Lib. Compile all packages of Prject Group. Install DclEhLibXX.Dpk and DclEhLibDataDriversXX.Dpk packages in IDE (Use Project/Install menu). Consistently compile packages EhLibXX.Dpk and EhLibDataDriversXX.Dpk in next modes: Win32\Debug Win64\Release Win64\Debug After compilation there should be created subfolders a Win32\Release, Win32\Debug, Win64\Release, Win64\Debug in the "[EhLib folder]\Lib" folder. Copy the *. dfm and *. res files from the "[Folder EhLib]\Lib" folder into the each of the next folders: Win32\Release, Win32\Debug, Win64\Release, Win64\Debug In the RAD Studio IDE add next paths: "[EhLib folder]\Lib\Win32\Release" path in the "Library path" for the Win32 platform. "[EhLib folder]\Lib\Win32\Debug" path in the "Debug dcu" for the Win32 platform. "[EhLib folder]\Lib\" path in the "Brasing path" for the Win32 platform. "[EhLib folder]\Lib\Win64\Release" path in the "Library path" for the Win64 platform. "[EhLib folder]\Lib\Win64\Debug" path in the "Debug dcu" for the Win64 platform. "[EhLib folder]\Lib\" path in the "Brasing path" for the Win64 platform. -- Copy DEMOS folder from the Archive EhLib to the "[EhLib Folder]". Open and compile any demo project for test. 2.2.2. Delphi 5.x - 7.x, Delphi 9.X Win32, BDS2006 Win32, Delphi2007, CodeGear RAD Studio 2009: ------------------------------------------------------------------------------- Uninstall previous or evaluation version of EhLib (Old version) from Delphi IDE. Remove or copy to other directory files of old version to prevent crossing old and new version of EhLib (Including EhLib.bpl, EhLib.dcp or EhLibXX.bpl, EhLibXX.dcp, EhLibDataDriversXX, DclEhLibDataDriversXX files). Create directory from which you will install EhLib library ('EhLib directory') (for example, C:\Delphi[X]\EhLib). Copy files from "Common", "Delphi[X]" | "BDS2006" and "LangResources\Res.Ansi" folders of the EhLib archive to 'EhLib directory'. Default language resource of the library is English. If you want to change it to the other language do the next steps: - Select one of language file EhLibLangConsts.XXX.dfm - Copy this file to EhLibLangConsts.dfm file (with replacment of existing file) - In the first line of a new EhLibLangConsts.dfm file delete _XXX suffix in the name of object like this: object TEhLibLanguageConsts_ENU -> object TEhLibLanguageConsts By default Delphi (5, 6 and 7) places compiled files to the <Delphi path>\Projects\Bpl directory and this directory already present in the search PATH. But if you overwrite default BPL directory then you need put compiled EhLibXX.BPL file into directory that is accessible through the search PATH (i.e. DOS "PATH" environment variable; for example, in the Windows\System directory). Add, (if needed) 'EhLib directory' in Tools->Environment Options->Library-> Library Path (For Delphi 9 in Tools->Options->Environment Options-> Delphi Options->Library - Win32->Library Path). Use "File\Open..." menu item of Delphi IDE to open the runtime package - EhLibXX.Dpk. In "Package..." window click "Compile" button to compile the package. After that open and compile EhLibDataDriversXX.Dpk. After compiling run-time packages install design-time packages DclEhLibXX.BPL and DclEhLibDataDriversXX.BPL into the IDE. For that use "File\Open..." menu item to open design-time package DclEhLibXX.Dpk. In "Package..." window click "Compile" button to compile the package and then click "Install" button to register EhLib components on the component palette. Open and install DclEhLibDataDriversXX.Dpk package. EhLib components have to appear on 'EhLib' page of components palette. 2.2.4. Delphi 9.X Vcl.Net, , BDS2006 Vcl.Net: ---------------------------------------- Uninstall previous or evaluation version of EhLib (Old version) from Delphi IDE. Remove or copy to other directory files of old version to prevent crossing old and new version of EhLib (Including Vcl.EhLib90.dll, Vcl.DclEhLib90.dll, Vcl.EhLibDataDrivers90.dll, Vcl.DclEhLibDataDrivers90.dll files). Create directory from which you will install EhLib library ('EhLib directory') (for example, C:\BDS\3.0\EhLibVclNet). Copy files from Common and Delphi9 directories of the EhLib archive to 'EhLib directory'. In Delphi IDE: Add, (if needed) 'EhLib directory' in Component->Installed .NET Components ...-> Assembly Search Paths. Add, (if needed) 'EhLib directory' in Tools->Options->Environment Options-> Delphi Options->Library - NET->Library Path. Use "File\Open..." menu item of Delphi IDE to open the runtime package - Vcl.EhLibXX.Dpk. In "Project Manager..." window, click right button above 'Vcl.EhLibXX.Dll' and select "Build" menu to compile package. After that, open and compile Vcl.EhLibDataDriversXX.Dpk, Vcl.DclEhLibXX.Dpk and Vcl.DclEhLibDataDriversXX.Dpk. Open menu "Component->Installed .NET Components ..."->.NET VCL Components. Press 'Add...' button. Locate 'Vcl.DclEhLibXX.dll' and press 'Open'. (By default, this file have to be located in 'EhLib directory' directory) Press 'Ok' in 'Installed .NET Components' Dialog. 4. Documentation and Help ------------------------- 4.1. This version of library doesn't have embedded help files for Delphi8 or Higher. But the online help is available on the ehlib home page - http://www.ehlib.com/online-help 4.2. Delphi 7.x: Copy the EhLib.hlp and EhLib.cnt files to the Delphi HELP subdirectory. Select Help|Customize to start the OpenHelp application. Add the EhLib.cnt file to the Contents page, add the EhLib.hlp file to the Index and Link pages. 5. Demonstration Programs and Projects -------------------------------------- Demonstration programs use tables from the DEMOS directory and ADO Data Access. Read description of Demo projects in the file Demos\Info Eng.doc 6. Registering and Prices ------------------------- The EhLib is a Commercial product. If you find it useful and want to receive the latest versions please register your evaluation copy. You can read detailed information about prices on ehlib home prices page http://www.ehlib.com/buy You can read detailed information about registration at https://secure.shareit.com/shareit/product.html?productid=102489 After registration you will receive (e-mail only) address of registered version for downloading and password for unpacking. By registering the components you get the following advantages: 1. You will get new versions of the library free within a year from the date of registration. 2. You will get technical support for the library all the time. 3. You encourage EhLib Team to make the library even better. 7. Other information ----------------- (1) Information for user who already have old version of TDBGridEH or TDBSumList or EhLib installed: Before installation this version of EhLib uninstall previous version of TDBGridEh or TDBSumList or EhLib from IDE and remove or copy this files to other directory to prevent crossing of new and old files. (2) If at compile-time under C++ Builder you get next error: [Linker Error] Unresolved external 'AlphaBlend' referenced from C:\PROGRAM FILES\BORLAND\CBUILDER6\PROJECTS\LIB\EHLIBB60.LIB|C:\VCL6\EhLib\Common\DBGridEh.pas then add msimg32.lib library in Linker options of your Project. It is placed at $(BCB)\lib\psdk\msimg32.lib 8. About Company ---------------- Contact as if you have any questions, comments or suggestions: EhLib Team
Java8中Stream使用的一个注意事项
08-28
最近在工作中发现了对于集合操作转换的神器，java8新特性 stream，但在使用中遇到了一个非常重要的注意点，所以这篇文章主要给大家介绍了关于Java8中Stream使用过程中的一个注意事项，需要的朋友可以参考借鉴，下面...
Stream_Java8.pdf
01-05
java 8 中Stream使用方式案例
Java8- Stream API的用法.pdf
07-05
Java8- Stream API的用法.pdf
stream().findFirst().get()
08-22
从引用中可以看出，代码 `stream().findFirst().get()` 是用于从流中获取第一个元素的操作。如果找到了元素，则返回该元素；否则返回 `null`。 在引用中，也有类似的使用方式，即 `business.findFirst().get()` 用于从流中获取第一个满足条件的元素。 在引用中，`findFirst()` 方法也是用于返回流中的第一个元素。 因此，`stream().findFirst().get()` 是一种常见的操作，用于获取流中的第一个元素。<span class="em">1</span><span class="em">2</span><span class="em">3</span> #### 引用[.reference_title] - *1* *2* [java8 stream findfirst().get()空指针 返回 No value present](https://blog.csdn.net/ecba1988/article/details/131292122)[target="_blank" data-report-click={"spm":"1018.2226.3001.9630","extra":{"utm_source":"vip_chatgpt_common_search_pc_result","utm_medium":"distribute.pc_search_result.none-task-cask-2~all~insert_cask~default-1-null.142^v93^chatsearchT3_2"}}] [.reference_item style="max-width: 50%"] - *3* [Java 8 Stream的用法详解](https://blog.csdn.net/lqq404270201/article/details/108713986)[target="_blank" data-report-click={"spm":"1018.2226.3001.9630","extra":{"utm_source":"vip_chatgpt_common_search_pc_result","utm_medium":"distribute.pc_search_result.none-task-cask-2~all~insert_cask~default-1-null.142^v93^chatsearchT3_2"}}] [.reference_item style="max-width: 50%"] [ .reference_list ]

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 2
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值