This Private Label Manufacturing Agreement, dated as of [], between QOL Labs LLC,a Delaware limited liability company ("QOL"), and [ ],a [] ("Customer")
RECITALS
A. As part of its business, QOL manufactures and sells dietary supplements for its customers to resell under their own private label brand names.
B. Customer desires to purchase the dietary supplements set forth on Schedule B hereto (the "Products") on the terms provided herein.
NOW, THEREFORE, the parties agree as follows:
1. Basic Terms of Sale.
a. Orders; Acceptance. Customer hereby makes, and QOL hereby accepts, the Product orders set forth on Schedule B hereto. All future orders hereunder will be subject to acceptance by QOL. QOL may reject any order for any reason, including, without limitation, the size of the order. Upon QOL's acceptance of an order, the parties will update Schedule B hereto to reflect same.
b. QOL Items. For purposes of fulfilling each order set forth on Schedule B hereto, QOL shall, at no additional charge, provide the items and services expressly set forth under the heading "To Be Provided by QOL." QOL will not be responsible for providing any other items or services in connection therewith.
2. Pricing.
a. Prices. QOL may quote different prices from time to time for any Product. For each order that has been accepted by QOL, the Product's price will be as set forth on Schedule B hereto.
b. Taxes. In addition to any charges due under this Agreement, Customer shall pay all taxes, duties, or other amounts, however designated, which are levied or based upon such charges, or upon this Agreement, provided, however, that Customer will not be liable for taxes based on QOL's net income.
3. Payment.
a. Payment Timing. Except as otherwise agreed, Customer shall pay [50]% of the balance for ordered Products on or before the tenth day after QOL accepts Customer’s order. Customer shall pay the remaining balance on or before the 30th day after the date such Products are made available for shipment in accordance herewith.
b. Payment Methods. Customer shall pay the balance due under any invoice by Customer’s check or by bank wire transfer, as provided in the instruction set forth on Schedule 3(b) hereto or such other instructions as QOL may provide in writing from time to time, on or before the date specified in Section 3(a) above. All payments under this Agreement shall be in U.S. Dollars unless otherwise specified in writing by QOL.
c. Late Payments. For any undisputed amounts that are past due hereunder, Customer shall pay to QOL, on demand, interest, at a rate equal to the lesser of (x) 1.5% per month and (y) the maximum rate permitted by applicable law, from the date an invoice is past due to the date of actual payment.
d. Deemed Payment Date. Notwithstanding anything to the contrary in this Agreement, any payment by Customer hereunder will be deemed to have been made only upon the date such payment is actually received by QOL and such date will be deemed to be the payment date hereunder.
4.Delivery.
a. FOB Shipping Point. Prices to Customer for the Products will be F.O.B. QOL’s warehouse. Delivery will be deemed complete and risk of loss or damage to the Products will pass to Customer upon delivery to the carrier.
b. [Shipment Protection. Without limiting Section 4(a) above, QOL will not be responsible for the effects of temperature, humidity or weather conditions at any point after delivery to the carrier. It will be the Customer’s sole responsibility to protect against the possible effects of same during shipment of Products and their storage thereafter.]
c. Return of Materials. Except as otherwise agreed in writing, upon completion of an order, any unused Customer-supplied labels, packaging or ingredients will be shipped to Customer at Customer’s expense
d. Delivery Timing. QOL shall use reasonable efforts to make deliveries with reasonable promptness but will not be liable for any damages, direct, consequential, special or otherwise, to Customer or to any
other person for QOL ‘s failure to fill any orders or for any delay in delivery.
5. Inspection; Acceptance.
Customer shall (i) promptly inspect all Products upon their arrival at Customer’s warehouse and (ii) accept all Products that conform to Customer’s purchase order [and meet the Product specifications provided by QOL therefor (the “Specifications”)]. If the Products do not conform to the applicable purchase order [or the Specifications], Customer shall report the same to QOL within [ten (10)] days after their delivery. In connection therewith, Customer shall furnish such evidence or other documentation as QOL may request. If the Products do not conform to the applicable purchase order [or the Specifications] and the cause is determined to be the fault of QOL, (i) QOL shall promptly deliver additional or substitute Products to Customer at QOL’s expense or, at QOL’s option, refund Customer’s purchase price therefor and (ii) Customer shall, at QOL’s option, return or dispose of the non-conforming Product, at QOL’s expense. All Products not rejected within the time period specified in this Section 5 shall be deemed accepted by Customer.
6. Customer Responsibilities.
a. Customer Packaging. For each order Customer shall provide the items indicated on Schedule B hereto under the column titled “To Be Provided by Customer” (collectively, the “Customer Items”). All Customer Items shall be supplied at such times, in such amounts and with such allowances for loss, as QOL deems reasonably necessary. QOL may reject any Customer Items in its sole discretion. Customer acknowledges that any problems or delays with respect to any Customer Items could delay fulfillment of Customer’s order.
b. [Customer Packaging Verification. Customer is solely responsible for verifying that all packaging items (e.g., bottles, caps, seals, cartons, etc.) set forth on Schedule B hereto meet Customer’s standards and are otherwise appropriate for the ordered Products.]
c. Customer Label Obligations. Customer (i) shall ensure that any Product labels it supplies comply with all applicable laws,
rules and regulations, including those of the U.S. Food and Drug Administration and (ii) shall not submit any finished Product labels to QOL unless drafts of same have first been pre-approved by QOL in writing. QOL will not be responsible for any quality, content or other issues relating to Customer-supplied labels or their application.
d. [Customer Ingredient Obligations. Upon request, Customer shall provide QOL with the current MSDS and Certificate of Analysis for each ingredient Customer provides. Notwithstanding anything to the contrary herein, QOL will not be responsible for any defective or unsafe Product ingredients supplied by Customer.]
e. [Customer Formulations. Customer acknowledges that, except as otherwise agreed in writing, for formulations stipulated by Customer, QOL will not conduct any testing (e.g., efficacy, stability, consistency, etc.).]
f. Compliance with Law. Customer shall comply with all applicable laws, rules and regulations relating to the marketing, sale, and use of the Product.
7. Intellectual Property.
a. Customer IP Authority. Customer hereby represents that it has, and will throughout the term of this Agreement have, the requisite authority to stipulate and provide any Product formulations, specifications, ingredients, labels, packaging, and materials of any kind provided in connection herewith and the foregoing will not, either individually or in combination, infringe any third party’s rights of ownership or use.
b. QOL IP Ownership. Except as otherwise agreed by the parties in writing, all trade secrets, formulations, production methods, techniques, know-how, inventions or other intellectual property developed by QOL in connection with this Agreement (the “QOL IP”) will be the sole and exclusive property of QOL. Except as agreed by QOL in writing, Customer shall not, during the term of this Agreement or thereafter, use, register, damage, violate or claim ownership of, any QOL IP.
8. Confidentiality.
Customer acknowledges that, in connection herewith, it may obtain information relating to Products and to QOL that is of a confidential nature. Such confidential information includes, but is not limited to, the QOL IP, customer and supplier lists, financial information, organizational and personnel data, and sales and marketing plans (“Confidential Information”). During
the term of this Agreement and thereafter Customer shall not (i) use such Confidential Information, other than to the extent required in the course of its duties under this Agreement, or (ii) disclose any of such Confidential Information to any party without QOL’s written consent. Customer shall appropriately bind each of its employees receiving Confidential Information to the confidentiality and use restrictions herein. QOL shall be a third party beneficiary of such employee agreements with the right to enforce such agreements to the extent litigation is necessary to protect QOL’s rights in the Confidential Information. Confidential Information will not include any information which is or becomes generally available to the public through no fault of Customer.
9. Warranty.
a. No Implied Warranties. There are no warranties, expressed or implied, by operation of law or otherwise, for the Products, except as expressly provided herein. QOL disclaims any implied warranties, including any implied warranties as to fitness for a particular purpose.
b. Limitation on Warranty Offers. Customer shall not offer any warranty on any Product without QOL’s prior written approval.
10. Indemnification; Insurance.
a. Mutual Indemnity. Each party (the “Indemnified Party”) shall indemnify, defend and hold the other party and its affiliates, and their respective officers, directors, agents and employees, harmless from and against any losses, liabilities, claims, damages and expenses (including reasonable attorneys’ fees) (collectively, “Liabilities”) arising out of the Indemnified Party’s breach of this Agreement.
b. [Additional Customer Indemnity. In addition, Customer shall indemnify, defend and hold QOL and its affiliates and their respective officers, directors, agents and employees, harmless from and against any Liabilities arising out of any third party claim relating to any Product formulations, specifications, ingredients, labels, packaging or materials of any kind provided or stipulated by Customer under this Agreement.]
c. Limitation on Liability. Notwithstanding the foregoing, neither party nor its officers, directors, shareholders, employees or agents will be liable to the other party for indirect, incidental, consequential or punitive damages, arising out of this Agreement, even if advised of the possibility of such damages.
d. Insurance. Each party represents that it has, or shall, within thirty (30) days after the date hereof, increase its existing insurance, to the extent required, to have, limits through underlying and excess coverage of not less than $3,000,000 per occurrence in [the United States] for [bodily injury, personal injury, products and completed operations and advertising injury coverage], together with a contractual liability endorsement, which coverage shall name the other party as an additional insured. Each party shall maintain such insurance with a third party commercial insurance carrier with an A.M. Best rating of A- or better. The insurance policy must provide that it will not be cancelled or materially altered except on at least 30 days prior written notice to the other party. Each party shall continue to maintain such insurance (i) at all times during the term hereof and (ii) for at least 3 years after the termination hereof. Each party shall provide evidence of compliance with the foregoing insurance requirements, reasonably satisfactory to the other party, upon the other party’s written requests from time to time.
11. Term and Termination.
a. Term; Renewal. The term of this Agreement will start on the date hereof and end on the date immediately preceding the first anniversary hereof. Thereafter the term will automatically renew for successive one-year periods, unless either party gives written notice of non-renewal to the other party not less than 30 days prior to the close of the thencurrent term.
b. Termination. (i) Breach. If either party materially breaches this Agreement, the other party may terminate this Agreement upon thirty (30) days’ prior written notice to the breaching party, unless the breach is cured or reasonably remedied within the notice period. (ii) Bankruptcy; Insolvency. Either party may, immediately upon written notice to the other party, terminate this Agreement, if: A. a receiver is appointed by a court of competent jurisdiction for the other party or its property; B. the other party becomes insolvent or unable to pay its debts as they mature or ceases to pay its debts as they mature in the ordinary course of business or makes an assignment for the benefit of its creditors; C. any voluntary proceedings are commenced by or for the other party
under any bankruptcy, insolvency or debtor’s relief law; or
D. any proceedings are commenced against the other party under any bankruptcy, insolvency or debtor’s relief law and such proceedings are not vacated or set aside within 60 days from the date of commencement thereof.
c. Survival. Except as expressly provided in this Agreement, termination of this Agreement will not affect or impair (x) any accrued remedies or liabilities of either party or (y) any provision of this Agreement that is intended to come into force or continue in force on or after such termination.
12. Notices.
All notices and other communications provided for herein shall be dated and in writing and shall be deemed to have been duly given (i) upon delivery, if delivered personally or by a nationally recognized overnight courier service, receipt confirmed, (ii) upon confirmation of receipt, if transmitted by email or (iii) when received or rejected by the addressee, if sent by registered or certified mail, postage prepaid, in each case to the party to whom it is directed at the address indicated on the signature page hereto (or at such other address as such party hereafter specifies by notice in writing to the other parties hereto): A notice by email will be deemed to have been confirmed when the recipient, by an email sent to the email address for the sender or by a notice delivered by another method in accordance with this Section 12, acknowledges having received that email, with an automatic “read receipt” not constituting acknowledgment of an email for purposes of this Section 12.
13. Force Majeure.
Neither party shall be liable to the other for any delay or nonperformance of its obligations (excluding payment obligations) under this Agreement arising from any cause beyond its reasonable control. The party that so delays or fails to perform shall promptly notify the other party in writing of the cause and the likely duration thereof
14. Miscellaneous.
a. Subcontractors. Customer acknowledges and agrees that QOL may use subcontractors in the performance of its obligations under this Agreement. b. Independent Contractors. QOL and Customer are each independent contractors and are solely responsible for their employees and agents. There is no partnership or joint venture between QOL and Customer hereunder.
c. Amendments; Waivers. This Agreement may be amended, superseded or canceled, and any of the terms hereof may be waived, only by a written instrument specifically referring to this Agreement and specifically stating that it amends, supersedes or cancels this Agreement or waives any of its terms, executed by the parties. Failure of either party to insist upon strict compliance with any of the terms of this Agreement in one or more instances shall not be deemed to be a waiver of its rights to insist upon such compliance in the future, or upon compliance with other terms hereof. d. No Assignment. Customer will not be permitted to assign, sell, or otherwise transfer any or all rights and obligations under this Agreement to any third party without the prior written consent of QOL
e. Severability. If any provision of this Agreement shall be held invalid or unenforceable, the remainder of this Agreement shall not be affected and shall be enforceable to the full extent permitted by law.
f. Governing Law. This Agreement shall be governed by the laws of the State of New York, excluding any conflict-of-laws provisions thereof that would require the application of the law of any other jurisdiction.
g. Arbitration. Any controversy or claim arising out of or relating to this Agreement, or the breach thereof, shall be settled by arbitration administered by the American Arbitration Association in New York, New York in accordance with its Commercial Arbitration Rules, and judgment on the award rendered by the arbitrator(s) may be entered in any court having jurisdiction thereof. Except as may be required by law, neither a party nor an arbitrator may disclose the existence, content, or results of any arbitration hereunder without the prior written consent of both parties.
h. Arbitration Expenses. The arbitrators shall award to the prevailing party, if any, as determined by the arbitrators, all of its costs and fees. “Costs and fees” mean all reasonable pre-award expenses of the arbitration, including the arbitrators’ fees, administrative fees, travel expenses, outof-pocket expenses such as copying and telephone, court costs, witness fees, and attorneys’ fees.
i. Counterparts. This Agreement may be executed in two or more counterparts, each of which shall be deemed to be an original but all of which together shall constitute one and the same instrument.
j. Complete Agreement. This Agreement sets forth the entire agreement and understanding of the parties with respect to the subject matter hereof and supersedes all prior agreements, arrangements and understandings relating thereto
IN WITNESS WHEREOF, the parties have executed this Agreement as of the date first-above written. QOL LABS LLC
Name:Dan Lifton
Address: QOL Labs LLC 2975 Westchester Avenue Purchase NY 10577 Attention: Dan Lifton
prododuct |
order acceptance date |
quantity |
price |
to be provided by qol |
to be provided by customer |
estimated delivery date |
Additional terms and conditions * |
prododuct |
$ |
-Ingredients -Capsule Manufactured -QOL’S Standard Issue bottles, caps and seal for products of the type ordered - Capsules packaged into bottles |
[Lables;Outer cartons or boxsr for bottles etc.] |
from label approval date |
N/A |
||
prododuct |
$ |
-Ingredients -Capsule Manufactured -QOL’S Standard Issue bottles, caps and seal for products of the type ordered - Capsules packaged into bottles |
[Lables;Outer cartons or boxsr for bottles etc.] |
from label approval date |
N/A |
||
prododuct |
$ |
-Ingredients -Capsule Manufactured -QOL’S Standard Issue bottles, caps and seal for products of the type ordered - Capsules packaged into bottles |
[Lables;Outer cartons or boxsr for bottles etc.] |
from label approval date |
N/A |
||
prododuct |
$ |
-Ingredients -Capsule Manufactured -QOL’S Standard Issue bottles, caps and seal for products of the type ordered - Capsules packaged into bottles |
[Lables;Outer cartons or boxsr for bottles etc.] |
from label approval date |
N/A |
||
prododuct |
$ |
-Ingredients -Capsule Manufactured -QOL’S Standard Issue bottles, caps and seal for products of the type ordered - Capsules packaged into bottles |
[Lables;Outer cartons or boxsr for bottles etc.] |
from label approval date |
N/A |
||
prododuct |
$ |
-Ingredients -Capsule Manufactured -QOL’S Standard Issue bottles, caps and seal for products of the type ordered - Capsules packaged into bottles |
[Lables;Outer cartons or boxsr for bottles etc.] |
from label approval date |
N/A |
||
prododuct |
$ |
-Ingredients -Capsule Manufactured -QOL’S Standard Issue bottles, caps and seal for products of the type ordered - Capsules packaged into bottles |
[Lables;Outer cartons or boxsr for bottles etc.] |
from label approval date |
N/A |
||
prododuct |
$ |
-Ingredients -Capsule Manufactured -QOL’S Standard Issue bottles, caps and seal for products of the type ordered - Capsules packaged into bottles |
[Lables;Outer cartons or boxsr for bottles etc.] |
from label approval date |
N/A |
|
|||
|
|
|
prododuct |
order acceptance date |
quantity |
price |
to be provided by qol |
to be provided by customer |
estimated delivery date |
Additional terms and conditions * |
prododuct |
$ |
-Ingredients -Capsule Manufactured -QOL’S Standard Issue bottles, caps and seal for products of the type ordered - Capsules packaged into bottles |
[Lables;Outer cartons or boxsr for bottles etc.] |
from label approval date |
N/A |
||
prododuct |
$ |
-Ingredients -Capsule Manufactured -QOL’S Standard Issue bottles, caps and seal for products of the type ordered - Capsules packaged into bottles |
[Lables;Outer cartons or boxsr for bottles etc.] |
from label approval date |
N/A |
||
prododuct |
$ |
-Ingredients -Capsule Manufactured -QOL’S Standard Issue bottles, caps and seal for products of the type ordered - Capsules packaged into bottles |
[Lables;Outer cartons or boxsr for bottles etc.] |
from label approval date |
N/A |
||
prododuct |
$ |
-Ingredients -Capsule Manufactured -QOL’S Standard Issue bottles, caps and seal for products of the type ordered - Capsules packaged into bottles |
[Lables;Outer cartons or boxsr for bottles etc.] |
from label approval date |
N/A |
||
prododuct |
$ |
-Ingredients -Capsule Manufactured -QOL’S Standard Issue bottles, caps and seal for products of the type ordered - Capsules packaged into bottles |
[Lables;Outer cartons or boxsr for bottles etc.] |
from label approval date |
N/A |
||
prododuct |
$ |
-Ingredients -Capsule Manufactured -QOL’S Standard Issue bottles, caps and seal for products of the type ordered - Capsules packaged into bottles |
[Lables;Outer cartons or boxsr for bottles etc.] |
from label approval date |
N/A |
||
prododuct |
$ |
-Ingredients -Capsule Manufactured -QOL’S Standard Issue bottles, caps and seal for products of the type ordered - Capsules packaged into bottles |
[Lables;Outer cartons or boxsr for bottles etc.] |
from label approval date |
N/A |
||
prododuct |
$ |
-Ingredients -Capsule Manufactured -QOL’S Standard Issue bottles, caps and seal for products of the type ordered - Capsules packaged into bottles |
[Lables;Outer cartons or boxsr for bottles etc.] |
from label approval date |
N/A |
QOL Labs LLCHSBC BankMamaroneck BranchMamaroneck, NY 10543ABA# 021001088SWIFT# MRMDUS33Account # 489176437 |


