OpenSolaris
Collectives
Discussions
Documentation
Download
Source Browser
Free CD
Log-in
|
en
Community Group int_localization
:
Tmp Directory
>
OpenSolaris ON(OS/Net) translation FAQ
Top Menu
Show
:
Comments
Attachments
History
Information
Print
:
Print
Print preview
Export as PDF
Export as RTF
Export as HTML
Export as XAR
Wiki code for
OpenSolaris ON(OS/Net) translation FAQ
Hide Line numbers
1: | 2: == FAQ: OpenSolaris ON(OS/Net) translation FAQ 3: * [[What is OpenSolaris ON(OS/Net) translation ?>>#whatisthis]] 4: * [[What are the different components in ON ? >>#ismylanguage]] 5: * [[OK, What are the pre-requisites for doing the translation ? >>#variants]] 6: * [[Done, show me an example of translating an ON component. >>#iloggedinbut]] 7: * [[How will I translate java property files ?>>#javaproperty]] 8: * [[How will I change the date and time formats system commands like cal, diff, ls etc. of my locale ?>>#dateandtime]] 9: * [[How will I contribute back the messages I translated ? >>#howtogiveback]] 10: **What is OpenSolaris ON(OS/Net) translation ? ** 11: OpenSolaris ON(OS/Net) translation is about making the core operating system and networking components in OpenSolaris usable by non-English speaking population by changing the interface language from English to user’s target language. 12: **What are the different components in ON ? ** 13: OpenSolaris do have many software layers, this FAQ concentrates on ON (OS/Net) libraries and utilities. The following section outlines some of the commands and library functions which can be localized by translating the messages. 14: |=Operating System Commands|=Operating System Libraries|=Sysadmin Commands|=BSD Compatibility Commands|=Software Generation Subsystem Commands 15: |AppcertUtil|ac|login|biff|ld 16: |iscsitgtd|apptrace|pwconv|install 17: |md_monitordp|assert|mkstr 18: |abi_index|cstone_piclfrutree|rusage 19: |acctadm|dak_piclfrutree|shutdown 20: |allocate_all|devfsadmd_mod|ucblinks 21: |appcert|errlst 22: |apptrace|errmsgs 23: |asa|getopt 24: |audioplay|getopt_long 25: |audiorecord|ib 26: |audit|libbsm 27: |audit_binfile|libcfgadm 28: |audit_syslog|libcontract 29: |auditd|libcurses 30: |auths|libdb2 31: |autopush|libdhcputil 32: |awk|libdladm 33: |awk_xpg4|libfruaccess 34: |banner|libgss 35: |bart|libinetcfg 36: |basename|libipmp 37: |bnu|libkadm5clnt 38: |bootconfchk|libkadm5srv 39: |bsmconv|libkdb 40: |bsmrecord|libldap 41: |bsmunconv|libmeta 42: |busstat|libpiclfrudata 43: |cal|libpool 44: |cat|libprtdiag_psr_cherrystone 45: |cdrw|libprtdiag_psr_daktari 46: |cfgadm|libprtdiag_psr_desktop 47: |checkeq|libprtdiag_psr_desktop_picl 48: |checknr|libprtdiag_psr_javelin 49: |chgrp|libprtdiag_psr_littleneck 50: |chmod_cmd|libprtdiag_psr_lw8_picl 51: |chown|libprtdiag_psr_montecarlo 52: |cksum|libprtdiag_psr_monto 53: |cmd-inet|libprtdiag_psr_ontari 54: |cmp|libprtdiag_psr_opl 55: |col|libprtdiag_psr_schumacher_picl 56: |comm|libprtdiag_psr_serengeti 57: |compress|libprtdiag_psr_snowbird 58: |consadm|libprtdiag_psr_starcat 59: |coreadm|libprtdiag_psr_starfire 60: |cpio|libprtdiag_psr_sunfire 61: |cpustat_cmd|libprtdiag_psr_tazmo 62: |cputrack_cmd|libprtdiag_sun4u 63: |cron_cmd|libprtdiag_sun4v 64: |cryptoadm_all|libsasl 65: |csh|libscf 66: |csplit|libshare 67: |ctrun|libsldap 68: |ctstat|libslp 69: |ctwatch|libsmedia 70: |cut|libss 71: |datadm|libtsol 72: |date|libuutil 73: |dc|libwanboot 74: |dcs|libwanbootutil 75: |dd|libwladm 76: |decrypt|libzfs 77: |deroff|libzonecfg 78: |diff|lw8_libfruaccess 79: |diffmk|lw8_piclfrutree 80: |digest|madv 81: |dladm|mpss 82: |du_cmd|mpxu_piclfrudr 83: |dumpcs|nlspath_checks 84: |ed_cmd|pci 85: |eject|perror 86: |env|picl 87: |eqn|picld_pluginutil 88: |etc|picldevtree 89: |expand|piclenvd_chicago 90: |expr|piclenvd_enchilada 91: |fgrep|piclenvd_excalibur 92: |file_all|piclenvd_grover 93: |filesync|piclenvd_taco 94: |find|piclenvmon_sun4u 95: |fold|piclevent 96: |fruadm|piclfcal_leds_lw2plus 97: |fs|piclfrutree_lneck 98: |fsstat|picllom_blade 99: |fstyp|piclmemcfg 100: |generic|piclmemcfg_comm 101: |geniconvtbl|priv_str_xlate 102: |genmsg|psiginfo 103: |getconf|psignal 104: |gettent|psvcplugin_cstone 105: |gettext|psvcplugin_dak 106: |gettxt|psvcplugin_lneck 107: |grep|psvcpolicy_cstone 108: |grep_xpg4|psvcpolicy_dak 109: |grpck|psvcpolicy_lneck 110: |halt|regerror_msg 111: |head|sata 112: |hostname|sbd 113: |htable|scsi 114: |id|siglist 115: |ifconfig|sm_fd 116: |in.dhcpd|sm_pcata 117: |in.ftpd_all|sm_pcmem 118: |in.routed|sm_scsi 119: |in.talkd|snowbird_piclenvmond 120: |inetadm|snowbird_piclfrutree 121: |inetconv|snowbird_piclwatchdog 122: |inetd|strerror 123: |iostat|strsignal 124: |ipqosconf|sysctrl 125: |isaexec|sysevent_conf_mod 126: |join|sysevent_reg_mod 127: |kadmind|ttyname 128: |kbd|usb 129: |kclient 130: |kdb5_util 131: |kdestroy 132: |kinit 133: |klist 134: |kmfcfg_msg 135: |kpasswd 136: |kprop 137: |kproplog 138: |krb5-config 139: |krb5kdc 140: |ksslcfg_all 141: |kstat 142: |ktkt_warnd 143: |ktutil 144: |last 145: |ldap_cachemgr 146: |ldapcmd 147: |lgrpinfo 148: |libshare_nfs 149: |locale 150: |lofiadm 151: |logadm 152: |logger 153: |logname 154: |lp 155: |ls 156: |lsvcrun 157: |mailx 158: |man 159: |mesg 160: |mfstscan_all 161: |mipagentconfig_prog 162: |mipagentstat 163: |mixerctl 164: |mkdir_cmd 165: |mkpwdict 166: |mktemp 167: |more 168: |mpstat 169: |msgfmt_all 170: |mv 171: |ncab2clf 172: |ncaconfd 173: |newgrp 174: |newtask 175: |nice 176: |nispasswd 177: |nohup 178: |oawk 179: |pack 180: |passmgmt 181: |passwd 182: |paste 183: |pathchk 184: |pdevfsadm 185: |pdsvclockd 186: |pfexec 187: |pg 188: |picld 189: |pktool_msg 190: |pooladm 191: |poolbind 192: |poolcfg 193: |poold 194: |poolstat 195: |power_all 196: |ppgrep 197: |pprstat 198: |pr 199: |praudit 200: |prcapadm 201: |prcapstat 202: |prcm_daemon 203: |prex 204: |print 205: |profiles 206: |projadd 207: |projdel 208: |projects 209: |projmod 210: |prophist 211: |prtdiag 212: |prtdscp 213: |prtfru_msg 214: |prtpicl 215: |ps 216: |psrinfo 217: |pstmsboot 218: |ptools 219: |pwd 220: |raidctl 221: |ramdiskadm 222: |rcapd 223: |refer 224: |regcmp 225: |renice 226: |rm 227: |rmdir 228: |rmformat 229: |rmmount 230: |rmvolmgr_all 231: |roles 232: |routeadm 233: |scadm_SUNW,Sun-Fire-V240 234: |script 235: |sdiff 236: |sdpadm_msg 237: |sgs 238: |sh 239: |sharectl 240: |sharemgr 241: |sleep 242: |snoop 243: |sort 244: |split 245: |sppptun 246: |ssh 247: |strings 248: |su 249: |sum 250: |svc 251: |svcadm_all 252: |svccfg_all 253: |svcprop 254: |svcs_all 255: |swap 256: |symcheck 257: |symprof 258: |symreport 259: |syseventadm 260: |syseventconfd_msg 261: |syseventd_msg 262: |tabs 263: |talk 264: |tar 265: |tbl 266: |tee 267: |time 268: |tnfdump 269: |tnfxtract 270: |touch 271: |tput 272: |troff 273: |tty 274: |ttymon 275: |tzselect 276: |ufsdump 277: |ufsrestore 278: |ul 279: |uname 280: |uniq 281: |units 282: |unlink 283: |unpack 284: |valtools 285: |vgrind 286: |vi 287: |vmstat 288: |vntsd_msg 289: |volcheck 290: |volrmmount 291: |w 292: |wanboot 293: |wbem_disk 294: |wbem_nfs 295: |wc 296: |who 297: |whodo 298: |wificonfig 299: |wracct 300: |write 301: |wrsmconf_cmd 302: |wrsmstat 303: |xargs 304: |yppasswd 305: |zdump 306: |zfs 307: |zic 308: |zlogin 309: |zoneadm_all 310: |zoneadmd_all 311: |zonecfg 312: |zonename 313: |zpool 314: **OK, What are the pre-requisites for doing the translation ?** 315: If you haven’t already, pl. download the Solaris Express community version of OpenSolaris from the following link to install Solaris in your machine. 316: See [[Solaris Express community versions download>>downloads.#use]] for downloading a Solaris Express distribution of OpenSolaris. 317: See [[for installation instructions>>Community Group documentation.chapter1]] if you plan to install Solaris in a dual boot environment 318: [[ Nevada Globalization project>>Project nv-g11n.WebHome]] have set up a [[mercurial based codebase of G11N code and messages >>Project nv-g11n.repository]]. Download the message component separately as given in the document. 319: 320: {{{ 321: $ hg clone<EMAIL_ADDRESS>322: }}} 323: 324: This will create a directory called "messages". 325: **Done, show me an example of translating an ON component ?** 326: You can either translate the messages in the already existing locale in the message source path or you may want to translate messages in a new locale which is not existing in the message workspace. 327: How to translate messages for the already existing locales in the message sources 328: Given that we already brought over the message workspace as given above in the previous answer, do the following steps. For this example we change a german message 329: 330: {{{ 331: $ cd messages/messages/on/de_DE/usr/lib/locale/__LOCALE__/LC_MESSAGES 332: }}} 333: 334: Look for Operating System Commands to be translated in the SUNW_OST_OSCMD.po file, Operating System Libraries inside SUNW_OST_OSLIB.po file, Sysadmin commands under SUNW_OST_ADMIN.po BSD Compatibility Commands in SUNW_OST_UCBCMD.po and Software Generation Subsystem Commands in SUNW_OST_SGS.po file 335: We are picking a specific command cmp from SUNW_OST_OSCMD.po for this example. 336: // # The following lines are contents of SUNW_OST_OSCMD/cmp.po 337: msgid "%s %s differ: char %lld, line %lld\n" 338: msgstr "%s %s unterscheiden sich: Zeichen %lld, Zeile %lld\n" 339: msgid "cmp: cannot open %s\n" 340: msgstr "cmp: %s kann nicht geöffnet werden.\n" 341: msgid "cmp: EOF on %s\n" 342: msgstr "cmp: EOF (Dateiende) bei %s.\n" 343: // 344: if you want to change the msgstr for 345: // msgid "cmp: cannot open %s\n" 346: msgstr "cmp: %s kann nicht geöffnet werden.\n" 347: // 348: with 349: // msgid "cmp: cannot open %s\n" 350: msgstr "cmp: %s kann nicht sich öffnen.\n" 351: // 352: Change that and close the .po file, define 353: 354: {{{ 355: $ export SRC=/path/to/message/directory 356: }}} 357: 358: for example if you have your local message root directory brought over under $HOME/projects, then set SRC like follows 359: 360: {{{ 361: $ export SRC=$HOME/projects/messages 362: }}} 363: 364: Then do 365: 366: {{{ 367: $ cd $SRC 368: $ /usr/bin/make 369: $ /usr/bin/make build 370: }}} 371: 372: We can see the .mo file is created under $SRC/proto/`mach`/fileroot/usr/lib/locale/de.UTF-8/LC_MESSAGES directory. That newly created .mo file can be copied onto /usr/lib/locale/de.UTF-8/LC_MESSAGES/ directory for ’cmp’ utility running in de.UTF-8 locale to acess it. You may have noticed that the proto file is created under de.UTF-8, not de_DE.UTF-8 as one might expect from the location of the original .mo file. This is due to the $SRC/messages/on/makefiles/usr/lib/locale/rootdir.sh which changes the root directory to put in the .mo files created. 373: The next section describes how to do message translation in a totally new locale which is not there in the message sources 374: In this example we are taking hi_IN locale as an example. In the sample files and code in this example hi and hi_IN are indicated in red. Pl. substitute this with the language/locale of your choice when following these instructions. 375: Check that the locale you’re going to add support for is already included in the Makefile.master file under the messages directory, like 376: // # List of all our locales - if you need to add/remove any, do it here 377: ALL_LOCALES = ar_EG ar_SA bg_BG ca cs_CZ da_DK da_DK de_DE de_AT de_CH de_LU el_GR el_CY 378: en_AU en_CA en_GB en_IE en_MT en_NZ en_US es_ES es_AR es_BO es_CL es_CO es_CR es_EC es_GT 379: es_MX es_NI es_PA es_PE es_PY es_SV es_UY es_VE et_EE fi_FI fr_FR fr_BE fr_CA fr_CH fr_LU 380: he_IL **hi_IN** hr_HR hu_HU is_IS it_IT ja_JP ko_KR lt_LT lv_LV mk_MK nb_NO nl_NL nl_BE nn_NO 381: no_NO no_NY pl_PL pt_PT pt_BR ro_RO ru_RU sh_BA sk_SK sl_SI sq_AL sr_CS sr_SP sr_YU sv_SE 382: ta_IN th_TH tr_TR zh_CN zh_HK zh_TW iconv 383: // 384: As given in bold, hi_IN locale is already included in the master locale list, if your target locale is not there, add it. 385: Modify the $SRC/messages/Makefile.trans file to add the following changes highlighted in bold red 386: # These are default language setting 387: TARG_LANGUAGE:sh= echo ${TARG_LANGUAGE-’de_DE es_ES fr_FR **hi_IN** it_IT ja_JP ko_KR sv_SE zh_CN zh_TW’ 388: TARG_LANGUAGE_S:sh= echo ${TARG_LANGUAGES_S-’de es fr **hi** it ja ko sv zh zh_TW’} 389: de_DE_LOCALE :sh = echo ${de_DE_LOCALE-’de_DE.ISO8859-1 de_DE.UTF-8’} 390: es_ES_LOCALE :sh = echo ${es_ES_LOCALE-’es_ES.ISO8859-1 es_ES.UTF-8’} 391: fr_FR_LOCALE :sh = echo ${fr_FR_LOCALE-’fr_FR.ISO8859-1 fr_FR.UTF-8’} 392: it_IT_LOCALE :sh = echo ${it_IT_LOCALE-’it_IT.ISO8859-1 it_IT.UTF-8’} 393: **hi_IN_LOCALE :sh = echo ${hi_IN_LOCALE-’hi_IN.UTF-8’}** 394: hi_IN_LOCALE :sh = echo ${hi_IN_LOCALE-’hi_IN.UTF-8’} 395: ja_JP_LOCALE :sh = echo ${ja_JP_LOCALE-’ja_JP.eucJP ja_JP.PCK ja_JP.UTF-8’} 396: ko_KR_LOCALE :sh = echo ${ko_KR_LOCALE-’ko_KR.EUC ko.UTF-8’} 397: pl_PL_LOCALE :sh = echo ${pl_PL_LOCALE-’pl_PL.ISO8859-2 pl_PL.UTF-8’} 398: pt_BR_LOCALE :sh = echo ${pt_BR_LOCALE-’pt_BR.ISO8859-1 pt_BR.UTF-8’} 399: ru_RU_LOCALE :sh = echo ${ru_RU_LOCALE-’ru_RU.UTF-8 ru_RU.KOI8-R ru_RU.ISO8859-5 ru_RU.ANSI1251’} 400: sv_SE_LOCALE :sh = echo ${sv_SE_LOCALE-’sv_SE.ISO8859-1 sv_SE.UTF-8’} 401: zh_CN_LOCALE :sh = echo ${zh_CN_LOCALE-’zh_CN.EUC zh.GBK zh.UTF-8’} 402: zh_TW_LOCALE :sh = echo ${zh_TW_LOCALE-’zh_TW.EUC zh_TW.UTF-8 zh_TW.BIG5’} 403: TARG_LOCALE= \ 404: $(de_DE_LOCALE) \ 405: $(es_ES_LOCALE) \ 406: $(fr_FR_LOCALE) \ 407: $(it_IT_LOCALE) \ 408: **$(hi_IN_LOCALE) \** 409: $(hi_IN_LOCALE) \ 410: $(ja_JP_LOCALE) \ 411: $(ko_KR_LOCALE) \ 412: $(sv_SE_LOCALE) \ 413: $(zh_CN_LOCALE) \ 414: $(zh_TW_LOCALE) 415: 416: {{{ 417: $ cd $SRC/messages/common/locale 418: }}} 419: 420: Here we need to create Makefiles specific to hi, looking at the already existing Makefiles, we can create Makefile for hi. We are only interested in having a UTF-8 code set, so create Makefile.hi and Makefile.hi_IN.UTF-8 421: Create Makefile.hi like 422: //** # For Solaris 423: LOCALE= hi 424: CHARSET= UTF-8 425: SRC_LOCALE= hi_IN 426: # For java 427: JAVA_LOCALE= hi_IN 428: JAVA_LOCALE_S= hi 429: # 430: UINICV= 431: ** // 432: Create Makefile.hi_IN.UTF-8 like 433: //** # For Solaris 434: LOCALE= hi_IN.UTF-8 435: CHARSET= UTF-8 436: SRC_LOCALE= hi_IN 437: # For java 438: JAVA_LOCALE= hi_IN 439: # 440: USEICV= 441: ** // 442: 443: {{{ 444: $ cd ../../on 445: $ cp -r en_US hi_IN 446: }}} 447: 448: Do the following modifications for the Java reource bundles copied from the en_US directory. This will change the filenames ending in ’_en_US.properties’ to files ending in ’ {{{___}}}LOCALE__.properties’. 449: 450: {{{ 451: $ cd $SRC/messages/on 452: $ cp -r en_US hi_IN 453: $ cd hi_IN 454: $ for i in `find . -name "*_en_US.properties"` 455: > do 456: > FL=`basename $i` 457: > CHFL=${FL%_en_US.properties} 458: > mv $i `dirname $i`/${CHFL}{{{___}}}LOCALE__.properties 459: > done 460: $ for i in `find . -name "en_US" 461: > do 462: > mv $i `dirname $i`/{{{___}}}LOCALE__ 463: > done 464: $ for i in `find . -name "*_en_US.java"` 465: > do 466: > FL=`basename $i` 467: > CHFL=${FL%_en_US.java} 468: > mv $i `dirname $i`/${CHFL}{{{___}}}LOCALE__.java 469: > cat `dirname $i`/${CHFL}{{{___}}}LOCALE__.java | \ 470: /usr/bin/sed -e ’/^public class/s/pmHelpResources /pmHelpResources{{{___}}}LOCALE__ /’ \ 471: -e ’/^public class/s/pmResources /pmResources{{{___}}}LOCALE__ /’ > /tmp/$$ 472: > mv /tmp/$$ `dirname $i`/${CHFL}{{{___}}}LOCALE__.java 473: > done 474: }}} 475: 476: {{{ 477: $ cd hi_IN/usr/lib/locale/__LOCALE__/LC_MESSAGES 478: }}} 479: 480: Preprocess the .po file to be translated to make the default translation to be ASCII with the following nawk script 481: // index($1,"#") == 1 { print $0 } 482: $1 == "msgstr" { for (i=0;i<var;i++) print arr[i]; } 483: $1 == "msgstr" { sub("msgid", "msgstr", arr[0]); } 484: $1 == "msgstr" { for (i=0;i<var;i++) print arr[i]; } 485: $1 == "msgid" { var=0; arr[var++]=$0; } 486: $1 != "msgid" { arr[var++]=$0 } 487: // 488: Save this in a file like modpo.awk and call with the name of the .po file to be translated. 489: 490: {{{ 491: $ nawk -f modpo.awk SUNW_OST_OSCMD.po 492: }}} 493: 494: This will make the msgid/msgstr equal, then modify SUNW_OST_OSCMD.po, for example for the command cmp which is like follows, 495: // // 496: Can be modified like, with an example translation. 497: // # The following lines are contents of SUNW_OST_OSCMD/cmp.po 498: msgid "%s %s differ: char %lld, line %lld\n" 499: msgstr "%s %s differ: char %lld, line %lld\n" 500: msgid "usage: cmp [-l | -s] file1 file2 [skip1] [skip2]\n" 501: msgstr "usage: cmp [-l | -s] file1 file2 [skip1] [skip2]\n" 502: msgid "cmp: cannot open %s\n" 503: msgstr **"cmp: %s खोल नहीं सकता। \n" 504: ** msgid "cmp: EOF on %s\n" 505: msgstr "cmp: EOF on %s\n" 506: // 507: 508: {{{ 509: $ cd $SRC 510: $ /usr/bin/make 511: $ /usr/bin/make build 512: }}} 513: 514: Will build the message files and the resultant SUNW_OST_OSCMD.mo file can be found under the proto directory. ie, under $SRC/proto/sparc/fileroot/usr/lib/locale/hi_IN.UTF-8/LC_MESSAGES/ 515: **How will I translate java property files ?** 516: After creating a working message directory structure, see how this is done for a sample .properties file. 517: Part of the original untranslated .properties file $SRC/messages/on/en_US/usr/share/lib/locale/com/sun/slp/ClientLib_en_US.properties 518: // no_message = 519: #Messages logged through SLPConfig.writeLog(). 520: unknown_da_address = Unknown DA address: {0} 521: periodic_exception = Exception ``{0}’’’’ during periodic SA reregistering: {1} 522: sending_da_trace = Sending message ``{0}’’’’ to DA ``{1}’’’’ 523: reply_da_trace = Received reply ``{0}’’’’ from DA ``{1}’’’’ 524: tcp_send_da_trace = Sending TCP message ``{0}’’’’ to DA ``{1}’’’’ 525: tcp_reply_da_trace = Received TCP reply ``{0}’’’’ from DA ``{1}’’’’ 526: da_exception_trace = Error ``{0}’’’’ from DA ``{1}’’’’: {2} 527: udp_timeout = UDP timed out: {0} 528: datagram_io_error = IOException during datagram transaction with address ``{0}’’’’: {1} 529: // 530: Message file translated for de_DE locale as $SRC/messages/on/de_DE/usr/share/lib/locale/com/sun/slp/ClientLib{{{___}}}LOCALE__.properties 531: // #@EN@ 532: no_message = 533: #Messages logged through SLPConfig.writeLog(). 534: #@EN@ Unknown DA address: {0} 535: unknown_da_address = Unbekannte DA-Adresse: {0} 536: #@EN@ Exception ``{0}’’’’ during periodic SA reregistering: {1} 537: periodic_exception = Ausnahme ``{0}’’’’ w\u00e4hrend planm\u00e4\u00dfiger SA-Neuregistrierung: {1} 538: #@EN@ Sending message ``{0}’’’’ to DA ``{1}’’’’ 539: sending_da_trace = Nachricht ``{0}’’’’ wird an DA ``{1}’’’’ gesendet 540: #@EN@ Received reply ``{0}’’’’ from DA ``{1}’’’’ 541: reply_da_trace = Antwort ``{0}’’’’ von DA ``{1}’’’’ empfangen 542: #@EN@ Sending TCP message ``{0}’’’’ to DA ``{1}’’’’ 543: tcp_send_da_trace = TCP-Nachricht ``{0}’’’’ wird an DA ``{1}’’’’ gesendet 544: #@EN@ Received TCP reply ``{0}’’’’ from DA ``{1}’’’’ 545: tcp_reply_da_trace = TCP-Antwort ``{0}’’’’ von DA ``{1}’’’’ empfangen 546: #@EN@ Error ``{0}’’’’ from DA ``{1}’’’’: {2} 547: da_exception_trace = Fehler ``{0}’’’’ von DA ``{1}’’’’: {2} 548: #@EN@ UDP timed out for address ``{0}’’’’. 549: udp_timeout = UDP wegen Zeit\u00fcberschreitung abgebrochen: {0} 550: #@EN@ IOException during datagram transaction with address ``{0}’’’’: {1} 551: datagram_io_error = E/A-Ausnahme w\u00e4hrend Datagramm-Transaktion mit Adresse ``{0}’’’’: {1} 552: // 553: Similarly the newly created hi_IN property files also may be translated. 554: **How will I change the date and time formats of system commands like cal, diff, ls etc. of my locale ?** 555: Look under (for the hi_IN exmaple in the previous case) $SRC/messages/on/hi_IN/usr/lib/locale/__LOCALE__/LC_TIME for SUNW_OST_OSCMD.po and SUNW_OST_OSLIB.po which contain messages to be changed for doing this. 556: **How will I contribute back the messages I translated ?** 557: Follow [[ these instructions >>Project nv-g11n.get_account]] to apply for a hg account for accessing G11N workspace and affiliate with the Nevada G11N project and contribute.
Search
Collectives
Community Group
Academic and Research
Accessibility
Advocacy
Appliances
Approachability
Architecture Process and Tools
BrandZ
Chinese Users
Community Advisory Board
Databases
Desktop
Device Drivers
Distribution
Documentation
DTrace
Emerging Platforms
Fault Management
Games on OpenSolaris
HA Clusters
HPC Developer
Installation and Packaging
Internationalization and Localization
Laptop
Logical Domains
Modular Debugger (MDB)
Networking
NFS
Observability
OpenSolaris Governing Board (OGB)
OpenSolaris Printing
OS/Net (ON)
Performance
Power Management
PowerPC
Security
Service Management Facility (smf(5))
Software Porters
Solaris Volume Manager
Storage
Systems Administration Community Group
Testing
Tools Home
Unix File Systems (UFS)
Website Community
X Window System
Xen
ZFS
Zones
Project
ADSL Modem Enhancement
ARC Process Definition
ARM Platform Port
Automatic Data Migration
BIND Update
Bluetooth Stack & Drivers
Brocade FC HBA - Initiator
Brocade FC HBA - Target
Brussels - unified network link configuration
Caiman, Solaris Install Revisited
Celeste
Český portál
Chime Visualization Tool for DTrace
CIFS client for Solaris
CIFS Server
Clearview: Network Interface Coherence
Cluster Agent: Informix Dynamic Server
Cluster Agent: OpenSolaris Container
Cluster Agent: OpenSolaris xVM
Cluster Agent: Oracle E-Business Suite
Cluster agent: PostgreSQL
Cluster Agent: Samba
Cluster Agent: Tomcat
CMT
Coarse Data Flow Parallelism
Colorado: Open HA Cluster on OpenSolaris
Command Assistant
Common Array Manager
Companion - /opt/sfw: Free and Open Source software
COMSTAR: Common Multiprotocol SCSI Target
Content
Contest
CPU Observability
Credentials Process Groups
Crossbow: Network Virtualization and Resource Control
Crypto KMS Agent Toolkit
Cryptographic Framework
Data Migration Manager
Data Tethers
Deutsches Portal
Device Detection Tool
Device Driver Utility
Device Manager
Device Mapper
Direct Rendering Infrastructure & 3D drivers
DTrace Guide
Duckwater: Simplified name services management
Easy Tools
Emancipation
Emulex Fibre Channel Device Driver
Emulex Advanced Ethernet Device Driver
Enable/Enhance Solaris support for Intel Platform
Enhance the support of USB webcams
Enhanced SMF Profiles
Enhancements for AMD-based Platforms
Erlang DTrace Integration
Ethernet bridge module for Solaris
Evaluate Conary
Events Registry
Ext3 file system support
F/OSS Package Base
Facilitation
Fibre Channel over Ethernet
Fine Grained Access Policy (FGAP)
Fingerprint Authentication
Flexible Mandatory Access Control
Forensic Tools
Fully Open X Project
Fuse on Solaris
gcore
Generic Machine Check Architecture Improvements
Google SOC
HA-JBoss
HA-MySQL
Hadoop Live CD
Hitachi
HoneyComb Fixed Content Storage
HPC Stack
Image Packaging System
Improved Performance MIB
Indiana
Innovation Awards
Input Method
Intel Graphics
Internet Key Exchange, version 2
Interrupt Resource Management
IP Datapath Refactoring
IP over Infiniband
IPsec Tunnel Reform
iSCSI Extensions for Remote DMA (iSER)
iSNS Server
JeOS - Just enough Operating System
JKstat - a java binding for libkstat
Journaled File System (JFS)
K Desktop Environment
Kerberos
Kernel Sockets
Kernel SSL Enhancements
Key Management Framework
Korn Shell 93 integration/migration project
Labeled IPsec
LatencyTOP
Layer 2 Filtering
LDoms Manager
Lending
libMicro - portable microbenchmarks
Link Layer Discovery
Live Media: Technologies for distributions running from CD and other media
Locale Data
lofi compression and cryptography support
lx64 brand
Media Management System
Mega_sas
Mexico
MilaX minimal Live Distribution
MIPS Platform Port
Mozilla DTrace
MRSL.NONsharedDevice
Multi-lingual Glossary
Multi-pathing software (MPxIO)
Multiple disk sector size support
Multiple DOI
Muskoka: An open repository for OpenSolaris technical content
Navigator
Nemo: A Framework for High-Performance Networking
Network Auto-Magic
Network Data Management Protocol
Network MIBs
Network Performance Projects
Network Storage
Network Time Protocol (NTP)
Nevada Globalization
New Design of 4over6 Mechanism Based on OpenSolaris
NFS RDMA transport update and performance analysis
NFS Server in non-Global Zones
NFS version 4.1 pNFS
NFSv4 namespace extensions
Nightingale: Port Songbird to OpenSolaris
NPort ID Virtualization (NPIV)
NUMA
Object Storage Device (OSD) support for Solaris
OHACGE Script Based Plug-in
ON/Nevada (ONNV) Project
Open Development Infrastructure
Open HA Cluster Utilities
Open Sound System
OpenGrok
OpenPegasus CIM Server
OpenRTI
OpenSolaris Busybox
OpenSolaris Desktop
OpenSolaris Hispano
OpenSolaris Security Audit
OpenSolaris support for the QEMU processor emulator: host and guest
PEF: Packet Event Framework
Performance Wrappers
Pkgfactory
Polski Portal
Portail Francophone
Portal Brasil
Portals
Power Management Usability Interfaces
Presto: Automatic Printing Configuration
Printable Many Page Solaris Manuals
Promise SuperTrak RAID HBA Driver
QLogic Converged Network Adapter GLDv3 NIC Driver
Quagga Routing Protocol Suite Integration
RAID Configuration Utility
RBridge (IETF TRILL) support
RDMA Offload Framework
Reno: Login Process Enhancements for Interop
Resource Management
s10brand
SAM/QFS
SCM Migration Project
SCSI RDMA Protocol
SDcard Drivers
Sensor Abstraction Layer
Session Initiation Protocol
SFW
Shell: bourne shell, korn shell, C shell, etc.
Sierra: Intel WiFi Chipsets Support
Simple Panels
SM-HBA Based SAS HBA Management
SMF Documentation
Solaris iSCSI Target
Solaris PowerPC Port
SourceJuicer
Sparks: name service switch/nscd enhancements
Squashfs
Star integration/migration project
Starfish
Starter Kit
Storage Power Management
Sun Security Toolkit
Sun StorageTek Availability Suite
Support for OpenFabrics User Verbs / API on OpenSolaris OS
Support gcc4/GCCfss in Solaris
Suspend/Resume
SVR4 Packaging
Systemz
Tamarack: Removable Media Enhancements in Solaris
Tesla: OpenSolaris Enhanced Power Management
Test Development
Tickless Kernel Architecture
TIPC
Trademarks
Trusted networking interface policy database for Trusted Extensions
Trusted Platform Module support
Use Case
Validated Execution Project
Virtual Console
Virtual Network Machines
Visual Panels
Visualization for HPC
Volo
VRRP: Virtual Router Redundancy Protocol Implementation
VSCAN service
Web Stack
Website
Winchester: Schema mapping and ID mapping for AD Interoperability
Wireless USB Support
Wireless Wide Area Network
X Consolidation
x86 Generic FMA Topology Enumerator
Xen Gate
Xfce: A lightweight desktop environment
ZFS Boot and Install
ZFS on disk encryption support
Zone Manager
Zone Statistics
Русский портал
البوابة العربية
भारतीय पोर्टल
中国门户
日本ポータル
한국 포탈
User Group
Adelaide
Argentina
Arizona
Atlanta
Baltimore-Washington
Bangalore
Bangkok
Bangladesh
Brasilia
Beijing
Bélem
Berlin
Bhimavaram
Bloomington
Campus Ambassadors
Capital Region
Cardiff
Ceara
Charlotte
Chengdu
Chennai
Chihuahua
Chile
Cleveland
Colombia
Columbus
Connecticut
Cracow
Czech
Dallas/Ft. Worth
Danish
Delaware
Edinburgh
Egypt
Finland
Florida
Front Range
FuZhou
Great Lakes
Greece
Hangzhou
Hawaii
HeFei
Houston
Hong Kong
Hyderabad
Indonesia
Irish
Israel
Italian
Jinan
Jogja
Kabul
Kansas City
Latvia
London
Madurai
Manchester
Mato Grosso
Melbourne
Minas Gerais
Minnesota
Montreal
Moscow
Mumbai
Munich
NEA
Netherlands
New England
New York City
New Zealand
NIT Hamirpur
Noroeste
Nuremberg-Erlangen
Oklahoma City
Osnabrück
Peru
Philadelphia
Piaski
Pittsburgh
Porto Alegre
Puget Sound
Pune
Queensland
Rio de Janeiro
Research Triangle Park
Romania
Russia
San Antonio
San Diego
San Francisco
São Paulo
Scottish
Serbia
Shanghai
Shenzhen
Silicon Valley
Singapore
Slovak
South African
Southern Connecticut
St. Louis
Stavanger
Sweden
Switzerland
Sydney
Szczecin
Taiwan
Tecum
Thames Valley
Tokyo
Toronto
Trondheim
Tulsa
Turkey
Ufa
Ukraine
University of Melbourne
Vale do Paraíba
Vancouver
Venezuela
Welsh - Cymru
Wisconsin
Xi'an
Subsites
Code Reviews
Code Repositories
Package Search
Bugster
Bugzilla
Test Machines
Planet
Mailing Lists
Elections & Polls
ARC Case Logs
Source Juicer
Package Factory
User Authentication
Community Group int_localization Pages
Community Structure
المجموعة العربية
Българска група
Grup Català
Česká skupina
Ελληνική Ομάδα - Greek Group
Grupo Español
Groupe francophone
Magyar csapat - Hungarian Group
Indonesian Group
Gruppo Italiano
日本語グループ
한국어를 위한 모임
മലയാളം ഗ്രൂപ്പ്
Nederlandse groep (Dutch)
Polska Grupa
Grupo Português-Brasil
Группа русификации на OpenSolaris.Org
Slovenská skupina
Srpska grupa
தமிழ்குழு
Türkçe Grubu
简体中文工作组
繁體中文香港工作組
繁體中文工作組
Contributors
Document Translation
FAQ
Solaris Express General Globalization FAQ
Related Links
I18N Development
Locale Development
Projects
OpenSolaris Translation
Common Mistakes During Translation
How To Start
Top Contributors
Active Projects
Old Projects
Translation Status
Testing
I18N/L10N Bug Filing
I18N/L10N Testing
Projects
Tmp Directory
OpenSolaris ON(OS/Net) translation FAQ
Old i18n/l10n Home Page
OpenSolaris Gnome translation FAQ
Sources


MIS Admin
Report A Bug
Name
Register No
Specification
Please select the module
Personal Information
Internals
Attendence
Externals
Subject/About
Date
Description
Success
Thanks for contacting us, we will get back to you shortly.
Send
Ready to Leave?
×
Select "Logout" below if you are ready to end your current session.


Beer bar
Beers
(current)
Random beer
Search
Page Size
show 5
show 10
show 20
Sort by
Name asc
Name desc
Alcohol asc
Alcohol desc
Bitterness asc
Bitterness desc
Production date oldest
Production date newest
Hello, this is beer world!
This is a simple beer page, you can get all the information for beers here.
Previous
Next


Files CCore/inc/Tree.h CCore/src/Tree.cpp
Subfolders CCore/inc/tree CCore/src/tree
Binary trees is an important class of data structures. A tree consists of a set of elements, each element has a unique key. Keys are comparable and form a linear ordered set. A non-empty tree has a root element and two subtrees: Lo and Hi. Elements in the Lo subtree have a lower keys than the root element. The same way, elements in the Hi subtree have a higher keys than the root element.
Tree operation complexities are O(tree height). To be efficient, a tree must have a limited height. To achieve this there are different methods. We use two most important of them: Radix Tree and Red-Black Tree. The first is applicable to the key types with the limited value range, like integral types.
The height of the Radix Tree is limited by the log(value range volume).
Red-Black Tree has a colored arrows. Each arrow is either red or black. Some properties must be satisfied: there is no two consecutive red arrows, all tree leaves have the same black height. The height of the Red-Black Tree is limited by the 2*log(number of elements). So for these trees operations has a practically constant time limit.
Trees are useful for building maps.
CCore provides a variety of intrusive trees, the same way as a lists. They are available through the header CCore/inc/Tree.h.
CCore has four kind of tree links, each with a tree algorithms sets. To define a tree node you must include one of this links in the class:
struct Node { TreeLink<Node,unsigned> link; .... };
Then use one of Algorithm Packages to operate on trees:
using Algo = TreeLink<Node,unsigned>::RadixAlgo<&Node::link> ;
The TreeLink is a simplest tree link. It has three members: pointers to the Lo and Hi subtrees and the key. The key is unique across all tree.
template <class T,class K>
struct TreeLink
{
T *lo;
T *hi;
K key; // unique
using Node = TreeLink<T,K> ;
template <TreeLink<T,K> T::* LinkMember,class KRef=K> requires ( TreeKeyTypes<K,KRef> ) struct BinAlgo;
template <TreeLink<T,K> T::* LinkMember> requires ( UIntType<K> ) struct RadixAlgo;
};
There are two Algorithm Packages: BinAlgo with basic binary tree operations and RadixTree, which extends BinAlgo with radix tree operations. The first package has the additional template parameter: KRef. If the K is a lightweight type, then use the default KRef equals K. But for more complicated types, you may use const K & instead or even a completely different type. This type is used to pass key arguments. RadixTree requires the K to be an unsigned integral type.
struct BinAlgo
{
// node!=0
// root_ptr!=0
static Node & Link(T *node) { return node->*LinkMember; }
Link() extracts link from the object.
// Find static T * Find(T *root,KRef key); // == key static T * FindMin(T *root); static T * FindMin(T *root,KRef key); // min >= key static T * FindMax(T *root); static T * FindMax(T *root,KRef key); // max <= key
Find...() is a family of searching functions. The first argument is a tree root pointer. It may also be a subtree root. The second argument (if any) is a key value. Keys must be 3-Way comparable using the function Cmp(KRef,K). Each function returns a pointer to the found element, or null if the required element does not exist.
Find() is searching for the element with the given key.
FindMin() is searching for the element with the minimum key in the tree.
FindMin(,key) is searching for the element with the minimum key in the tree, greater or equal than the given key.
FindMax() is searching for the element with the maximum key in the tree.
FindMax(,key) is searching for the element with the maximum key in the tree, less or equal than the given key.
// Locate template <class Ref> static T ** Locate(T **root_ptr,Ref key) requires ( OneOfTypes<Ref,KRef,const K &> ) ; static T ** LocateMin(T **root_ptr); static T ** LocateMin(T **root_ptr,KRef key); // min >= key static T ** LocateMax(T **root_ptr); static T ** LocateMax(T **root_ptr,KRef key); // max <= key
Locate...() is another family of searching functions. It does the same as the correspondent Find...() function, but gets another input. It takes not the root pointer, but a non-null pointer to the root pointer variable. The return value is another double pointer: it is the original root_ptr or the pointer to the element pointer in the parent element. It is null, if the element is not found.
These functions are required by the Del...() implementation, you probably wouldn't use them.
// Del static T * DelRoot(T **root_ptr); // (*root_ptr)!=0 static T * Del(T **root_ptr,KRef key); static T * DelMin(T **root_ptr); static T * DelMin(T **root_ptr,KRef key); static T * DelMax(T **root_ptr); static T * DelMax(T **root_ptr,KRef key); static void Del(T **root_ptr,T *node); // node!=0 template <FuncType<bool,T *> TestFunc,FuncArgType<T *> DelFunc> static void DelIf(T **root_ptr,TestFunc test_func,DelFunc del_func); // root_ptr!=0
Del...() deletes the element from the tree and returns the pointer to this element (or null, if the element is not found). The first argument is a (non-null) root double pointer, this variable will be updated as the root is changed during the operation.
DelRoot() deletes the root element. The element must exist.
Del(root_ptr,node) deletes the given element form the tree. node must not be null.
The remaining Del...() functions search the element like the Find...() do and delete it.
DelIf() performs the massive delete operation. The first argument is a (non-null) root double point. The second argument is a functor. This functor checks the tree node and determines if it should be deleted. The signature of this functor is boolable (T *node). If it returns true, the node will be deleted. The third argument is a delete functor. It has the signature void (T *node) and is called to delete the node.
// struct NodePtr
struct NodePtr
{
T **node_ptr;
NodePtr(T **node_ptr_) : node_ptr(node_ptr_) {}
T ** operator + () const { return node_ptr; }
bool operator ! () const { return !node_ptr; }
T * node() const { return *node_ptr; }
};
NodePtr wraps a double pointer to an element. It is used by Root methods to return locate...() results.
// struct Cur struct Cur { T *ptr; // constructors Cur() noexcept : ptr(0) {} explicit Cur(T *ptr_) : ptr(ptr_) {} // object ptr T * operator + () const { return ptr; } bool operator ! () const { return !ptr; } T & operator * () const { return *ptr; } T * operator -> () const { return ptr; } // recursor Cur prev() const { return Cur(Link(ptr).lo); } Cur next() const { return Cur(Link(ptr).hi); } }; // struct RevCur struct RevCur { T *ptr; // constructors RevCur() noexcept : ptr(0) {} explicit RevCur(T *ptr_) : ptr(ptr_) {} // object ptr T * operator + () const { return ptr; } bool operator ! () const { return !ptr; } T & operator * () const { return *ptr; } T * operator -> () const { return ptr; } // recursor RevCur prev() const { return RevCur(Link(ptr).hi); } RevCur next() const { return RevCur(Link(ptr).lo); } };
Cur is a direct recursor to iterate over the tree elements.
RevCur is a inverse recursor to iterate over the tree elements.
// struct Root
struct Root
{
T *root;
// constructors
Root() { init(); }
// methods
void init() { root=0; }
T * operator + () const { return root; }
bool operator ! () const { return !root; }
Cur start() const { return Cur(root); }
RevCur start_rev() const { return RevCur(root); }
// find
T * find(KRef key) const { return Find(root,key); }
T * findMin() const { return FindMin(root); }
T * findMin(KRef key) const { return FindMin(root,key); }
T * findMax() const { return FindMax(root); }
T * findMax(KRef key) const { return FindMax(root,key); }
// locate
NodePtr locate(KRef key) { return Locate(&root,key); }
NodePtr locateMin() { return LocateMin(&root); }
NodePtr locateMin(KRef key) { return LocateMin(&root,key); }
NodePtr locateMax() { return LocateMax(&root); }
NodePtr locateMax(KRef key) { return LocateMax(&root,key); }
// del
T * del(KRef key) { return Del(&root,key); }
T * delMin() { return DelMin(&root); }
T * delMin(KRef key) { return DelMin(&root,key); }
T * delMax() { return DelMax(&root); }
T * delMax(KRef key) { return DelMax(&root,key); }
void del(T *node) { Del(&root,node); }
template <FuncType<bool,T *> TestFunc,FuncArgType<T *> DelFunc>
void delIf(TestFunc test_func,DelFunc del_func) { DelIf(&root,test_func,del_func); }
};
};
Root encapsulates a root pointer and tree operations. Its methods are direct calls of the correspondent functions.
struct RadixAlgo : BinAlgo { // Med() static K Med(K kmin,K kmax) // kmin<kmax { return K( kmin+(kmax-kmin-1)/2 ); } // class PrepareIns class PrepareIns : NoCopy { .... public: T *found; PrepareIns(T **root_ptr,K key); PrepareIns(Root &root,K key); PrepareIns(T **root_ptr,K key,K kmin,K kmax); PrepareIns(Root &root,K key,K kmin,K kmax); void complete(T *node); }; // struct Check struct Check { K minval; K maxval; Check(T *root,K kmin,K kmax); .... }; };
RadixAlgo extends BinAlgo with a Radix Tree functionality. The K must be an unsigned integral type. Each Radix Tree has a value range. It may be the full value range of the given type K, or some shorter range. Anyway, you have to use the same range for all operations with a particular tree.
Med() is used to split a value range. If the tree value range is [kmin,kmax], and kmed == Med(kmin,kmax), then the Lo subtree has a value range [kmin,kmed] and the Hi subtree — [kmed+1,kmax].
PrepareIns is a tool to insert an element into the tree. Its constructor prepares the operation. Its arguments are: the root double pointer (or the reference to a Root object), the key, and, optionally, the value range. If the value range is omitted, then the full range is assumed. There are two cases. First, there exist an element with the given key already. In such case, the pointer to this element is returned in the member found. Otherwise, found is null and you may do insert using the method complete(). You must provide an element to be inserted. The key will be placed into the link of this element. If you do not complete the operation, the tree remains in the original logical state, but probably with some tree structure modifications.
Check performs the tree structure check. This type is for testing purpose mostly. Constructor takes the root pointer and the value range. If the tree is broken, an exception is thrown. Otherwise, minval and maxval members will be assigned with the minimum and maximum value of keys in the tree (or both 0 if the tree is empty).
The TreeUpLink is another tree link. It has the additional member up. It points to the parent element. For the root node it is null. Keys are not unique. In fact, this kind of tree is a combination of tree and list. There are two kind of links: normal tree links, and same-key links, where lo==this. And the Lo and Hi subtrees may have nodes with the same key as the root element.
template <class T,class K>
struct TreeUpLink
{
T *lo; // == cur for same-key nodes
T *hi;
T *up;
K key; // non-unique
using Node = TreeUpLink<T,K> ;
template <TreeUpLink<T,K> T::* LinkMember,class KRef=K> requires ( TreeKeyTypes<K,KRef> ) struct BinAlgo;
template <TreeUpLink<T,K> T::* LinkMember> requires ( UIntType<K> ) struct RadixAlgo;
};
BinAlgo is essentially the same as for the TreeLink.
struct BinAlgo
{
// node!=0
// root_ptr!=0
static Node & Link(T *node) { return node->*LinkMember; }
// Find
static T * Find(T *root,KRef key); // == key
static T * FindMin(T *root);
static T * FindMin(T *root,KRef key); // min >= key
static T * FindMax(T *root);
static T * FindMax(T *root,KRef key); // max <= key
The family of Find...() functions is the same.
// Del static T * DelRoot(T *root); // root!=0 static void Del(T **root_ptr,T *node); static T * Del(T **root_ptr,KRef key); static T * DelMin(T **root_ptr); static T * DelMin(T **root_ptr,KRef key); static T * DelMax(T **root_ptr); static T * DelMax(T **root_ptr,KRef key);
Again, the family of Del...() functions is the same.
// struct Cur struct Cur { T *ptr; // constructors Cur() noexcept : ptr(0) {} explicit Cur(T *ptr_) : ptr(ptr_) {} // object ptr T * operator + () const { return ptr; } bool operator ! () const { return !ptr; } T & operator * () const { return *ptr; } T * operator -> () const { return ptr; } // recursor Cur prev() const { T *lo=Link(ptr).lo; return Cur( (lo!=ptr)?lo:0 ); } Cur next() const { return Cur(Link(ptr).hi); } }; // struct RevCur struct RevCur { T *ptr; // constructors RevCur() noexcept : ptr(0) {} explicit RevCur(T *ptr_) : ptr(ptr_) {} // object ptr T * operator + () const { return ptr; } bool operator ! () const { return !ptr; } T & operator * () const { return *ptr; } T * operator -> () const { return ptr; } // recursor RevCur prev() const { return RevCur(Link(ptr).hi); } RevCur next() const { T *lo=Link(ptr).lo; return RevCur( (lo!=ptr)?lo:0 ); } };
Cur is a direct recursor to iterate over the tree elements.
RevCur is a inverse recursor to iterate over the tree elements.
// struct Root
struct Root
{
T *root;
// constructors
Root() { init(); }
// methods
void init() { root=0; }
T * operator + () const { return root; }
bool operator ! () const { return !root; }
Cur start() const { return Cur(root); }
RevCur start_rev() const { return RevCur(root); }
// find
T * find(KRef key) const { return Find(root,key); }
T * findMin() const { return FindMin(root); }
T * findMin(KRef key) const { return FindMin(root,key); }
T * findMax() const { return FindMax(root); }
T * findMax(KRef key) const { return FindMax(root,key); }
// del
T * del(KRef key) { return Del(&root,key); }
T * delMin() { return DelMin(&root); }
T * delMin(KRef key) { return DelMin(&root,key); }
T * delMax() { return DelMax(&root); }
T * delMax(KRef key) { return DelMax(&root,key); }
void del(T *node) { Del(&root,node); }
// replace
void replace(T *place,T *obj); // place!=0 linked, obj!=0 unlinked
};
};
The Root is the same too, except, there is no locate() family of methods. There is also the additional method replace().
replace() replaces the given tree node with another unlinked node. The new node becomes a member of the tree, the old one becomes unlinked. Keys are swapped.
struct RadixAlgo : BinAlgo { // Med() static K Med(K kmin,K kmax) // kmin<kmax { return kmin+(kmax-kmin-1)/2; } // Ins static void Ins(BinAlgo::Root &root,T *node,K kmin,K kmax); static void Ins(T **root_ptr,T *node,K kmin,K kmax); static void Ins(BinAlgo::Root &root,T *node); static void Ins(T **root_ptr,T *node); // class PrepareIns class PrepareIns : NoCopy { .... public: T *found; PrepareIns(T **root_ptr,K key); PrepareIns(BinAlgo::Root &root,K key); PrepareIns(T **root_ptr,K key,K kmin,K kmax); PrepareIns(BinAlgo::Root &root,K key,K kmin,K kmax); void complete(T *node); }; // struct Root struct Root : BinAlgo::Root { void ins(T *node,K kmin,K kmax); void ins(T *node,K key,K kmin,K kmax); void ins(T *node); void ins(T *node,K key); }; // struct Check struct Check { K minval; K maxval; Check(T *root,K kmin,K kmax); .... }; };
RadixAlgo extends the BaseAlgo.
Med() is the same.
PrepareIns is the same.
Check is the same.
The main difference is insertion algorithms. You may choose between PrepareIns as for TreeLink. In this case you will have the same property tree with unique keys. Or you may choose the Ins() family of insertion functions. In this case keys are not unique and you may always insert an element into the tree. There are four of them. The first argument is the double root pointer or the BaseAlgo::Root reference. The second argument is the element to be inserted. The element must have the key inside initialized. Two last arguments, if any, specifies the tree value range.
The RadixAlgo Root extends the BaseAlgo Root with the insertion methods. Two of them are direct calls of the correspondent Ins() functions. Another two have the additional argument key. This key is placed into the element link before insertion.
RBTreeLink is a Red-Black Tree link. It has the additional member: RBFlag flag. This flag determines arrows colors:
enum RBFlag { RBFlag_BlackBlack, RBFlag_HiRed, RBFlag_LoRed, RBFlag_RedRed }; template <class T,class K> struct RBTreeLink { T *lo; T *hi; K key; // unique RBFlag flag; RBTreeLink() {} template <class ... SS> explicit RBTreeLink(SS && ... ss) : key( std::forward<SS>(ss)... ) {} using Node = RBTreeLink<T,K> ; template <RBTreeLink<T,K> T::* LinkMember,class KRef=K> requires ( RBTreeKeyTypes<K,KRef> ) struct BaseAlgo; template <RBTreeLink<T,K> T::* LinkMember,class KRef=K,void (*CopyKeyFunc)(K &,KRef)=DoCopyKey> requires ( RBTreeKeyTypes<K,KRef> ) struct Algo; template <RBTreeLink<T,K> T::* LinkMember,class KRef=K,void (*CopyKeyFunc)(K &,KRef)=DoCopyKey> requires ( RBTreeKeyTypes<K,KRef> ) struct AltAlgo; };
There are tree Algorithm Packages for this link: BaseAlgo, Algo and AltAlgo. AltAlgo is an alternative implementation of the same operations, as Algo.
struct BaseAlgo { // node!=0 static Node & Link(T *node) { return node->*LinkMember; } // Find static T * Find(T *root,KRef key); // == key static T * FindMin(T *root); static T * FindMin(T *root,KRef key); // min >= key static T * FindMax(T *root); static T * FindMax(T *root,KRef key); // max <= key // struct Cur struct Cur { T *ptr; // constructors Cur() noexcept : ptr(0) {} explicit Cur(T *ptr_) : ptr(ptr_) {} // object ptr T * operator + () const { return ptr; } bool operator ! () const { return !ptr; } T & operator * () const { return *ptr; } T * operator -> () const { return ptr; } // recursor Cur prev() const { return Cur(Link(ptr).lo); } Cur next() const { return Cur(Link(ptr).hi); } }; // struct RevCur struct RevCur { T *ptr; // constructors RevCur() noexcept : ptr(0) {} explicit RevCur(T *ptr_) : ptr(ptr_) {} // object ptr T * operator + () const { return ptr; } bool operator ! () const { return !ptr; } T & operator * () const { return *ptr; } T * operator -> () const { return ptr; } // recursor RevCur prev() const { return RevCur(Link(ptr).hi); } RevCur next() const { return RevCur(Link(ptr).lo); } }; // struct Check struct Check { K minval; K maxval; int height; bool black_black; explicit Check(T *root); .... }; };
This package contains find operations, recursors and the Check. Find operations are exactly the same as find operations of the TreeLink. Check has the same meaning too. It just has different arguments: there are no range variables. And it returns additional information: height is a black height of the tree, black_black is true, if two root arrows of the tree are black.
Cur is a direct recursor to iterate over the tree elements.
RevCur is a inverse recursor to iterate over the tree elements.
struct Algo : BaseAlgo
{
// node!=0
// root_ptr!=0
// Del
static T * DelMin(T **root_ptr);
static T * DelMax(T **root_ptr);
static T * Del(T **root_ptr,KRef key);
static void Del(T **root_ptr,T *node);
Algo extends BaseAlgo with delete operations, insert operation and Root.
There are four delete functions with the same semantic as TreeLink delete functions.
// struct Root
struct Root
{
T *root;
// constructors
Root() { init(); }
// methods
void init() { root=0; }
T * operator + () const { return root; }
bool operator ! () const { return !root; }
Cur start() const { return Cur(root); }
RevCur start_rev() const { return RevCur(root); }
// find
T * find(KRef key) const { return Find(root,key); }
T * findMin() const { return FindMin(root); }
T * findMin(KRef key) const { return FindMin(root,key); }
T * findMax() const { return FindMax(root); }
T * findMax(KRef key) const { return FindMax(root,key); }
// del
T * delMin() { return DelMin(&root); }
T * delMax() { return DelMax(&root); }
T * del(KRef key) { return Del(&root,key); }
void del(T *node) { Del(&root,node); }
};
Root encapsulates a root pointer and tree operations. The methods are direct calls of the correspondent functions.
// class PrepareIns
class PrepareIns : NoCopy
{
....
public:
T *found;
PrepareIns(T **root_ptr,KRef key);
PrepareIns(Root &root,KRef key);
void complete(T *node);
};
};
PrepareIns is a tool to insert an element into the tree. Its constructor prepares the operation. Its arguments are: the root double pointer (or the reference to a Root object) and the key. There are two cases. First, there exist an element with the given key already. In such case, the pointer to this element is returned in the member found. Otherwise, found is null and you may do insert using the method complete(). You must provide an element to be inserted. The last template parameter CopyKeyFunc determines the way of the key handling. If this function is DoCopyKey, the key will be placed into the link of this element by copying. This mode requires that K can be nothrow copied from the KRef. If this function is NoCopyKey, then no key copying is performed. Ih this case the caller is responsible for creation of the element with the proper key using the non-default constructor. If you do not complete the operation, the tree remains in the original logical state, but probably with some tree structure modifications.
RBTreeUpLink is another Red-Black Tree link. It contains the additional up pointer, this pointer points to the parent tree element. For the root element it is null.
template <class T,class K>
struct RBTreeUpLink
{
T *up;
T *lo;
T *hi;
K key; // unique
RBFlag flag;
RBTreeUpLink() {}
template <class ... SS>
explicit RBTreeUpLink(SS && ... ss) : key( std::forward<SS>(ss)... ) {}
using Node = RBTreeUpLink<T,K> ;
template <RBTreeUpLink<T,K> T::* LinkMember,class KRef=K> requires ( RBTreeKeyTypes<K,KRef> ) struct BaseAlgo;
template <RBTreeUpLink<T,K> T::* LinkMember,class KRef=K,void (*CopyKeyFunc)(K &,KRef)=DoCopyKey> requires ( RBTreeKeyTypes<K,KRef> ) struct Algo;
};
There are two Algorithm Packages for this link: BaseAlgo and Algo. They content are the same as for the RBTreeLink packages. The only difference, the struct Root has the additional method replace().
// replace void replace(T *place,T *obj); // place!=0 linked, obj!=0 unlinked };
replace() replaces the given tree node with another unlinked node. The new node becomes a member of the tree, the old one becomes unlinked. Keys are swapped.


Name of your in-game character that you're planning on playing
Class will be automatically detected based on your role on discord.
*OBS* make sure you've picked a role in #welcome-read-this
Your age (>16 & <80)
Check which days you'll mostly be available to play in
MON
TUE
WED
THU
FRI
SAT
SUN
List the three words that best describes you
Long application description, stay under 1000 characters
Copy the text below and paste it into the appropriate channel. Note: This field will be empty until all required fields are filled in


Have a look in the Network panel of your devtools, I'll see the loading of my corresponding chunk ;-)


At its core, the Phoenix Sports Exchange is a marketplace for investing in sports based securities. In regular companies, we can buy a share of the company for a price. For example, we can buy one share of Apple for $100. When we buy the share, we make money when the company does well (successful new iPhone, increase in earnings) because people are willing to pay more for a share in the company. We lose money when the company does poorly (failed product, reduced earnings) because people don’t want to spend as much money for a share. This basic concept of investing is what the Phoenix Sports Exchange is based on.
Co-Founder
Co-Founder


Aristocratkids Privacy Policy And Cookie Policy (europe)
This privacy policy (“Policy”) describes the personal data collected or generated (processed) when you use Aristocrat Kids’s websites (the “Sites”), for example Aristocrat Kids.com and Aristocrat Kidsplus.Aristocrat Kids.com, and Aristocrat Kids’s mobile applications (our “Apps”). This Policy describes the types of personal data collected when you use our Sites and Apps and how your personal data is used, shared and protected. It also explains the choices you have relating to your personal data and how you can contact us.
WHO is Responsible for the Processing of Your Personal Data?
The Aristocrat Kids entity responsible for the processing of your personal data will depend on how you interact with our Sites and Apps and where you are located in the world.
The relevant Aristocrat Kids affiliate(s) and Aristocrat Kids, Inc. are referred to as “Aristocrat Kids” or “we”. Please review our List of Local Entities for the name of the Aristocrat Kids entity responsible and appropriate contact information.
WHAT Personal Data We Collect and WHEN
We ask you for certain personal data to provide you with the products or services you request. For example, when you make purchases, request to receive communications, create an account, participate in our events or contests, or interact with our Sites or use our Apps. This personal data includes your:
- Contact details including name, email, telephone number and physical address
- Login and account information, including screen name, password and unique user ID
- Personal details including gender and date of birth
- Payment or credit card information
- Images, photos and videos
- Data on physical characteristics, including weight, height, and body measurements (such as estimated stride and shoe/foot measurements or bra size)
- Fitness activity data provided by you or generated through our Sites or Apps (time, duration, distance, location, calorie count, FuelPoints, pace/stride)
- Personal preferences including your marketing and cookie preference
We use additional personal data in order to enable particular features within our Sites and Apps or services. For example, we request access to your phone’s geolocation data in order to log your run route, or request access to your social network credentials in order to post content from an App to a social network. This personal data includes your:
- Movement data from your device’s accelerometer
- Photos, contacts and calendar information
- Sensor data, including heart rate and (GPS) location data
- Social network information, including credentials and any information from your public posts about Aristocrat Kids or your communications with us
When interacting with our Sites and Apps, data is automatically collected and shared with Aristocrat Kids by the technology platforms providing the experience. For example your web browser or mobile device may share certain data with Aristocrat Kids as those devices interact with Aristocrat Kids’s Sites or Apps. More information about these practices is included in the Cookies and Pixel Tags section below. This data includes:
- Device IDs, call state, network access, storage information and battery information
- Cookies, IP addresses, referrer headers, data identifying your web browser and version, and web beacons and tags
Tools to Manage What We Collect
When using our Apps, we also inform you about our collection through standard permissions in app stores, mobile operating systems, and in the App experience. We also prompt you for your consent where necessary.
In many cases, your web browser or mobile device platform will provide additional tools to allow you to control when your device collects or shares particular categories of information. For example, your mobile device or web browser may offer tools to allow you to manage cookie usage or location sharing. We encourage you to familiarize yourself with and use the tools available on your devices.
WHY and HOW We Use (Process) Your Personal Data
We use the personal data we collect from you in the following ways:
To Provide the Features of the Sites, Apps, and Services You Request
When you use our Sites and Apps, we will use your data to provide the product or service you have selected. For example, if you make a purchase on Aristocrat Kids.com, or participate in an event or promotion, we will use the contact information you give us to communicate with you about the purchase, event or promotion.
If you use our Apps to track your fitness activity or physical characteristics, we will collect this data and store it so that you can review it in the App. Your fitness activity data may include data you enter about your activity as well as data collected by your device during the course of your activity such as location data and movement data. We may use this activity data to calculate further information about your activity, such as distance run, or calories burned, so that the calculated information can be provided to you as part of the functionality of the App.
In many cases, to use particular features within our Sites, Apps, and services you may need to provide Aristocrat Kids with additional data or additional consent to use particular data in a certain way. For example, to use the heart rate tracking features of our Apps, you may need to connect a heart rate monitoring device to the experience; to share content on social media, you may be required to provide your social media account credentials.
To Communicate Information about our Products, Services, Events and for Other Promotional Purposes
When you create a Aristocrat Kids user account, we may use the information you provide as well as information from other Aristocrat Kids sources, such as your use of Aristocrat Kids’s Sites and Apps, your visits to or purchases made in Aristocrat Kids stores, your participation in Aristocrat Kids events and contests (possibly through other Aristocrat Kids affiliates) to send you personalized communications on products and services that may be interesting for you.
To Operate, Improve and Maintain our Business, Products and Services
We may use the data you provide to us to operate our business. For example, when you make a purchase, we may use that information for accounting, auditing and other internal functions. As another example, we may use data about how you use our products and services to enhance your user experience and to help us diagnose technical and service problems and administer our Sites and Apps.
To Protect Our or Others' Rights, Property or Safety
We may also use data about how you use our Sites and Apps to prevent or detect fraud, abuse, illegal uses and violations of our Terms of Use and to comply with court orders, governmental request or applicable law.
For General Research and Analysis Purposes
We use data about how our visitors use our Sites, Apps and Services to understand customer behavior or preferences. For example, we may use information about how visitors to Aristocrat Kids.com search for and find products to better understand the best ways to organize and present product offerings in our storefront.
Use (Processing) of Fitness Activity and Physical Characteristic Data
As discussed above, Aristocrat Kids may collect data about your fitness activity or your physical characteristics in order to provide our Apps and other services. Because of this intimate nature of this data, we strive to provide you with clear information about how this data will be used. As this data may be considered sensitive in certain jurisdictions, we take appropriate measures in protecting and using this data and, where required by applicable law or under Aristocrat Kids’s internal policies, obtain your consent for use.
Other Purposes
We may also use your personal data in other ways and will provide specific notice at the time of collection and obtain your consent where necessary.
SHARING of Your Personal Data
Aristocrat Kids’s Sharing
Aristocrat Kids shares your personal data with:
- Aristocrat Kids affiliates for the purposes outlined above
- Third party service providers processing personal data on Aristocrat Kids’s behalf, for example to process credit cards and payments, shipping and deliveries, manage and service our data, distribute emails, research and analysis, manage brand and product promotions as well as administering certain services and features
- Other third parties to the extent necessary to: (i) comply with a government request, a court order or applicable law; (ii) prevent illegal uses of our Sites and Apps or violations of our Sites’ and the Apps’ Terms of Use and our policies; (iii) defend ourselves against third party claims; and (iv) assist in fraud prevention or investigation (e.g., counterfeiting)
We may also transfer personal data we have about you in the event we sell or transfer all or a portion of our business or assets (including in the event of a reorganization, spin-off, dissolution or liquidation).
Your Sharing
When you use certain social features on our Sites or Apps, you can create a public profile that may include information such as your screen name, profile picture and hometown. You can also share content with your friends or the public, including information about your Aristocrat Kids activity. We encourage you to use the tools we provide for managing Aristocrat Kids’s social sharing to control what information you make available through Aristocrat Kids’s social features.
PROTECTION and MANAGEMENT of your Personal Data
- Encryption & Security: We use a variety of security measures, including encryption and authentication tools to maintain the safety of your personal data. Your personal data is contained behind secured networks and is only accessible by a limited number of persons who have special access rights to such systems.
- International data transfers: The personal data we collect or generate (process) in the context of our Sites and Apps will be stored in the USA.
Some of the data recipients with whom Aristocrat Kids shares your personal data may be located in countries other than the country in which your personal data originally was collected. The laws in those countries may not provide the same level of data protection compared to the country in which you initially provided your data. Nevertheless, when we transfer your personal data to recipients in other countries, including the USA, we will protect that information as described in this Policy and in compliance with applicable law.
If you are located in the European Economic Area (“EEA”) or Switzerland, we take measures to comply with applicable legal requirements and ensure adequate protection for the transfer of personal data to recipients in countries outside of the EEA or Switzerland.
- Retention of your data: We retain your personal data for as long as necessary to fulfil the purposes for which we collect it, except if required otherwise by law.
- Your rights related to your personal data: You have the right to withdraw your consent with respect to our use of your personal data. You also have the right to access your data and to modification or deletion, in the event your data as stored by us are incorrect or otherwise unlawful.
To modify your (email or sms) subscriptions or to opt-out of receiving Aristocrat Kids communication, please modify your preferences in the "view or change my profile" section of our Sites. You can also contact us to exercise your rights of access, modification and deletion or to object to the processing of your personal data via the contact details in the “Question and Feedback” section below or by sending an email to privacy@Aristocrat Kids.com.
COOKIES and Pixel Tags
Aristocrat Kids receives and records information, which may include personal data, from your browser when you use our Sites. We use a variety of methods, such as cookies and pixel tags to collect this information, which may include your (i) IP-address; (ii) unique cookie identifier, cookie information and information on whether your device has software to access certain features; (iii) unique device identifier and device type; (iv) domain, browser type and language, (v) operating system and system settings; (vi) country and time zone; (vii) previously visited websites; (viii) information about your interaction with our Sites such as click behavior, purchases and indicated preferences; and (ix) access times and referring URLs.
Third parties may also collect information via Sites through cookies, third party plug-ins and widgets. These third parties collect data directly from your web browser and the processing of this data is subject to their own privacy policies. More information on the identity of these third parties and their privacy policies is provided below.
We use cookies and pixel tags to track our customer's usage of the Sites and to understand our customer's preferences (such as country and language choices). This enables us to provide services to our customers and improve their online experience. We also use cookies and pixel tags to obtain aggregate data about site traffic and site interaction, to identify trends and obtain statistics so that we can improve our Sites. There are generally three categories of cookies used on our Sites:
- Functional: These cookies are required for basic site functionality and are therefore always enabled. These include cookies that allow you to be remembered as you explore our Sites within a single session or, if you request, from session to session. They help make the shopping cart and checkout process possible as well as assist in security issues and conforming to regulations.
- Performance: These cookies allow us to improve our Sites’ functionality by tracking usage. In some cases these cookies improve the speed with which we can process your request, allow us to remember site preferences you have selected. De-selecting these cookies may result in poorly-tailored recommendations and slow site performance.
- Social media and Advertising: Social media cookies offer the possibility to connect you to your social networks and share content from our Sites through social media. Advertising cookies (of third parties) collect information to help better tailor advertising to your interests, both within and beyond our Sites. In some cases, these cookies involve the processing of your personal data. De-selecting these cookies may result in seeing advertising that is not as relevant to you or you not being able to link effectively with Facebook, Twitter, or other social networks and/or not allowing you to share content on social media.
You can always change your preference by visiting the "Cookie Settings" at the bottom of each page of our Sites.
For a comprehensive and up-to-date summary of every third-party accessing your web browser (through Aristocrat Kids Sites or otherwise), we recommend installing a web browser plugin built for this purpose. You can also choose to have your computer warn you each time a cookie is being sent, or you can choose to turn off all cookies. You do this through your browser settings on each browser and device that you use. Each browser is a little different, so look at your browser Help menu to learn the correct way to modify your cookies. If you turn cookies off, you may not have access to many features that make our Sites and Apps more efficient and some of our services will not function properly.
USING Aristocrat Kids Sites and Apps with Third-Party Products and Services
Our Sites and Apps allow you to interact with a wide variety of other digital products and services. For example, our Sites and Apps can integrate with third-party devices for activity tracking, social networks, music streaming services and other digital services.
If you choose to connect your Aristocrat Kids account with a third-party device or account, your privacy rights on third-party platforms will be governed by their respective policies. For example, if you choose to share your Aristocrat Kids activity on third-party social media platforms, the policies of those platforms govern the data that resides there.
Our Sites and Apps may provide links to other (third-party) websites and apps for your convenience or information. Linked sites and apps have their own privacy notices or policies, which we strongly encourage you to review. To the extent any linked websites or apps are not owned or controlled by us, we are not responsible for their content, any use of the websites or apps, or the privacy practices of the websites or apps.
CHANGES to our Privacy Policy
Applicable law and our practices change over time. If we decide to update our Policy, we will post the changes on our Sites and Apps. We strongly encourage you to read our Policy and regularly check for any changes. This Policy was last modified in January 2016.
QUESTIONS and Feedback
We welcome questions, comments, and concerns about our Policy and privacy practices. If you wish to provide any feedback or if you have questions or concerns, please contact Consumer Services/Privacy at Aristocrat Kids Retail B.V Colosseum 1, 1213NL The Netherlands, send us an email at privacy@Aristocrat Kids.com or click here.


Getting Started
coming soon...
Ripple Exchange Data
~100,000 XRP to 1 BTC~1,100 XRP to 1 USD
~91,000,000 USD Market Capitalization
Ripple Facts
20% owned by Ripple's founders80% being distributed by OpenCoin and Co.
??% publicaly owned /outstanding
Ripple Resources
http://www.ripplecharts.com/http://www.rippledb.com/
Ripple Merchants / Traders
https://bitcointalk.org/index.php?topic=148114Ripple Calculator
I OwnValued @ 0 BTC
Valued @ 0 USD


CHAPTER 12
OPERATING HISTORY
12.1
Route / Schedule
The vessel was operated in a ferry service between Stockholm and Tallinn.
Tallinn
The vessel berthed at Terminal 2 in Basin No. 2 (see map attached as Enclosure 12.1.138), starboard side to shore, loading/discharging via bow ramp, i.e. the vessel was alongside all day with open visor. Berthing was not always easy which is demonstrated by the frequent use of the port anchor. The vessel had to pass the narrow entrance between the two breakwaters with some speed, in particular when side winds were prevailing, but the stopping distance ahead was only about 3 ship lengths.
The scheduled arrival was 09.00 hours and the departure was 19.00 hours (Estonian time = Swedish time + 1 hour). At wind speeds in excess of 15 m/sec the ferry proceeded stern first all the way out through the breakwater and turned round outside, at lower wind speeds the turning took place already inside the breakwater.The three pictures following this show ESTONIA at her berth in Tallinn.
Stockholm
The scheduled arrival was at the beginning of the service 09.30 hours and since 24.01.94 at 09.00 hours local time. The ferry berthed at the Frihamn Terminal opposite the Silja Terminal also starboard side to the shore, but discharging/ loading took place via the 2 stern ramps. Departure was at 17.30 hours (Swedish time).
The pictures below show ESTONIA at her berth in Stockholm.
At Sea:
The route from Tallinn to Stockholm was leading between mainland and the island Nayssaar to the west and followed the Estonian coast with a course of ca. 262° to a waypoint on approximately 59°20' N, 22°00' E. The waypoint was changed according to requirements. Up to the waypoint the vessel was normally running on full speed, i.e. in calm sea = about 19 kn, and depending on the time when the waypoint was reached, the speed was then adjusted to be at the Sandhamn pilot at ca. 05.00 hours respectively at the Söderarm pilot at about 04.00 hours. The course from the waypoint to Sandhamn was ca. 266° and to the Söderarm entrance 287°.


referenced
by Kevin Reiss at 2019-10-30 23:48:27.merged
by Kevin Reiss at 2019-10-30 23:48:27.closed
by Kevin Reiss at 2019-10-30 23:48:27.head_ref_deleted
by Kevin Reiss at 2019-10-30 23:48:33.labeled
by None at 2019-10-31 12:27:56.milestoned
by None at 2019-10-31 12:27:56.assigned
by None at 2019-10-31 13:48:34.referenced
by Kevin Reiss at 2019-10-31 15:00:30.merged
by Kevin Reiss at 2019-10-31 15:00:30.closed
by Kevin Reiss at 2019-10-31 15:00:30.head_ref_deleted
by Kevin Reiss at 2019-10-31 15:00:35.referenced
by Shaun Ellis at 2019-10-31 16:14:08.merged
by Shaun Ellis at 2019-10-31 16:14:08.closed
by Shaun Ellis at 2019-10-31 16:14:08.head_ref_deleted
by Shaun Ellis at 2019-10-31 16:14:10.review_requested
by None at 2019-10-31 17:13:35.referenced
by Shaun Ellis at 2019-10-31 17:42:41.merged
by Shaun Ellis at 2019-10-31 17:42:41.closed
by Shaun Ellis at 2019-10-31 17:42:41.head_ref_deleted
by Shaun Ellis at 2019-10-31 17:42:42.closed
by Christina Chortaria at 2019-10-30 23:02:58.referenced
by Christina Chortaria at 2019-10-30 23:02:58.merged
by Christina Chortaria at 2019-10-30 23:02:58.closed
by Christina Chortaria at 2019-10-30 23:02:58.head_ref_deleted
by Eliot Jordan at 2019-10-31 15:35:56.assigned
by Eliot Jordan at 2019-10-31 17:34:38.Update the email body to include the temp location when it exists. Snap ticket details below: ``` This was reported by a patron:
If you bookmark something in the catalog and send it to yourself as an email it sends the original location not the temporary location. Here are two examples below:
Hideyoshi - The Recap copy is on 3 hour Reserve at the Firestone Circulation Desk and the other copy is in the Firestone stacks.
The DVD Princess Mononoke is temporarily on Reserve in the Video Library.
See the email below.
Best,
Angie ``` -----Original Message-----
Message: test 2
Title: Hideyoshi / Mary Elizabeth Berry.
Author: Berry, Mary Elizabeth, 1947-
Published/Created: Cambridge, Mass. : Harvard University Press, 1982.
Format: Book
Holdings:
Location: Firestone Library
Call number: DS869.T6 B47
Location: ReCAP
Call number: DS869.T6 B47
URL: https://catalog.princeton.edu/catalog/97801
--------------------------------------------------------------------------------
Title: Princess Mononoke / a Studio Ghibli film ; Tokuma Shoten Nippon Television Network ; Dentsu & Studio Ghibli present ; screenplay and original story by Hayao Miyazaki ; produced by Toshio Suzuki ; directed by Hayao Miyazaki.
Published/Created: Burbank, CA : Disney : Distributed by Buena Vista Home Entertainment, 2012.
Format: Video/Projected medium
Holdings:
Location: Firestone Library - Circulation Desk
Call number: DVD 10830
URL: https://catalog.princeton.edu/catalog/10393747
reopened
by Nikitas Tampakis at 2019-10-31 02:42:16.head_ref_force_pushed
by James R. Griffin III at 2019-10-31 06:17:02.head_ref_force_pushed
by James R. Griffin III at 2019-10-31 06:24:22.unassigned
by James R. Griffin III at 2019-10-31 13:06:42.base_ref_force_pushed
by James R. Griffin III at 2019-10-31 06:17:02.head_ref_force_pushed
by James R. Griffin III at 2019-10-31 06:22:24.base_ref_force_pushed
by James R. Griffin III at 2019-10-31 06:24:22.head_ref_force_pushed
by James R. Griffin III at 2019-10-31 06:26:09.There exists a test area in the institutional Aeon installation that we are permitted to use for testing integration. We have been provided with a set of credentials for using a separate, dedicated account for developing integration with the request service (please see the information shared in Shared-ITIMS-Passwords\aeon
on LastPass)
Normally the config/repositories.yml
contains the mapping of form field elements which are used in order to construct the Aeon HTTP request:
yaml
request_mappings:
static:
Notes: ''
scheduledDate: ''
AeonForm: 'EADRequest'
RequestType: 'Loan'
GroupingIdentifier: 'ItemVolume'
GroupingOption_ReferenceNumber: 'Concatenate'
GroupingOption_ItemNumber: 'Concatenate'
GroupingOption_ItemDate: 'FirstValue'
GroupingOption_CallNumber: 'FirstValue'
GroupingOption_ItemVolume: 'FirstValue'
GroupingOption_ItemInfo1: 'FirstValue'
GroupingOption_Location: 'FirstValue'
accessor:
DocumentType: document_type
Site: site
Location: location
ItemTitle: title
static
identifies the field values which are constant between Aeon requests, and accessor
specifies the SolrDocument
methods which should be invoked in order to retrieve these values on a per-Document basis.
However, from my findings on the PULFA 2.0 application, there are form field names, which themselves, are dynamically generated:
{name: "ItemSubTitle_32101037692462", value: "Boyd, Alice: Correspondence, 4 ALsS to Cosmo Monkhouse"},
{name: "ItemTitle_32101037692462", value: "William Bell Scott Collection"},
{name: "ItemDate_32101037692462", value: "1890-1891"},
...
Unfortunately, I cannot find a means by which to generate these without overriding Arclight::Requests::AeonExternalRequest
I have been progressing with this on https://github.com/pulibrary/plantain/compare/issues-39-jrgriffiniii-aeon-integration
assigned
by James R. Griffin III at 2019-10-31 13:07:22.review_requested
by None at 2019-10-31 20:42:41.While discussing this workflow with @mzelesky, it was discovered that the Java-implemented routine which transforms the ProQuest metadata into proper MARC records was generating improperly-formatted MARC. Further, justified concerns regarding why this transform and process should be so tightly-bound to Java (particularly given that so many within the ITIMS teams work with Ruby Gems in order to interface with the ILS) were raised.
Perhaps a more streamlined approach could be undertaken which relies more heavily upon Ruby-based solutions could instead be explored (as the problematic MARC record formatting must be addressed regardless).
mentioned
by James R. Griffin III at 2019-10-31 17:25:09.subscribed
by James R. Griffin III at 2019-10-31 17:25:09.mentioned
by Peter Green at 2019-10-31 17:25:09.assigned
by James R. Griffin III at 2019-10-31 17:25:09.subscribed
by Peter Green at 2019-10-31 17:25:09.mentioned
by None at 2019-10-31 20:09:40.subscribed
by None at 2019-10-31 20:09:40.This might not be reasonable to request, but Honeybadger has been indicating that there are certain requests inbound from EZID resolver services which specify non-existent item records. If it is possible to identify and update those ARKs which produce these 404 errors, that would resolve this issue.
renamed
by James R. Griffin III at 2019-10-31 20:35:34.


| Class and Description |
|---|
| AugmentedPageableList.AugmentationKeys
This enum provides the available augmentation keys which are used to reference augmentation
data.
|
| Orderable
Interface to be implemented by objects that should be orderable.
|
| PageableList
A list wrapper with additional attributes which state whether there are more elements if the list
represents subset of a larger data-set.
|
| Pair
Simple Pair.
|
| PairComparator
Generic Comparator for Pairs
|
| Class and Description |
|---|
| Orderable
Interface to be implemented by objects that should be orderable.
|
| Class and Description |
|---|
| Orderable
Interface to be implemented by objects that should be orderable.
|
| Class and Description |
|---|
| Orderable
Interface to be implemented by objects that should be orderable.
|
| Class and Description |
|---|
| Orderable
Interface to be implemented by objects that should be orderable.
|
| Class and Description |
|---|
| Pair
Simple Pair.
|
| Class and Description |
|---|
| Pair
Simple Pair.
|
| Class and Description |
|---|
| PageableList
A list wrapper with additional attributes which state whether there are more elements if the list
represents subset of a larger data-set.
|
| Class and Description |
|---|
| PageableList
A list wrapper with additional attributes which state whether there are more elements if the list
represents subset of a larger data-set.
|
| Class and Description |
|---|
| Orderable
Interface to be implemented by objects that should be orderable.
|
| Class and Description |
|---|
| Orderable
Interface to be implemented by objects that should be orderable.
|
| Pair
Simple Pair.
|
| Class and Description |
|---|
| Orderable
Interface to be implemented by objects that should be orderable.
|
| Class and Description |
|---|
| Orderable
Interface to be implemented by objects that should be orderable.
|
| Class and Description |
|---|
| Orderable
Interface to be implemented by objects that should be orderable.
|
| Class and Description |
|---|
| Orderable
Interface to be implemented by objects that should be orderable.
|
| Class and Description |
|---|
| Orderable
Interface to be implemented by objects that should be orderable.
|
| Class and Description |
|---|
| Orderable
Interface to be implemented by objects that should be orderable.
|
| Class and Description |
|---|
| Orderable
Interface to be implemented by objects that should be orderable.
|
| Class and Description |
|---|
| Pair
Simple Pair.
|
| Class and Description |
|---|
| Pair
Simple Pair.
|
| Class and Description |
|---|
| Orderable
Interface to be implemented by objects that should be orderable.
|
| Pair
Simple Pair.
|
| Class and Description |
|---|
| Orderable
Interface to be implemented by objects that should be orderable.
|
| Class and Description |
|---|
| Orderable
Interface to be implemented by objects that should be orderable.
|
| Class and Description |
|---|
| Orderable
Interface to be implemented by objects that should be orderable.
|
| Class and Description |
|---|
| PageableList
A list wrapper with additional attributes which state whether there are more elements if the list
represents subset of a larger data-set.
|
| Class and Description |
|---|
| PageableList
A list wrapper with additional attributes which state whether there are more elements if the list
represents subset of a larger data-set.
|
| Class and Description |
|---|
| Orderable
Interface to be implemented by objects that should be orderable.
|
| Class and Description |
|---|
| Orderable
Interface to be implemented by objects that should be orderable.
|
| Class and Description |
|---|
| Pair
Simple Pair.
|
| Class and Description |
|---|
| Orderable
Interface to be implemented by objects that should be orderable.
|
| Class and Description |
|---|
| Orderable
Interface to be implemented by objects that should be orderable.
|
| Class and Description |
|---|
| Orderable
Interface to be implemented by objects that should be orderable.
|
| Class and Description |
|---|
| PageableList
A list wrapper with additional attributes which state whether there are more elements if the list
represents subset of a larger data-set.
|
| Class and Description |
|---|
| PageableList
A list wrapper with additional attributes which state whether there are more elements if the list
represents subset of a larger data-set.
|
| Class and Description |
|---|
| PageableList
A list wrapper with additional attributes which state whether there are more elements if the list
represents subset of a larger data-set.
|
| Class and Description |
|---|
| PageableList
A list wrapper with additional attributes which state whether there are more elements if the list
represents subset of a larger data-set.
|
| Class and Description |
|---|
| PageableList
A list wrapper with additional attributes which state whether there are more elements if the list
represents subset of a larger data-set.
|
| Class and Description |
|---|
| PageableList
A list wrapper with additional attributes which state whether there are more elements if the list
represents subset of a larger data-set.
|
| Class and Description |
|---|
| PageableList
A list wrapper with additional attributes which state whether there are more elements if the list
represents subset of a larger data-set.
|
| Class and Description |
|---|
| PageableList
A list wrapper with additional attributes which state whether there are more elements if the list
represents subset of a larger data-set.
|
| Class and Description |
|---|
| PageableList
A list wrapper with additional attributes which state whether there are more elements if the list
represents subset of a larger data-set.
|
| Class and Description |
|---|
| PageableList
A list wrapper with additional attributes which state whether there are more elements if the list
represents subset of a larger data-set.
|
| Class and Description |
|---|
| Orderable
Interface to be implemented by objects that should be orderable.
|
| Class and Description |
|---|
| PageableList
A list wrapper with additional attributes which state whether there are more elements if the list
represents subset of a larger data-set.
|
| Pair
Simple Pair.
|
| Class and Description |
|---|
| Orderable
Interface to be implemented by objects that should be orderable.
|
| Class and Description |
|---|
| Orderable
Interface to be implemented by objects that should be orderable.
|
| Pair
Simple Pair.
|
| Class and Description |
|---|
| Pair
Simple Pair.
|
| Class and Description |
|---|
| PageableList
A list wrapper with additional attributes which state whether there are more elements if the list
represents subset of a larger data-set.
|
| Class and Description |
|---|
| Orderable
Interface to be implemented by objects that should be orderable.
|
| Pair
Simple Pair.
|
| Class and Description |
|---|
| PageableList
A list wrapper with additional attributes which state whether there are more elements if the list
represents subset of a larger data-set.
|
| Class and Description |
|---|
| PageableList
A list wrapper with additional attributes which state whether there are more elements if the list
represents subset of a larger data-set.
|
| Class and Description |
|---|
| PageableList
A list wrapper with additional attributes which state whether there are more elements if the list
represents subset of a larger data-set.
|
| Pair
Simple Pair.
|
| Class and Description |
|---|
| Orderable
Interface to be implemented by objects that should be orderable.
|
| Class and Description |
|---|
| Orderable
Interface to be implemented by objects that should be orderable.
|
| Class and Description |
|---|
| PageableList
A list wrapper with additional attributes which state whether there are more elements if the list
represents subset of a larger data-set.
|
| Class and Description |
|---|
| Pair
Simple Pair.
|
| Class and Description |
|---|
| PageableList
A list wrapper with additional attributes which state whether there are more elements if the list
represents subset of a larger data-set.
|
| Class and Description |
|---|
| PageableList
A list wrapper with additional attributes which state whether there are more elements if the list
represents subset of a larger data-set.
|
| Class and Description |
|---|
| Orderable
Interface to be implemented by objects that should be orderable.
|
| Class and Description |
|---|
| PageableList
A list wrapper with additional attributes which state whether there are more elements if the list
represents subset of a larger data-set.
|
| Class and Description |
|---|
| PageableList
A list wrapper with additional attributes which state whether there are more elements if the list
represents subset of a larger data-set.
|
| Class and Description |
|---|
| Orderable
Interface to be implemented by objects that should be orderable.
|
| Class and Description |
|---|
| Pair
Simple Pair.
|
Copyright © 2019 Communote team. All rights reserved.


Defense SC
D-fense SC is a powerful suspended concentrate (SC) deltamethrin that
provides excellent control of a wide variety of insect pests including
bed bugs, ants, fleas, flies, silverfish, spiders and cockroaches. It
can be utilized for crack and crevice and spot applications in homes,
hotels, schools, businesses and more. It is odorless and safe around kids
and pets when used as directed. Provides a 2-3 month residual for
long-term insect control. The active ingredient is Deltamethrin.
Deltamethrin kills insects by direct contact or if they eat it.
It disrupts their normal nervous system function. It is less toxic to mammals
due to their higher body temperature, larger body size, and decreased sensitivity
to the chemical.


\
SEvenTeen
Home
About
Order
Try this
Contact Us
Use mouse to look and
W
A
S
D
to move
HTML model element: 3D Scene demo. Please see
github
for more information.


Rules
They're pretty simple
- You Do Not Talk About Poker.
- YOU DO NOT TALK ABOUT POKER!
- Someone Yells "STOP", Goes All-In Or Folds - Their Hand Is Over.
- Only Two Players To A Heads-up.
- One Hand At A Time.
- No Shirt, No Shoes - Except For Pics, Pics Are Public.
- Hands Will Go On As Long As The Timer Does.
- If This Is Your First Time Playing Poker, YOU HAVE TO PLAY.
If you want to actually read then go here: http://en.wikipedia.org/wiki/Texas_hold_'em#Rules
Hands


WITNESS LIST State Affairs Committee March 25, 1997-2:00P SB 73 For: Bacus, Thomas (Self), Wichita Falls Against: Woodford, Suzy (Common Cause Texas), Austin Registering, but not testifying: Against: Smith, Tom (Public Citizen), Austin SB 500 For: Gibbud, Andrea (Tax Asses.&Collec.Assn), Beeville On: Hanshaw-Ross, Elizabeth (Sec. of State's Office), Austin Rushing, Linda (Sen. Zaffirini), Austin SB 512 For: DeBeauvoir, Dana (Travis Co. Clerk), Austin DeSalme, Judith (Bexar County), San Antonio SB 552 For: DeBeauvoir, Dana (Travis County Clerk), Austin Against: Martin,Edward (Self), Austin Ramirez, Jorge (TX Democratic Party), Austin On: Hanshaw-Ross, Elizabeth (Sec. of State's Office), Austin Registering, but not testifying: For: Wholtermann, John (TX Silver-Haired Leg), San Marcos SB 700 On: Howell, James (Comptroller's Office), Austin Roe, Eleanor (Comptroller's Office), Austin SB 805 For: Rayas, Juan (Self), El Paso On: Briers, Stanley (St. Bd. of Plumbing Exa), Taylor Hardwick, Jeff (TX Assn of Healthcare), Austin Kissling, Gilbert (TX Board of Plumbing Eg), Austin Maxwell, Robert (State Plumbing Board), Austin Smith, Stuart (TX Assn of Healthcare), Austin Stacy, Deborah (Self), Ft. Worth Registering, but not testifying: For: Christianson, Robert (Self), Round Rock Smith, Gary (Lone Star Gas Co.), Dallas SB 946 Registering, but not testifying: For: Cernosek, Larry (TTSA), Houston SB 977 For: Armaugh, Richard (Southwest Lift, Inc.), Sausalito Christiansen, Fred (Southwest Lift, Inc.), San Antonio On: Mills, Lester (TX DPS), Austin SB 986 On: Cowan, Andrea (Comptroller's Office), Austin McAlmon, Alex (TX Performance Review), Austin SB 1125 For: Whitesell, Steve (National Park Service), San Antonio Registering, but not testifying: For: Chandoha, Susan (Los Compadres), San Antonio Lucero, Homero (Bexar Co. Comm. Court), Austin SB 1131 For: Sekula, Shelley (TX Dermotological Soc.), Houston On: Strader, Dick (TX Cosmetology Comm.), Austin Registering, but not testifying: For: Gilchrist, Alfred (TX Medical Assn.), Austin SB 1281 For: Fuantes, Frank (Hispanic Contrac Assn), Austin Lliteras, Chris (Southwestern Bell), Austin Smith, Gary (Lone Star Gas Co.), Dallas Against: Allison, Jim (Co. Judges & Comm. Assn), Austin Armstrong, Betty (Co. Judges & Comm. Assn), Corsicana Gossom, Woodrow (Co. Judges & Comm. Assn), Wichita Falls Lee, Donald (Conference of Urban Co.), Austin Shull, Gene (Self), Tyler Weisman, John (Self), Austin Registering, but not testifying: For: Arnold, W.D. (TX Cable & Telecom.Assn), Austin Brown, Pat (GTE), Austin Hackney, Clint (One Call Concepts), Austin Hughes, Lisa (Southwestern Bell), Austin Hyde, Richard (PanEnergy Corp.), Houston Luby, Jamie (MCI), Austin Miksa, Mary (TX Assn of Bus & CofC), Austin Nugent, Patrick (TX Natl. Gas Pipel.Assc), Austin Powers, Bill (TX Farm Bureau), Austin Rice, Rell (TX Coal. for Safe Excav), Austin Rigsbee, Ken (Phillips Petroleum Co.), Austin Smith, Clint (AT & T), Austin Ward, Leslie (Sprint), Austin Weaver, Ellen (Lone Star Gas), Dallas Weaver, Ellen (Lone Star Gas Co.), Dallas Against: Duck, Tom (TX Rural Water Assn), Austin On: McDaniel, Mary (Railroad Commission), Austin


This is a demo of text rotator
Tutorial on the way :)
I like
Toast, Candy, Turtles, Ketchup, Banana, Baby pandas
See what i did here, Do you like this?, I can be a link
I have these options:
Random loop, Normal Loop, Speed configuration, Animation In, Animation Out, Seperator


The Standards and Interoperability (S&I) Framework empowers healthcare stakeholders to establish standards, specifications and other implementation guidance that facilitate effective healthcare information exchange. The S&I Framework creates a forum – enabled by integrated functions, processes, and tools – where healthcare stakeholders can focus on solving real-world interoperability challenges.
The S&I Framework is one approach adopted by ONC's Office of Standards & Interoperability to fulfill its charge of enabling harmonized interoperability specifications to support national health outcomes and healthcare priorities, including Meaningful Use and the ongoing efforts to create better care, better population health and cost reduction through delvery improvements. The S&I Framework creates a forum – enabled by integrated functions, processes, and tools – where healthcare stakeholders can focus on solving real-world interoperability challenges. |
Transparency and open communication are essential to overcome the current and future challenges of the healthcare industry. By becoming a participant you will engage other stakeholders in defining and guiding the harmonization of health information standards. Make a difference and get involved today by participating in S&I Initiatives and Pilot projects. Learn More |
The S&I Framework was established in order to enable healthcare stakeholders to drive higher interoperability and greater health information exchange to improve quality of care. The community of participants has created valuable work products and launched further initiatives that are advancing interoperability across the healthcare industry.  Learn More |
Using the Nationwide Health Information Network (NwHIN) 1.0 Portfolio, you can implement solutions that meet Meaningful Use objectives and other national healthcare priorities. The NwHIN 1.0 Portfolio is a collection of standards, services, and policies that form the foundation for meaningful electronic exchange of health information. This portfolio represents a hybrid of existing industry best-practices partnered with new artifacts developed by the S&I Framework community, which is fostered by ONC's Office of Standards and Interoperability (OSI). |
What Our Participants Are SayingWe asked members of our participant community what they think of the S&I Framework.
|


josiahwaikari
About
Blog
Games
Recent Game
Inflate The Unicorn
22nd july 2020
Games
game
Minesweeper
17th july 2020
game
Whack A Mole
17th july 2020
game
Dress The Clown
17th july 2020