Checkpoint¶
Checkpoint¶
-
class
kospeech.checkpoint.checkpoint.
Checkpoint
(model=None, optimizer=None, criterion=None, trainset_list=None, validset=None, epoch=None)[source]¶ The Checkpoint class manages the saving and loading of a model during training. It allows training to be suspended and resumed at a later time (e.g. when running on a cluster using sequential jobs). To make a checkpoint, initialize a Checkpoint object with the following args; then call that object’s save() method to write parameters to disk.
Parameters: - model (nn.Module) – LAS model being trained
- optimizer (torch.optim) – stores the state of the optimizer
- criterion (nn.Module) – loss function
- trainset_list (list) – list of trainset
- validset (e2e.data_loader.data_loader.SpectrogramDataset) – validation dataset
- epoch (int) – current epoch (an epoch is a loop through the full training data)
Variables: -
get_latest_checkpoint
()[source]¶ returns the path to the last saved checkpoint’s subdirectory. Precondition: at least one checkpoint has been made (i.e., latest checkpoint subdirectory exists).
-
load
(path)[source]¶ Loads a Checkpoint object that was previously saved to disk.
Parameters: path (str) – path to the checkpoint subdirectory Returns: checkpoint object with fields copied from those stored on disk Return type: checkpoint (Checkpoint)


Hisense King Kong 6 Officially Announced with 10010mAh battery - Gizchina.com
by PierreHisense King Kong 6 Officially Announced with 10010mAh battery
4 (80%) 2 votes
While most phone makers appear to be interested in launching new devices with as many camera sensors as technically possible, smaller Chinese company Hisense is actually more concerned about equipping their handsets with larger batteries.
Hisense did indeed just launch the new addition to the King Kong series. Which, as the name suggests, consists of smartphones of massive sizes. Let’s have a closer look!
Hisense King Kong 6 Officially Announced with 10010mAh battery
The device announced today is the Hisense King Kong 6 and the main feature about the device we know so far is the battery capacity. The new smartphone does in fact pack a large 10010mAh capacity battery for probably around four to five days of use without charging.
So, the King Kong 6 will be the smartphone with the largest battery coming from a relatively mainstream brand. Because, as some of you probably know, smaller brands like Oukitel, Blackview, Homtom among others, have already launched devices with 10000mAh or bigger capacity batteries.
But the King Kong 6 is more than a “battery phone”. Hisense promotes the smartphone as a flagship and that’s why we also get three rear cameras. These will probably include a primary wide angle lens, a secondary telephoto and a third ultra wide angle lens. On the back we also find a fingerprint scanner, while on the front we have a camera hidden in the notch.
Other specs on the Hisense King Kong 6 will be announced in the following days but we expect to find entry-level to mid-range class hardware, so not too much to be excited about.
What do you guys think about this new battery phone by Hisense? Would you consider getting one? Let us know down below!


The internet of things (IoT) is transforming everyday physical objects that surround us into an ecosystem of information that is rapidly changing the way we live our lives. WarCollar Industries is moving forward with a number of products and can help customers adopt and secure IoT for the enterprise
WarCollar cybersecurity professionals will not only examine your network systems and determine vulnerabilities, but assist in the remediation of those vulnerabilities to provide decision makers with the most accurate assessment of residual risk possible.
Our cybersecurity professionals are accomplished and trusted network defenders, with the skills and experience to separate actual incidents from false positives and ensure decision makers are given up to date risk status regarding their equities.
Our cybersecurity professionals can make sense of the jargon, acronyms, certifications and compliance requirements. From PCI to 800-53, WarCollar professionals will ensure your compliance testing succeeds.
Integrity
WarCollar Industries cybersecurity professionals hold themselves to the highest level of professional integrity in everything they do.
Innovation
WarCollar Industries is moving forward with Internet of Things (IoT) development and can help customers adopt and secure IoT for the enterprise.
Agility
As a veteran-owned business, WarCollar Industries has the discipline and focus to bring the best solution to the customer. As a small business, WarCollar is unencumbered by bureaucracy and can adjust quickly to a customer’s specifications.


Calculate power for generalised linear mixed models, using simulation. Designed to work with models fit using the 'lme4' package. Described in Green and MacLeod, 2016 <doi:10.1111/2041-210X.12504>.
| Version: | 1.0.4 |
| Depends: | lme4 (≥ 1.1-16) |
| Imports: | binom, iterators, pbkrtest, plotrix, plyr, RLRsim, stringr, stats, methods, utils, graphics, grDevices, car |
| Suggests: | testthat, knitr, rmarkdown, lmerTest (≥ 3.0-0) |
| Published: | 2018-04-30 |
| Author: | Green Peter [aut, cre], MacLeod Catriona [aut], Alday Phillip [ctb] |
| Maintainer: | Green Peter <simr.peter at gmail.com> |
| BugReports: | https://github.com/pitakakariki/simr/issues |
| License: | GPL-2 | GPL-3 [expanded from: GPL (≥ 2)] |
| URL: | https://github.com/pitakakariki/simr |
| NeedsCompilation: | no |
| Citation: | simr citation info |
| Materials: | README NEWS |
| CRAN checks: | simr results |
| Reference manual: | simr.pdf |
| Vignettes: |
Test examples Power analysis from scratch |
| Package source: | simr_1.0.4.tar.gz |
| Windows binaries: | r-devel: simr_1.0.4.zip, r-release: simr_1.0.4.zip, r-oldrel: simr_1.0.4.zip |
| OS X binaries: | r-release: simr_1.0.4.tgz, r-oldrel: simr_1.0.4.tgz |
| Old sources: | simr archive |
Please use the canonical form https://CRAN.R-project.org/package=simr to link to this page.


--- layout: default title: Events permalink: /events/ pinned: true index: true description: Events Page for Whiskey Flat Days in Kernville, CA tags: - events - whiskey flat days - whiskey flats - kernville - rodeo - encampment ---


Your one stop solution for all technology news and support.
Apple event
More news about apple eventiPhone6S
In and Out of Iphone6SSurface pro
Forget Laptop, use surface tabletNexus10
The big boy is coming soonSkype on TV – stay in touch from the comfort of your sofa
Get all the family together on your big screen – no matter what device they’re using Skype on.
The Surface Pro 3 is closer than Microsoft has ever been to making good on its mobile computing vision. After over a week with the slate, I'd go so far as to say that the Pro 3 is closer than any laptop-tablet hybrid released yet..Read More


| UTMP(5) | Linux Programmer's Manual | UTMP(5) |
Warning: utmp must not be writable by the user class "other", because many system programs (foolishly) depend on its integrity. You risk faked system logfiles and modifications of system files if you leave utmp writable to any user other than the owner and group owner of the file.
The file is a sequence of utmp structures, declared as follows in <utmp.h> (note that this is only one of several definitions around; details depend on the version of libc):
/* Values for ut_type field, below */ #define EMPTY 0 /* Record does not contain valid info (formerly known as UT_UNKNOWN on Linux) */ #define RUN_LVL 1 /* Change in system run-level (see init(8)) */ #define BOOT_TIME 2 /* Time of system boot (in ut_tv) */ #define NEW_TIME 3 /* Time after system clock change (in ut_tv) */ #define OLD_TIME 4 /* Time before system clock change (in ut_tv) */ #define INIT_PROCESS 5 /* Process spawned by init(8) */ #define LOGIN_PROCESS 6 /* Session leader process for user login */ #define USER_PROCESS 7 /* Normal process */ #define DEAD_PROCESS 8 /* Terminated process */ #define ACCOUNTING 9 /* Not implemented */ #define UT_LINESIZE 32 #define UT_NAMESIZE 32 #define UT_HOSTSIZE 256 struct exit_status { /* Type for ut_exit, below */ short int e_termination; /* Process termination status */ short int e_exit; /* Process exit status */ }; struct utmp { short ut_type; /* Type of record */ pid_t ut_pid; /* PID of login process */ char ut_line[UT_LINESIZE]; /* Device name of tty - "/dev/" */ char ut_id[4]; /* Terminal name suffix, or inittab(5) ID */ char ut_user[UT_NAMESIZE]; /* Username */ char ut_host[UT_HOSTSIZE]; /* Hostname for remote login, or kernel version for run-level messages */ struct exit_status ut_exit; /* Exit status of a process marked as DEAD_PROCESS; not used by Linux init (1 */ /* The ut_session and ut_tv fields must be the same size when compiled 32- and 64-bit. This allows data files and shared memory to be shared between 32- and 64-bit applications. */ #if __WORDSIZE == 64 && defined __WORDSIZE_COMPAT32 int32_t ut_session; /* Session ID (getsid(2)), used for windowing */ struct { int32_t tv_sec; /* Seconds */ int32_t tv_usec; /* Microseconds */ } ut_tv; /* Time entry was made */ #else long ut_session; /* Session ID */ struct timeval ut_tv; /* Time entry was made */ #endif int32_t ut_addr_v6[4]; /* Internet address of remote host; IPv4 address uses just ut_addr_v6[0] */ char __unused[20]; /* Reserved for future use */ }; /* Backward compatibility hacks */ #define ut_name ut_user #ifndef _NO_UT_TIME #define ut_time ut_tv.tv_sec #endif #define ut_xtime ut_tv.tv_sec #define ut_addr ut_addr_v6[0]
This structure gives the name of the special file associated with the user's terminal, the user's login name, and the time of login in the form of time(2). String fields are terminated by a null byte ('\0') if they are shorter than the size of the field.
The first entries ever created result from init(1) processing inittab(5). Before an entry is processed, though, init(1) cleans up utmp by setting ut_type to DEAD_PROCESS, clearing ut_user, ut_host, and ut_time with null bytes for each record which ut_type is not DEAD_PROCESS or RUN_LVL and where no process with PID ut_pid exists. If no empty record with the needed ut_id can be found, init(1) creates a new one. It sets ut_id from the inittab, ut_pid and ut_time to the current values, and ut_type to INIT_PROCESS.
mingetty(8) (or agetty(8)) locates the entry by the PID, changes ut_type to LOGIN_PROCESS, changes ut_time, sets ut_line, and waits for connection to be established. login(1), after a user has been authenticated, changes ut_type to USER_PROCESS, changes ut_time, and sets ut_host and ut_addr. Depending on mingetty(8) (or agetty(8)) and login(1), records may be located by ut_line instead of the preferable ut_pid.
When init(1) finds that a process has exited, it locates its utmp entry by ut_pid, sets ut_type to DEAD_PROCESS, and clears ut_user, ut_host and ut_time with null bytes.
xterm(1) and other terminal emulators directly create a USER_PROCESS record and generate the ut_id by using the string that suffix part of the terminal name (the characters following /dev/[pt]ty). If they find a DEAD_PROCESS for this ID, they recycle it, otherwise they create a new entry. If they can, they will mark it as DEAD_PROCESS on exiting and it is advised that they null ut_line, ut_time, ut_user, and ut_host as well.
telnetd(8) sets up a LOGIN_PROCESS entry and leaves the rest to login(1) as usual. After the telnet session ends, telnetd(8) cleans up utmp in the described way.
The wtmp file records all logins and logouts. Its format is exactly like utmp except that a null username indicates a logout on the associated terminal. Furthermore, the terminal name ~ with username shutdown or reboot indicates a system shutdown or reboot and the pair of terminal names |/} logs the old/new system time when date(1) changes it. wtmp is maintained by login(1), init(1), and some versions of getty(8) (e.g., mingetty(8) or agetty(8)). None of these programs creates the file, so if it is removed, record-keeping is turned off.
Linux defines the utmpx structure to be the same as the utmp structure.
v7/BSD has fewer fields; most importantly it lacks ut_type, which causes native v7/BSD-like programs to display (for example) dead or login entries. Further, there is no configuration file which allocates slots to sessions. BSD does so because it lacks ut_id fields.
In Linux (as in System V), the ut_id field of a record will never change once it has been set, which reserves that slot without needing a configuration file. Clearing ut_id may result in race conditions leading to corrupted utmp entries and potential security holes. Clearing the abovementioned fields by filling them with null bytes is not required by System V semantics, but makes it possible to run many programs which assume BSD semantics and which do not modify utmp. Linux uses the BSD conventions for line contents, as documented above.
System V has no ut_host or ut_addr_v6 fields.
The file format is machine-dependent, so it is recommended that it be processed only on the machine architecture where it was created.
Note that on biarch platforms, that is, systems which can run both 32-bit and 64-bit applications (x86-64, ppc64, s390x, etc.), ut_tv is the same size in 32-bit mode as in 64-bit mode. The same goes for ut_session and ut_time if they are present. This allows data files and shared memory to be shared between 32-bit and 64-bit applications. This is achieved by changing the type of ut_session to int32_t, and that of ut_tv to a struct with two int32_t fields tv_sec and tv_usec. Since ut_tv may not be the same as struct timeval, then instead of the call:
gettimeofday((struct timeval *) &ut.ut_tv, NULL);
the following method of setting this field is recommended:
struct utmp ut; struct timeval tv; gettimeofday(&tv, NULL); ut.ut_tv.tv_sec = tv.tv_sec; ut.ut_tv.tv_usec = tv.tv_usec;
| 2017-09-15 | Linux |


How To Use?
Install
The package is on NPM:
npm install sowstring
Usage
For NodeJS, just require the file:
var SowString = require ("sowstring").SowString;
var tree = SowString (sourceString, optionsObject);
On browsers, include the script:
<script src="path/to/library/dist/sowstring.js"></script>
You will have SowString
registered globally in the window
object. The function has the classes SowString.Node
and SowString.Leaf
as well.
Options
Options should be passed as an object to the second argument of SowString (source, { options:here })
function, and all its fields are optionals:
emptyLines
(Boolean) — when true, preserve the empty lines in the final tree items. When false, empty lines will be entirely ignored. Default: false.
error
(Function) — when provided, it executes always when the indent is invalid in the string or made invalid by the intercept
function. The function is called without arguments, with an handler object as this
and ignores returns. It is the last chance to fix manually an indent error, and whether it is not fixed, it will fix automatically or throw an exception, according to fixIndent
option. See below for a complete reference of the this
object passed to the function, and its uses. Default: null.
fixIndent
(Boolean) — when true, indent errors will be fixed automatically, if not error
handler, nor intercept
callback take care of it. If false, an exception is thrown, identifying the error and line of occurence. Default: false.
intercept
(Function) — when provided, it executes the function for each line. The function is called without arguments, with an handler object as this
and ignores returns. See below for a complete reference of the this
object and its uses. The function will not handle empty lines. Default: null.
tabReplace
(String or Number) — set this option to the string that will replace every TAB character (ASCII: 9), or to the amount of spaces that replace it. Default: string with 4 whitespaces.
useHeading
(Boolean) — when true, tree omits each item before arrays of nodes and set those line as heading
attributes of nodes. The option itself is saved in the tree outter node as useHeading
to remember the tree scheme. Default: false.
Intercept and Error context object (this)
The callbacks error
and intercept
passed to the options are called without arguments. The handling is made through the this
object. The object has some useful informations and functions to handle various cases. See below a list of properties and functions:
hasErrors
(Boolean) — inform if the current indent is invalid according to the tree. See the section about invalid indent below.
indent
(Number) — get or set the indent of the item. The indent is given by the number of whitespaces before the line start. Its concept is the same as the code indentation. Strings indented with 2 spaces will also have the indents multiple of 2 (0, 2, 4, 6…).
level
(Number) — get or set the level assigned to the item. The level is the height of the item in the tree, according to the indent, being no indent the level 0, the first indent the level 1 and so on…
lineNum
(Number, readonly) — number of the line currently being parsed in the given string.
startIndent
(Number, readonly) — inform the original indent of the item when the function was called. This value will not update during the function execution.
startLevel
(Number, readonly) — inform the original level of the item when the function was called. This value will not update during the function execution.
text
(String) — get or set the text assigned to the item. The initial value is the line of the string assigned with the item.
discard ()
(no return) — the item and line will be completely ignored and will not be included in the resulting tree. Use this function to remove lines on the fly.
getProp (name)
(returns the value) — get a custom property previously assigned to the current item.
setProp (name, value)
(no return) — set a custom property to the current item. This is useful to assign the item with custom fields related to the user logic. There are some reserved names which you cannot use: constructor
, prototype
, indent
, level
, lineNum
, parent
and children
.
setChild ()
(no return) — causes the item to be a child of the previous appended item. The item will have the same indent as the previous plus 1.
setParent ()
(no return) — causes the item to back to the parent level of the previous appended item. The item will have the same indent as the parent of the previous item.
setSibling ()
(no return) — causes the item to be a sibling of the previous appended item. The item will have the very same indent as the previous item.
setSiblingOfNext ()
(no return) — the item will not be appended in the tree while the next item is not appended. When the next item is appended, all the stack of "siblings of next" are appended before it, in the same level. It is the same process used to fix invalid indentations.
Tree to String
If you want to get back the tree as a string, you can use the toString
method in the most outter (root) node. This node is the tree itself, which is returned from the SowString
function.
var myString = myTree.toString ()
Here we also have options, which is also a plain object:
var myString = myTree.toString({…options…})
Options
details
(Boolean) — If true, the resulting string will include a note between brackets [ ]
defining if the object is a Node or Leaf, and the line that generated the item. Default: false.
Invalid indent and poisonous trees
If the string has inconsistent indentation, it msut be treated before the item is added on the tree.
If no process fix the error, and fixIndent
is false, an error of type
Error
will be thrown informing the line of occurence. Otherwise, the fixed indent
is assigned to the item.
For example, consider the following tree:
Parent
Node 1
Node 2
Node 3
Node 4
Observe the Node 3
item, it has one space less than the previous
item, but has three spaces more than the parent. It can be hard to realize
what were the intention of the user. For the computer, the item cannot be the parent,
as it has much more indentation, and cannot be a sibling because it is very little indented.
So, it is not a parent, sibling or child, and there's no other state in our
tree.
Solution I
This issue can be solved automatically by the library passing the option
fixIndent
as true
. In this case, the item awaits
for the next inclusion and is appended as sibling of next item.
Solution II
The user can set an error
callback in the options. So, if the
line as any issue relative to its indent, the function is called and the
user can set a valid indent using the this
object. If this
function just call this.setSiblingOfNext ();
, this code will
do exactly the same as the fixIndent
option.
If the error is not really solved in this option, the algorithm will fallback
to the fixIndent
option. If the option is not enabled, an error
is thrown.
This approach can be combined with solution I and executes before that.
Solution III
The user can also check for indent errors in the intercept
function passed in the options. The check can be made using the hasErrors
field of the this
object. If the indent has errors, the user can
fix it manually.
The intercept function is executed before the error
function, and both execute before the automatic fix (fixIndent
).
Then, the first try of the library is to use the intercept function,
if there is an error in the indent, the error function is called and,
if the error wasn't solved, the automatic fix is executed or an error is thrown.
This approach can be combined with solution I and II and executes before them.


| Rule Violations |
Count |
| Clearance Constraint (Gap=0.15mm) (All),(All) |
0 |
| Clearance Constraint (Gap=0.3mm) (OnLayer('Ground Plane') or OnLayer('Power Plane')),(All) |
0 |
| Short-Circuit Constraint (Allowed=No) (All),(All) |
0 |
| Un-Routed Net Constraint ( (All) ) |
0 |
| Modified Polygon (Allow modified: No), (Allow shelved: No) |
0 |
| Width Constraint (Min=0.15mm) (Max=2mm) (Preferred=0.2mm) (All) |
0 |
| SMD To Corner (Distance=0.1mm) (Not InNet('*SENSE*') And Not InNet('V_24P0') And Not InNet('V_5P0') And Not InNet('V_IN_24P0') And Not InNet('V_REG_5P0')) |
0 |
| SMD Entry (Side = Allowed) (Corner = Not Allowed) (Any Angle = Not Allowed) (Ignore First Corner = Allowed) |
0 |
| Power Plane Connect Rule(Direct Connect )(Expansion=0.175mm) (Conductor Width=0.2mm) (Air Gap=0.2mm) (Entries=4) (All) |
0 |
| Minimum Annular Ring (Minimum=0.174mm) (((ObjectKind = 'Pad') OR (ObjectKind = 'Via')) And (Layer = 'MultiLayer') And (HoleDiameter <= AsMM(0.45))) |
0 |
| Minimum Annular Ring (Minimum=0.174mm) (((ObjectKind = 'Pad') OR (ObjectKind = 'Via')) And (Layer = 'MultiLayer') And (HoleDiameter > AsMM(0.45))) |
0 |
| Hole Size Constraint (Min=0.25mm) (Max=3.5mm) (All) |
0 |
| Hole To Hole Clearance (Gap=0.35mm) (All),(All) |
0 |
| Hole To Hole Clearance (Gap=0.2mm) (Not PadIsPlated),(Not PadIsPlated) |
0 |
| Minimum Solder Mask Sliver (Gap=0.08mm) (All),(All) |
0 |
| Silk To Solder Mask (Clearance=0.1mm) (IsPad),(All) |
0 |
| Silk to Silk (Clearance=0.2mm) (All),(All) |
0 |
| Net Antennae (Tolerance=0mm) (All) |
0 |
| Board Clearance Constraint (Gap=0mm) (Not OnSilkscreen) |
0 |
| Room SLOT1 (Bounding Region = (21.48mm, 68.45mm, 41.8mm, 110.36mm) (InComponentClass('SLOT1')) |
0 |
| Room I2C (Bounding Region = (32.2mm, 112.795mm, 49.1mm, 120.695mm) (InComponentClass('I2C')) |
0 |
| Room MASTER (Bounding Region = (139.3mm, 122.72mm, 172.5mm, 166.995mm) (InComponentClass('MASTER')) |
0 |
| Room POWER (Bounding Region = (97.3mm, 114.995mm, 142.1mm, 156.475mm) (InComponentClass('POWER')) |
0 |
| Room CONNECTORS (Bounding Region = (81.7mm, 150.095mm, 143.6mm, 172.495mm) (InComponentClass('CONNECTORS')) |
0 |
| Room USB (Bounding Region = (90.1mm, 111.995mm, 138.1mm, 149.395mm) (InComponentClass('USB')) |
0 |
| Room LAN (Bounding Region = (22.9mm, 96.395mm, 148.9mm, 171.595mm) (InComponentClass('LAN')) |
0 |
| Room DOWNSTREAM (Bounding Region = (14.825mm, 55.75mm, 33.6mm, 175.75mm) (InComponentClass('DOWNSTREAM')) |
0 |
| Room ADDR (Bounding Region = (142.4mm, 147.195mm, 157.8mm, 161.495mm) (InComponentClass('ADDR')) |
0 |
| Room SLOT3 (Bounding Region = (62.12mm, 68.45mm, 82.44mm, 110.36mm) (InComponentClass('SLOT3')) |
0 |
| Room SLOT2 (Bounding Region = (41.8mm, 68.45mm, 62.12mm, 110.36mm) (InComponentClass('SLOT2')) |
0 |
| Room SLOT6 (Bounding Region = (123.08mm, 68.45mm, 143.4mm, 110.36mm) (InComponentClass('SLOT6')) |
0 |
| Room SLOT4 (Bounding Region = (82.44mm, 68.45mm, 102.76mm, 110.36mm) (InComponentClass('SLOT4')) |
0 |
| Room SLOT7 (Bounding Region = (143.4mm, 68.45mm, 163.72mm, 110.36mm) (InComponentClass('SLOT7')) |
0 |
| Room UPSTREAM (Bounding Region = (151.6mm, 55.75mm, 170.075mm, 175.75mm) (InComponentClass('UPSTREAM')) |
0 |
| Room SLOT5 (Bounding Region = (102.76mm, 68.45mm, 123.08mm, 110.36mm) (InComponentClass('SLOT5')) |
0 |
| Height Constraint (Min=0mm) (Max=25mm) (Prefered=12.5mm) (All) |
0 |
| Total |
0 |


SC agrees to hear Madhu Koda's plea challenging his disqualification by EC
Koda was disqualified by the poll panel in 2017 for not submitting poll expenses incurred by him in contesting assembly election in an appropriate format
by Press Trust of IndiaThe Supreme Court on Wednesday agreed to hear a plea filed by former Jharkhand chief minister Madhu Koda challenging his disqualification by the Election Commission in 2017 for not submitting poll expenses.
A bench headed by CJI designate Justice S A Bobde took note of the submission that Koda's petition needed an urgent hearing in view of the fact that the last date for filing nomination for the upcoming Assembly polls was concluding on November 18.
"List this petition for hearing before appropriate bench on Friday," the bench said.
Koda was disqualified by the poll panel in 2017 for not submitting poll expenses incurred by him in contesting assembly election in an appropriate format.
Koda, an Independent MLA, served as the chief minister from 2006 to 2008.


We’re in Front of the Competition…
Serving Your Home Bar..
From simple to lavish, customize a bar for your home or private club. No design is too complex for us to create for you!
Our Home Bar Features
Here are a few of the things that make this automated bar so great.
Custom Design
Your Bar. Your Way. Any way.
Speed Control
Ideally controlled per your function type
App
Custom-built app to complement your customized bar
Easy Maintenance
No more maintenance than the toaster in your kitchen


|
| Last modified on Sat Jul 22 11:14:10 2023 UTC. | Improve this page |
From the software point of view, an embedded system is a small computer, built for a dedicated function (as opposed to general purpose computers).
There are many types of embedded systems, with varying degrees of complexity, from small proximity sensors used in home automation, to internet routers, remote surveillance cameras and even smart phones.
Complex systems, especially those with high bandwidth communication needs, are designed around embedded versions of GNU/Linux, which include a large kernel, a root file system, multiple processes, not very different from their larger cousins running on desktop computers.
The application is generally a combination of processes running in user space, and device drivers, running inside the kernel.
Smaller devices have much less resources, and are build around microcontrollers which do not have the required hardware to properly run an Unix kernel.
In this case the application is monolithic and runs directly on the hardware, thus the name bare-metal.
µOS++ focuses on these bare-metal applications, especially those running on ARM Cortex-M devices. Although µOS++ can be ported on larger ARM Cortex-A cores, even the 64-bits ones, there are no plans to include support for MMU, virtual memory, separate processes and other such features specific to the Unix world.
A real-time embedded system is a piece of software that manages the resources and the time behaviour of an embedded device, usually build around a microcontroller, emphasising on the correctness of the computed values and their availability at the expected time.
µOS++ is a real-time operating system (RTOS).
There are two types of real-time systems, hard and soft real-time systems.
The main difference between them is determined by the consequences associated with missing deadlines. Obtaining correctly computed values but after the deadline has passed may range from useless to dangerous.
For hard real-time systems the tolerance to missing deadlines is very low, since missing a deadline often results in a catastrophe, which may involve the loss of human lives.
For soft real-time systems this tolerance is not as tight, since missing deadlines is generally not as critical.
Absolute hard real-time systems, with near zero tolerance, are typically very difficult to design, and it is recommended to approach them with caution.
However, with a careful design, reasonable tolerance can be obtained, and µOS++ can be successfully used in real-time applications.
Legal-notice: According to the MIT license, “the software is provided as-is, without warranty of any kind”. As such, its use in life threatening applications should be avoided.
There are many techniques for writing embedded software. For low complexity systems, the classic way does not use an RTOS, but are designed as foreground/background systems, or superloops.
An application consists of an infinite loop that calls one or more functions in succession to perform the desired operations (background).
Interrupt service routines (ISRs) are used to handle the asynchronous, real-time parts of the application (foreground).
In this architecture, the functions implementing the various functionalities are inherently, even if not formally declared as such, some kind of finite state machines, spinning around and switching states based on inputs provided by the ISRs.
Superloop application
The superloop technique has the advantage of requiring only one stack and sometimes may result in simpler applications, especially when the entire functionality is performed on ISRs, and the background logic is reduced to an empty loop waiting for interrupts.
However, for slightly more complex applications, expressing the entire logic as a set of state machines is not easy, and maintenance becomes a serious problem as the program grows.
The overall reaction speed may also be a problem, since the delay between the moment when the ISR makes available the input and the moment when the background routine can use it is not deterministic, depending on many other actions that can happen at the same time in the superloop.
To ensure that urgent actions are performed in a timely manner, they must be moved on the ISRs, lengthening them and further worsening the reaction speed of the application.
Regardless how elaborate the techniques for implementing the finite state machines are, the human mind still feels more comfortable with linear representations of lists of steps to be done, than with graph and state tables.
In the µOS++ context, a task is a well defined sequence of operations, usually represented in a programming language as a function.
A complex application can be decomposed as a series of tasks, some executed in succession, some executed in parallel and possibly exchanging data.
Multi-tasking is the technique of running multiple tasks in parallel.
The Java Threads book (one of the inspiration source for the early versions of this project) states:
Historically, threading was first exploited to make certain programs easier to write: if a program can be split into separate tasks, it’s often easier to program the algorithm as separate tasks or threads… while it is possible to write a single-threaded program to perform multiple tasks, it’s easier and more elegant to place each task in its own thread.
Threads and processes are the operating system mechanisms for running multiple tasks in parallel.
The main difference between threads and processes is how the memory space is organised. Processes run in separate, virtual memory spaces, while threads share a common memory space.
The implementation of virtual memory requires hardware support for a MMU, available only in application class processors, like the Cortex-A devices.
Smaller devices, like the ARM Cortex-M devices, can still run multiple tasks in parallel, but, without a MMU and the benefits of virtual memory, these multiple tasks are performed by multiple threads, all sharing the same memory space.
As such, µOS++ is a multi-threaded system, supporting any number of threads, with the actual number limited only by the amount of available memory.
One of the most encountered scenario when implementing tasks, is to wait for some kind of input data, for example by performing a read()
, then process the data and, most of the times, repeat this sequence in a loop. When the system executes the read()
call, the thread might need to wait for the required data to become available before it can continue to the next statement. This type of I/O is called blocking I/O: the thread blocks until some data is available to satisfy the read()
function.
One possible implementation is to loop until the data becomes available, but this type of behaviour simply wastes resources (CPU cycles and implicitly power) and should be avoided by all means.
Well behaved applications should never enter (long) busy loops waiting for conditions to occur, but instead suspend the thread and arrange for it to be resumed when the condition is met. During this waiting period the thread completely releases the CPU, so the CPU will be fully available for the other active threads.
For the sake of completeness, it should be noted that the only exception to the rule applies to short delays, where short means delays with durations comparable with the multitasking overhead required to suspend/resume threads (where the context switching time plays an important role). On most modern microcontrollers this is usually in the range of microseconds.
As seen before, at thread level, the goal is to process the available data as soon as possible and suspend itself to wait for more data. In other words, the thread ideal way of life should be… to do nothing!
But what happens if all threads accomplish this goal and there is nothing else to do?
Well, enter the idle thread. This internal thread is always created before the scheduler is started; it has the lowest possible priority, and is always running when there are no more other threads to run.
The idle thread can perform various low priority maintenance chores (like destroying terminated threads), but at a certain moment even the idle thread will have nothing else to do.
When the idle thread has nothing to do, it still can do something useful: it can put the CPU to a shallow sleep, and wait for the next interrupt (the Cortex-M devices use the Wait For Interrupt instruction for this).
In this mode the CPU is fully functional, with all internal peripherals active, but it does not run any instructions, so it is able to save a certain amount of power.
If the application has relatively long inactive moments, further savings are possible, i.e. power down all peripherals except a low frequency real time timer, usually triggered once a second. In this case the idle task can arrange for the CPU to enter a deep sleep mode, saving a significantly higher amount of power.
As a summary, the multilevel strategy used to reduce power consumption implies:
In conclusion, by using a wide range of power management techniques, an RTOS can be successfully used in very low power applications.
Running multiple threads in parallel is only apparent, since under the hood the threads are decomposed in small sequences of operations, serialised in a certain order, on the available CPU cores. If there is only one CPU core, there is only one running thread at a certain moment. The other threads are suspended, in a sense are frozen and put aside for later use; when the conditions are again favourable, each one may be revived and, for a while, allowed to use the CPU.
Suspended threads are sometimes called sleeping, or dormant; these terms are also correct, but it must be clearly understood that the thread status is only a software status, that has nothing to do with the CPU sleep modes, which are hardware related; the existence of suspended threads means only that the threads are not scheduled for execution; they do not imply that the CPU will enter any of the sleep modes, which may happen only when all threads are suspended.
Restarting a suspended thread requires restoring exactly the internal CPU state existing at the moment when the thread was suspended. Physically, this state is usually stored in a certain number of CPU registers. When the thread is suspended, the content of these registers must be stored in a separate RAM area, specific to each thread. When the thread is resumed, the same registers must be restored with the saved values.
This set of information required to resume a thread is also called the thread execution context, in short the context.
The set of operations required to save the context of the running thread, select the next thread and restore its context is called context switching.
Modern CPUs, like the ARM Cortex-M devices, make use of a stack to implement nested function calls and local function storage.
The same stack can be used to store the thread context. When starting a context switch all registers are pushed onto the thread stack. Then the resulting stack pointer is saved in the thread context area. Resuming a thread is done in reverse order, i.e. the stack pointer is retrieved from the thread context, all registers are popped from the stack and execution is resumed.
This mechanism usually simplifies the scheduler implementation; it is used in the Cortex-M port of the µOS++ scheduler.
Historical note: early microcontrollers, like PIC before the 18 series, did not have a general purpose stack; instead they had a limited call stack, allowing only a small number of nested calls.
The most frequent reason for a context switch is when a thread decides to wait for a resource that is not yet available, like a new character from a device, a message in a queue, a mutex protecting a shared resource, etc.
In this case, yielding the CPU from one thread to another is done implicitly by the system function called to wait for the resource.
In case of long computations, a well behaved thread would not hold the CPU for the entire computation period, but explicitly yield the CPU from time to time, to give other threads a chance to run.
This polite behaviour, when the switch is performed by the thread itself, is called cooperative multi-tasking, since it depends on a the good-will of all tasks running in parallel.
The biggest disadvantage of cooperative multi-tasking is a possible low reaction speed, for example when an interrupt wants to resume a high priority thread, this might not happen until the low priority thread decides to yield.
Cooperative context switching.
In this case the solution is to allow the interrupt to trigger a context switch from the low priority thread to the high priority thread without the threads event knowing about. This automatic kind of context switch is also called preemptive multi-tasking, since long running threads are preempted to hog the CPU in favour of higher priority threads.
Preemptive context switching
Once the mechanism for an interrupt to preempt a thread is functional, a further improvement can be added: a periodic timer (for example the timer used to keep track of time), can be used to automatically preempt threads and give a chance to equal priority threads to alternatively get the CPU.
Preemptive context switching with periodic timer
In general cooperative multitasking is easier to implement, and, since the CPU is released under the application control, inter-thread synchronisation race conditions are avoided. However, at a more thorough analysis, this is not necessarily a feature, but a subtle way to hide other application synchronisation bugs, like the lack of explicit critical sections. In other words, a well behaved application should protect a shared resource by use of a critical section anyway, since although another task cannot execute inside another task, interrupt service routines can, and without the critical section it is very likely that a race condition may occur.
One special useful application of the cooperative mode is for debugging possible inter-thread race conditions. In case of strange behaviours that might be associated with synchronisation problems, if disabling preemption solves the problem, then an inter-thread race condition is highly probable. It the problem is still present in cooperative mode, than most probably the race condition involves the interrupt service routines. In both cases, the cure is to use critical sections where needed.
µOS++ implements both cooperative and preemptive multi-tasking.
Most schedulers keep track of time, at least for handling timeouts. Technically this is implemented with a periodic hardware timer, and timeouts are expressed in timer ticks.
A common frequency for the scheduler timer is 1000 Hz, which gives a resolution of 1 ms for the scheduler derived clock.
For preemptive schedulers, the same timer can be used to trigger context switches.
Acknowledging the importance of a system timer, ARM defined SysTick as a common timer for Cortex-M devices, which makes it a perfect match for the scheduler timer.
In real life applications, there are cases when some threads, for various reasons, must be interrupted.
µOS++ threads include support for interruption, but this support is cooperative, i.e. threads that might be interrupted should check for interruption requests and quit inner loops in an ordered manner.
A thread control block (TCB) is a data structure used by the scheduler to maintain information about a thread. Each thread requires its own TCB.
Being implemented in a structured, object oriented language like C++, the µOS++ threads implicitly have instance data structures associated with the objects, which are functionally equivalent to common TCBs; in other words, the µOS++ TCBs are the actual thread instances themselves.
The thread internal variables are protected, and cannot be directly accessed from user code, but for all relevant members there are public accessor and mutator functions defined.
The mechanism that performs the context switches is also called scheduling, and the code implementing this mechanism is also called scheduler.
During their lifetime, threads can be in different states.
Apart from some states used during thread creation and destruction, the most important thread states are:
To performs its duties efficiently, the scheduler needs to keep track only of the threads ready to run. Threads that for a little while must wait for various events can be considered to momentarily exit the scheduler jurisdiction, and other mechanisms, like timers, synchronisation objects, notifications, etc are expected to return them to the scheduler when ready to run.
In order to keep track of the ready threads, the scheduler maintains a ready list. The term list is generic, regardless of the actual implementation, which might be anything from a simple array to multiple double linked lists.
The main existential question in the life of a scheduler is how to select the next thread to run among the treads in the READY list? This question is actually much more difficult to answer when dealing with a hard real-time application, with strict life or death deadlines for threads.
Legal notice: From this point of view it must be clearly stated that the µOS++ scheduler does not guarantee any deadlines in thread executions.
However, what the µOS++ scheduler does, is to be as fair as possible with existing threads, and give them the best chance to access the CPU.
One of the simple ways to manage the ready list is FIFO, with new threads inserted at the back, and the scheduler extracting from the front. This mechanism works well if there is no need to guarantee response time.
When response time becomes important, the mechanism can be greatly improved by assigning priorities to threads, and ordering the ready list by priorities.
By always inserting higher priority threads immediately in front of the lower priority ones, two goals are achieved at the same time:
By default, the µOS++ user threads are created with normal priority. As the result, the scheduler default behaviour is round-robin.
As soon as thread priorities are changed, the scheduler behaviour automatically changes to priority scheduling, falling back to round-robin for threads with equal priorities.
As a general rule, threads that implement hard real-time functions should be assigned priorities above those that implement soft real-time functions. However, other characteristics, such as execution times and processor utilization, must also be taken into account to ensure that the entire application will never miss a hard real-time deadline.
One possible technique is to assign unique priorities, in accordance with the thread periodic execution rate (the highest priority is assigned to the thread that has the highest frequency of periodic execution). This technique is called Rate Monotonic Scheduling (RMS).
Priority inversion is a problematic scenario in scheduling in which a high priority thread is indirectly prevented to run by a lower priority thread effectively “inverting” the relative priorities of the two threads.
The first scenario is the following:
Although for the high priority thread this is an unfortunate scenario, there is not much that it can do but wait for the low priority thread to release the resource.
An even more unfortunate scenario is the following:
Priority inversion
The problem in this scenario is that although the high priority thread announced its intention to acquire the resource and knows it must wait for the low priority thread to release it, a medium priority thread can still prevent this to happen, behaving as like having the highest priority. This is known as unbounded priority inversion. It is unbounded because any medium priority can extend the time the high priority thread has to wait for the resource.
This problem was known for long, but many times ignored, until it was reported to have affected the NASA JPL’s Mars Pathfinder spacecraft (see What really happened on Mars?).
One of the possible solutions to avoid this is for the high priority thread to temporarily boost the priority of the low priority thread, to prevent other threads to interfere and so help the low priority thread to complete its job sooner. This is known as priority inheritance.
Priority inheritance
To be noted that priority inheritance does not completely fix the priority inversion problem, the high priority thread still has to wait for the low priority thread to release the resource, but at least it does its best to prevent other middle priority threads to interfere. It is not a good practice to rely only on priority inheritance for correct system operation and the problem should be avoided at system design time, by considering how resources are accessed.
In a multi-tasking application, the threads and the ISRs are basically separate entities. However, in order to achieve the application’s goals, they must work together and exchange information in various ways.
The easiest way to communicate between different pieces of code is by using global variables. In certain situations, it can make sense to communicate via global variables, but most of the time this method has disadvantages.
For example, if you want to synchronize a thread to perform some action when the value of a global variable changes, the thread must continually poll this variable, wasting precious computation time and energy, and the reaction time depends on how often you poll.
A better way is to suspend the waiting thread and, when the expected event occurs, to resume it. This method requires a bit of support from the system, to manage the operations behind suspend/resume, but has the big advantage that a suspended thread does not waste computation time and energy.
A message queue is usually an array of structures accessed in a FIFO way. Threads or ISRs can send messages to the queue, and other threads or interrupts can consume them.
Threads can block while waiting for messages, and as such do not waste CPU cycles.
Semaphores, and especially binary semaphores, are commonly used to pass notifications between different parts of the code, mostly from ISRs to threads. However, they have a richer semantic, especially the counting semaphores, and can also be used to keep track of the number of available resources (for example total positions in a circular buffer), which somehow places them at the border with managing shared resources.
An event flag is a binary variable, representing a specific condition that a thread can wait for. When the condition occurs, the flag is raised and the thread is resumed.
Multiple flags can be grouped and the thread can be notified when all or any of the flags was raised.
A shared resource is typically a variable (static or global), a data structure, table (in RAM), or registers in an I/O device, accessed in common by different parts of the code.
Typical examples are lists, memory allocators, storage devices, that all need a specific method to protect against concurrent accesses.
The technique for obtaining exclusive access to shared resources is to create critical sections, which temporarily lock access.
When the resource is also accessed from ISRs, the usual solution to prevent an ISR to access the resource at the same time with a thread or another lower priority ISR, is to temporarily disable the interrupts while using the shared resource.
The overhead to disable/enable interrupts is usually low, and for some devices, like the Cortex-M[347] ones, it is even possible to disable interrupts only partially, from a given priority level down, keeping high priority interrupts enabled.
Although apparently simple, this technique is often misused in cases of nested critical sections, when the inner critical section inadvertently enables interrupts, leading to very hard to trace bugs. The correct and bullet proof method to implement the critical sections is to always save the initial interrupt state and restore it when the critical section is exited.
This method must be used with caution, since keeping the interrupts disabled too long impacts the system responsiveness.
Typical resources that might be protected with interrupts critical sections are circular buffers, linked lists, memory pools, etc.
If the resource is not accessed from ISRs, a simple solution to prevent other threads to access it is to temporarily lock the scheduler, so that no context switches can occur.
Locking the scheduler has the same effect as making the task that locks the scheduler the highest-priority task.
Similar to interrupts critical sections, the implementation of scheduler critical sections must consider nested calls, and always save the initial scheduler state and restore it when the critical section is exited.
This method must be used with caution, since keeping the scheduler locked too long impacts the system responsiveness.
Counting semaphores can be used to control access to shared resources used on ISRs, like circular buffers.
Since they may be affected by priority inversions, their use to manage common resources should be done with caution.
This is the preferred method for accessing shared resources, especially if the threads that need to access a shared resource have deadlines.
µOS++ mutexes have a built-in priority inheritance mechanism, which avoids unbound priority inversions.
However, mutexes are slightly slower (in execution time) than semaphores since the priority of the owner may need to be changed, which requires more CPU processing.
A semaphore should be used when resources are shared with an ISR.
A semaphore can be used instead of a mutex if none of the threads competing for the shared resource have deadlines to be satisfied.
However, if there are deadlines to meet, you should use a mutex prior to accessing shared resources. Semaphores are subject to unbounded priority inversions, while mutexes are not. On the other hand, mutexes cannot be used on interrupts, since they need an owner thread.
A deadlock, also called a deadly embrace, is a situation in which two threads are each unknowingly waiting for resources held by the other.
Consider the following scenario where thread A and thread B both need to acquire mutex X and mutex Y in order to perform an action:
At the end of this scenario, thread A is waiting for a mutex held by thread B, and thread B is waiting for a mutex held by thread A. Deadlock has occurred because neither thread can proceed.
As with priority inversion, the best method of avoiding deadlock is to consider its potential at design time, and design the system to ensure that deadlock cannot occur.
The following techniques can be used to avoid deadlocks:
Most system objects are self-contained, and the rule is that if the storage requirements are known, constant and identical for all instances, then the storage is allocated in the object instance data.
However some system objects require additional memory, different from one instance to the other. Examples for such objects are threads (which require stacks), message queues and memory pools.
This additional memory can be allocated either statically (at compile-time) or dynamically (at run-time).
By default, all base classes use the system allocator to get memory.
In C++ all such classes are doubled by templates which handle allocation.
Another solution, also available to the C API, is to pass user defined storage areas via the attributes used during object creation.
For all objects that might need memory, µOS++ uses the system allocator os::rtos::memory::allocator<T>
, which by default is mapped to an allocator that uses the standard new/delete primitives, allocating storage on the heap.
This allocator is a standard C++ allocator. The user can define another such standard allocator, and configure the system allocator to use it, thus customising the behaviour of all system objects.
Even more, system objects that need memory are defined as templates, which can be parametrised with an allocator, so, at the limit, each object can be constructed with its own separate allocator.
The biggest concern with using dynamic memory is fragmentation, a condition that may render a system unusable.
To be noted that internally µOS++ does not use dynamic allocation at all, so if the application is careful enough not to use objects that need dynamic allocation, the resulting code is fully static.
Most application handle time by using the scheduler timer.
However low power applications opt to put the CPU in a deep sleep, which usually powers down most peripherals, including the scheduler timer.
For these situations a separate low power real-time clock is required; powered by a separate power source, possibly a battery, this clock runs even when the rest of the device is sleeping.
This clock not only keeps track of time, it can also trigger interrupts to wakeup the CPU at desired moments.
The usual resolution of the real-time clock is 1 sec.
Many authors also refer to their RTOSes as “kernels”. Well, even if OS in RTOS stands for operating system, this definition is somehow stretched to the limit, since in bare-metal embedded systems the so called operating system is only a collection of functions handling thread switching and synchronisation, linked together with the application in a monolithic executable.
As such, the term kernel is even more inappropriate, since there is no distinct component to manage all available resources (memory, CPU, I/O, etc) and to provide them to the application in a controlled way; most of the time the application has full control over the entire memory space, which, for systems with memory mapped peripherals, also means full control over the I/O.
The only kernel specific function available in bare-metal embedded systems is CPU management; with multiple threads sharing the CPU, probably a more appropriate name for the RTOS core component is scheduler; the µOS++ documentation uses the term operating system in its definition, occasionally refers to itself as a scheduler, and explicitly tries to avoid the term kernel.
Many authors refer to threads as “tasks”. Strictly speaking, threads (together with processes) are the system primitives used to run multiple tasks in parallel in a multitasking system.


Log out of this browser, and remove all stored session data.
Use the following key to experiment with authenticated API calls using Swagger.


Sort By
Alphabetical Order
Episodes Watched
Order Added To The List
Name:
Status:
Watching
On Hold
Dropped
Completed
To Watch
Episode:
/
Comment(optional):
Submit
Name:
Status:
Watching
On Hold
Dropped
Completed
To Watch
Episode:
/
Comment(optional):
Submit
Remove
Anime page cache:
Enable
Disable
Cache Duration:
day(s)
This application has been created by Musbah Sinno
The source for most of the data is Anime News Network.
Current Ep:
Status:
Note:
Random
Search by genres
Filters
Loading anime information...
No Results found (try changing the filter)


It is a if every time I read one of his works I begin to catch myself, periodically through out the day, dreaming of nondescript facades of truly empty people living lives that question the very meaning of what it is to be a human being. His literature is paintings of life I have never once experienced before; it casts me into an ocean of fear and serenity that I wish to never escape from.
I am a fan. I truly am.


|
Bomberman
1.0
Re-make of Bomberman game
|
#include <Timer.h>
Public Member Functions | |
| Timer (float seconds, bool everlasting, funcType lambda) | |
| Timer ()=delete | |
| Timer (Timer const &)=delete | |
| Timer & | operator= (Timer const &)=delete |
| void | Tick () |
| virtual | ~Timer () |
| Public Member Functions inherited from TimerBase | |
| TimerBase ()=delete | |
| TimerBase (TimerBase const &)=delete | |
| TimerBase & | operator= (TimerBase const &)=delete |
| virtual | ~TimerBase () |
| bool | readyForDelete () |
| bool | usedTheEvent () |
Additional Inherited Members | |
| Public Attributes inherited from TimerBase | |
| bool | toDelete |
| bool | usedEvent |
|
inline |
|
delete |


The Legendz Brands is under Full Website Category.
It displays the most rated or top most brands which are expensive, original or genuine.
It also displays the top most fashion designers around the world for women. We focused on women because as in every fashion women are very active and sensitive when it comes to this category. We want to patronize the best brands that most of them prefer to have for its quality.


java.io.Serializable
, java.lang.Comparable<YearWeek>
, java.time.temporal.TemporalAccessor
, java.time.temporal.TemporalAdjuster
public final class YearWeek extends java.lang.Object implements java.time.temporal.TemporalAccessor, java.time.temporal.TemporalAdjuster, java.lang.Comparable<YearWeek>, java.io.Serializable
2015-W13
YearWeek
is an immutable date-time object that represents the combination
of a week-based-year and week-of-week-based-year.
Any field that can be derived from those two fields can be obtained.
This class does not store or represent a day, time or time-zone.
For example, the value "13th week of 2007" can be stored in a YearWeek
.
The ISO-8601 calendar system is the modern civil calendar system used today in most of the world. It is equivalent to the proleptic Gregorian calendar system, in which today's rules for leap years are applied for all time. For most applications written today, the ISO-8601 rules are entirely suitable. However, any application that makes use of historical dates, and requires them to be accurate will find the ISO-8601 approach unsuitable.
ISO-8601 defines the week as always starting with Monday. The first week is the week which contains the first Thursday of the calendar year. As such, the week-based-year used in this class does not align with the calendar year.
This class must be treated as a value type. Do not synchronize, rely on the identity hash code or use the distinction between equals() and ==.
| Modifier and Type | Method | Description |
|---|---|---|
java.time.temporal.Temporal |
adjustInto(java.time.temporal.Temporal temporal) |
Adjusts the specified temporal object to have this year-week.
|
java.time.LocalDate |
atDay(java.time.DayOfWeek dayOfWeek) |
Combines this year-week with a day-of-week to create a
LocalDate . |
int |
compareTo(YearWeek other) |
Compares this year-week to another
|
boolean |
equals(java.lang.Object obj) |
Checks if this year-week is equal to another year-week.
|
java.lang.String |
format(java.time.format.DateTimeFormatter formatter) |
Formats this year-week using the specified formatter.
|
static YearWeek |
from(java.time.temporal.TemporalAccessor temporal) |
Obtains an instance of
YearWeek from a temporal object. |
int |
get(java.time.temporal.TemporalField field) |
Gets the value of the specified field from this year-week as an
int . |
long |
getLong(java.time.temporal.TemporalField field) |
Gets the value of the specified field from this year-week as a
long . |
int |
getWeek() |
Gets the week-of-week-based-year field.
|
int |
getYear() |
Gets the week-based-year field.
|
int |
hashCode() |
A hash code for this year-week.
|
boolean |
is53WeekYear() |
Checks if the week-based-year has 53 weeks.
|
boolean |
isAfter(YearWeek other) |
Is this year-week after the specified year-week.
|
boolean |
isBefore(YearWeek other) |
Is this year-week before the specified year-week.
|
boolean |
isSupported(java.time.temporal.TemporalField field) |
Checks if the specified field is supported.
|
int |
lengthOfYear() |
Returns the length of the week-based-year.
|
YearWeek |
minusWeeks(long weeksToSubtract) |
Returns a copy of this year-week with the specified number of weeks subtracted.
|
YearWeek |
minusYears(long yearsToSubtract) |
Returns a copy of this year-week with the specified number of years subtracted.
|
static YearWeek |
now() |
Obtains the current year-week from the system clock in the default time-zone.
|
static YearWeek |
now(java.time.Clock clock) |
Obtains the current year-week from the specified clock.
|
static YearWeek |
now(java.time.ZoneId zone) |
Obtains the current year-week from the system clock in the specified time-zone.
|
static YearWeek |
of(int weekBasedYear,
int week) |
Obtains an instance of
YearWeek from a week-based-year and week. |
static YearWeek |
parse(java.lang.CharSequence text) |
Obtains an instance of
YearWeek from a text string such as 2007-W13 . |
static YearWeek |
parse(java.lang.CharSequence text,
java.time.format.DateTimeFormatter formatter) |
Obtains an instance of
YearWeek from a text string using a specific formatter. |
YearWeek |
plusWeeks(long weeksToAdd) |
Returns a copy of this year-week with the specified number of weeks added.
|
YearWeek |
plusYears(long yearsToAdd) |
Returns a copy of this year-week with the specified number of years added.
|
<R> R |
query(java.time.temporal.TemporalQuery<R> query) |
Queries this year-week using the specified query.
|
java.time.temporal.ValueRange |
range(java.time.temporal.TemporalField field) |
Gets the range of valid values for the specified field.
|
java.lang.String |
toString() |
Outputs this year-week as a
String , such as 2015-W13 . |
YearWeek |
withWeek(int week) |
Returns a copy of this
YearWeek with the week altered. |
YearWeek |
withYear(int weekBasedYear) |
Returns a copy of this
YearWeek with the week-based-year altered. |
public static YearWeek now()
This will query the system clock
in the default
time-zone to obtain the current year-week.
The zone and offset will be set based on the time-zone in the clock.
Using this method will prevent the ability to use an alternate clock for testing because the clock is hard-coded.
public static YearWeek now(java.time.ZoneId zone)
This will query the system clock
to obtain the current year-week.
Specifying the time-zone avoids dependence on the default time-zone.
Using this method will prevent the ability to use an alternate clock for testing because the clock is hard-coded.
zone
- the zone ID to use, not nullpublic static YearWeek now(java.time.Clock clock)
This will query the specified clock to obtain the current year-week.
Using this method allows the use of an alternate clock for testing.
The alternate clock may be introduced using dependency injection
.
clock
- the clock to use, not nullpublic static YearWeek of(int weekBasedYear, int week)
YearWeek
from a week-based-year and week.
If the week is 53 and the year does not have 53 weeks, week one of the following year is selected.
weekBasedYear
- the week-based-year to represent, from MIN_YEAR to MAX_YEARweek
- the week-of-week-based-year to represent, from 1 to 53java.time.DateTimeException
- if either field is invalidpublic static YearWeek from(java.time.temporal.TemporalAccessor temporal)
YearWeek
from a temporal object.
This obtains a year-week based on the specified temporal.
A TemporalAccessor
represents an arbitrary set of date and time information,
which this factory converts to an instance of YearWeek
.
The conversion extracts the WEEK_BASED_YEAR
and
WEEK_OF_WEEK_BASED_YEAR
fields.
The extraction is only permitted if the temporal object has an ISO
chronology, or can be converted to a LocalDate
.
This method matches the signature of the functional interface TemporalQuery
allowing it to be used in queries via method reference, YearWeek::from
.
temporal
- the temporal object to convert, not nulljava.time.DateTimeException
- if unable to convert to a YearWeek
public static YearWeek parse(java.lang.CharSequence text)
YearWeek
from a text string such as 2007-W13
.
The string must represent a valid year-week.
Week 53 will be adjusted to week 1 of the following year if necessary.
The format must be YYYY-'W'ww
.
Years outside the range 0000 to 9999 must be prefixed by the plus or minus symbol.
text
- the text to parse such as "2007-W13", not nulljava.time.format.DateTimeParseException
- if the text cannot be parsedpublic static YearWeek parse(java.lang.CharSequence text, java.time.format.DateTimeFormatter formatter)
YearWeek
from a text string using a specific formatter.
The text is parsed using the formatter, returning a year-week.
text
- the text to parse, not nullformatter
- the formatter to use, not nulljava.time.format.DateTimeParseException
- if the text cannot be parsedpublic boolean isSupported(java.time.temporal.TemporalField field)
This checks if this year-week can be queried for the specified field.
If false, then calling the range
and
get
methods will throw an exception.
If the field is a ChronoField
then the query is implemented here.
The supported fields are:
WEEK_OF_WEEK_BASED_YEAR
WEEK_BASED_YEAR
ChronoField
instances will return false.
If the field is not a ChronoField
, then the result of this method
is obtained by invoking TemporalField.isSupportedBy(TemporalAccessor)
passing this
as the argument.
Whether the field is supported is determined by the field.
isSupported
in interface java.time.temporal.TemporalAccessor
field
- the field to check, null returns falsepublic java.time.temporal.ValueRange range(java.time.temporal.TemporalField field)
The range object expresses the minimum and maximum valid values for a field. This year-week is used to enhance the accuracy of the returned range. If it is not possible to return the range, because the field is not supported or for some other reason, an exception is thrown.
The range for the WEEK_BASED_YEAR
and
WEEK_OF_WEEK_BASED_YEAR
fields is returned.
All ChronoField
instances will throw an UnsupportedTemporalTypeException
.
range
in interface java.time.temporal.TemporalAccessor
field
- the field to query the range for, not nulljava.time.DateTimeException
- if the range for the field cannot be obtainedjava.time.temporal.UnsupportedTemporalTypeException
- if the field is not supportedpublic int get(java.time.temporal.TemporalField field)
int
.
This queries this year-week for the value for the specified field. The returned value will always be within the valid range of values for the field. If it is not possible to return the value, because the field is not supported or for some other reason, an exception is thrown.
The value for the WEEK_BASED_YEAR
and
WEEK_OF_WEEK_BASED_YEAR
fields is returned.
All ChronoField
instances will throw an UnsupportedTemporalTypeException
.
get
in interface java.time.temporal.TemporalAccessor
field
- the field to get, not nulljava.time.DateTimeException
- if a value for the field cannot be obtained or
the value is outside the range of valid values for the fieldjava.time.temporal.UnsupportedTemporalTypeException
- if the field is not supported or
the range of values exceeds an int
java.lang.ArithmeticException
- if numeric overflow occurspublic long getLong(java.time.temporal.TemporalField field)
long
.
This queries this year-week for the value for the specified field. If it is not possible to return the value, because the field is not supported or for some other reason, an exception is thrown.
The value for the WEEK_BASED_YEAR
and
WEEK_OF_WEEK_BASED_YEAR
fields is returned.
All ChronoField
instances will throw an UnsupportedTemporalTypeException
.
getLong
in interface java.time.temporal.TemporalAccessor
field
- the field to get, not nulljava.time.DateTimeException
- if a value for the field cannot be obtainedjava.time.temporal.UnsupportedTemporalTypeException
- if the field is not supportedjava.lang.ArithmeticException
- if numeric overflow occurspublic int getYear()
This method returns the primitive int
value for the week-based-year.
Note that the ISO week-based-year does not align with the standard Gregorian/ISO calendar year.
public int getWeek()
This method returns the primitive int
value for the week of the week-based-year.
public boolean is53WeekYear()
This determines if the year has 53 weeks, returning true. If false, the year has 52 weeks.
public int lengthOfYear()
This returns the length of the year in days, either 364 or 371.
public YearWeek withYear(int weekBasedYear)
YearWeek
with the week-based-year altered.
This returns a year-week with the specified week-based-year. If the week of this instance is 53 and the new year does not have 53 weeks, the week will be adjusted to be 52.
This instance is immutable and unaffected by this method call.
weekBasedYear
- the week-based-year to set in the returned year-weekYearWeek
based on this year-week with the requested year, not nulljava.time.DateTimeException
- if the week-based-year value is invalidpublic YearWeek withWeek(int week)
YearWeek
with the week altered.
This returns a year-week with the specified week-of-week-based-year. If the new week is 53 and the year does not have 53 weeks, week one of the following year is selected.
This instance is immutable and unaffected by this method call.
week
- the week-of-week-based-year to set in the returned year-weekYearWeek
based on this year-week with the requested week, not nulljava.time.DateTimeException
- if the week-of-week-based-year value is invalidpublic YearWeek plusYears(long yearsToAdd)
If the week of this instance is 53 and the new year does not have 53 weeks, the week will be adjusted to be 52.
This instance is immutable and unaffected by this method call.
yearsToAdd
- the years to add, may be negativepublic YearWeek plusWeeks(long weeksToAdd)
This instance is immutable and unaffected by this method call.
weeksToAdd
- the weeks to add, may be negativepublic YearWeek minusYears(long yearsToSubtract)
If the week of this instance is 53 and the new year does not have 53 weeks, the week will be adjusted to be 52.
This instance is immutable and unaffected by this method call.
yearsToSubtract
- the years to subtract, may be negativepublic YearWeek minusWeeks(long weeksToSubtract)
This instance is immutable and unaffected by this method call.
weeksToSubtract
- the weeks to subtract, may be negativepublic <R> R query(java.time.temporal.TemporalQuery<R> query)
This queries this year-week using the specified query strategy object.
The TemporalQuery
object defines the logic to be used to
obtain the result. Read the documentation of the query to understand
what the result of this method will be.
The result of this method is obtained by invoking the
TemporalQuery.queryFrom(TemporalAccessor)
method on the
specified query passing this
as the argument.
query
in interface java.time.temporal.TemporalAccessor
R
- the type of the resultquery
- the query to invoke, not nulljava.time.DateTimeException
- if unable to query (defined by the query)java.lang.ArithmeticException
- if numeric overflow occurs (defined by the query)public java.time.temporal.Temporal adjustInto(java.time.temporal.Temporal temporal)
This returns a temporal object of the same observable type as the input with the week-based-year and week changed to be the same as this.
The adjustment is equivalent to using Temporal.with(TemporalField, long)
twice, passing IsoFields.WEEK_BASED_YEAR
and
IsoFields.WEEK_OF_WEEK_BASED_YEAR
as the fields.
If the specified temporal object does not use the ISO calendar system then
a DateTimeException
is thrown.
In most cases, it is clearer to reverse the calling pattern by using
Temporal.with(TemporalAdjuster)
:
// these two lines are equivalent, but the second approach is recommended temporal = thisYearWeek.adjustInto(temporal); temporal = temporal.with(thisYearWeek);
This instance is immutable and unaffected by this method call.
adjustInto
in interface java.time.temporal.TemporalAdjuster
temporal
- the target object to be adjusted, not nulljava.time.DateTimeException
- if unable to make the adjustmentjava.lang.ArithmeticException
- if numeric overflow occurspublic java.lang.String format(java.time.format.DateTimeFormatter formatter)
This year-week will be passed to the formatter to produce a string.
formatter
- the formatter to use, not nulljava.time.DateTimeException
- if an error occurs during printingpublic java.time.LocalDate atDay(java.time.DayOfWeek dayOfWeek)
LocalDate
.
This returns a LocalDate
formed from this year-week and the specified day-of-Week.
This method can be used as part of a chain to produce a date:
LocalDate date = yearWeek.atDay(MONDAY);
dayOfWeek
- the day-of-week to use, not nullpublic int compareTo(YearWeek other)
The comparison is based first on the value of the year, then on the value of the week.
It is "consistent with equals", as defined by Comparable
.
compareTo
in interface java.lang.Comparable<YearWeek>
other
- the other year-week to compare to, not nullpublic boolean isAfter(YearWeek other)
other
- the other year-week to compare to, not nullpublic boolean isBefore(YearWeek other)
other
- the other year-week to compare to, not nullpublic boolean equals(java.lang.Object obj)
equals
in class java.lang.Object
obj
- the object to check, null returns falsepublic int hashCode()
hashCode
in class java.lang.Object
public java.lang.String toString()
String
, such as 2015-W13
.
The output will be in the format YYYY-'W'ww
:
toString
in class java.lang.Object
Copyright © 2010–2018 ThreeTen.org. All rights reserved.