OpenLLM-France/wikimedia huggingface dataset:
# Canadian Refugee Procedure/168 - Abandonment of proceeding
## IRPA Section 168

The legislative provision reads:

## Commentary

For a discussion of abandonment, see the commentary under RPD Rule 65: Canadian Refugee Procedure/RPD Rule 65 - Abandonment. For a discussion of withdrawal, see the commentary under RPD Rule 59: Canadian Refugee Procedure/RPD Rule 59 - Withdrawal.
For the RAD, see RAD Rule 68: Canadian Refugee Procedure/RAD Rules Part 4 - Rules Applicable to an Appeal for Which a Hearing Is Held#RAD Rule 68 - Abandonment.
# C++ Programming/Code/Standard C Library/Functions/toupper
#### toupper

| Syntax | #include <cctype> int toupper( int ch ); |
The toupper function returns the uppercase version of the character ch.

##### Related topics

    tolower
# C++ Programming/Code/Standard C Library/Functions/vscanf, vfscanf, and vsscanf
## vscanf, vfscanf, and vsscanf

| Syntax | #include <cstdarg> #include <cstdio> int vscanf( const char *format, va_list arg_ptr ); int vfscanf( FILE *stream, const char *format, va_list arg_ptr ); int vsscanf( const char *buffer, const char *format, va_list arg_ptr ); |
These functions are very much like scanf, fscanf, and sscanf. The difference is that the argument list is a pointer to a list of arguments. va_list is defined in cstdarg, and is also used by (Other Standard C Functions) va_arg.
For example:
# C++ Programming/Code/Standard C Library/Functions/vprintf, vfprintf, and vsprintf
## vprintf, vfprintf, and vsprintf

| Syntax | #include <cstdarg> #include <cstdio> int vprintf( char *format, va_list arg_ptr ); int vfprintf( FILE *stream, const char *format, va_list arg_ptr ); int vsprintf( char *buffer, char *format, va_list arg_ptr ); |
These functions are very much like printf, fprintf, and sprintf. The difference is that the argument list is a pointer to a list of arguments. va_list is defined in cstdarg, and is also used by (Other Standard C Functions) va_arg.
For example:
# C++ Programming/Code/Standard C Library/Memory
## Standard C Memory Management

This section covers memory management elements from the Standard C Library.

## calloc

| Syntax | #include <cstdlib> void *calloc( size_t num, size_t size); |
The function calloc allocates a block of memory that can store an array of num cells, each with a size size. Every cell of the array is set to value zero.
If the operation fails, calloc returns "NULL".
EXAMPLE:

### Related topics

    free - malloc - realloc

## free

| Syntax | #include <cstdlib> void free( void *p); |
The function free releases a previously allocated block from a call to calloc, malloc, or realloc.

### Related topics

    calloc - malloc - realloc

## malloc

| Syntax | #include <cstdlib> void *malloc( size_t s ); |
The function malloc allocates a block of memory of size s. The memory remains uninitialized.
If the operation fails, malloc returns NULL.

### Related topics

    calloc - free - realloc

## realloc

| Syntax | #include <cstdlib> void *realloc( void *p, size_t s); |
The function realloc resizes a block created by malloc or calloc, and returns a pointer to the new memory region.
If the resize operation fails, realloc returns NULL and leaves the old memory region intact.

### Related topics

    calloc - free - malloc
# C++ Programming/Code/Standard C Library/Functions/ungetc
#### ungetc

| Syntax | #include <cstdio> int ungetc( int ch, FILE *stream ); |
The function ungetc puts the character ch back in stream.

##### Related topics

    getc (C++ I/O) putback
# C++ Programming/Code/Standard C Library/Functions/va arg
#### va_arg

| Syntax | #include <cstdarg> type va_arg( va_list argptr, type ); void va_end( va_list argptr ); void va_start( va_list argptr, last_parm ); |
The va_arg macros are used to pass a variable number of arguments to a function.
* First, you must have a call to va_start passing a valid va_list and the name of the last argument variable before the ellipsis ("..."). This first argument can be anything; one way to use it is to have it be an integer describing the number of parameters being passed.
* Next, you call va_arg passing the va_list and the type of the argument to be returned. The return value of va_arg is the current parameter.
* Repeat calls to va_arg for however many arguments you have.
* Finally, a call to va_end passing the va_list is necessary for proper cleanup.
This code displays 10, which is 4+3+2+1.
Here is another example of variable argument function, which is a simple printing function:
This code displays the following output when run:
# Development Cooperation Handbook/Designing and Executing Projects/Project Execution and Control/Manage CSSQ

Manage CSSQ (Cost, Scope, Schedule, and Quality)
CSSQ is the acronym for a project’s inextricably linked quadruple constraints: Cost, Scope, Schedule, and Quality. Its purpose is to to ensure that the project outputs are delivered with the expected quality in the time and cost limits defined in the project plan document.
See also The project triangle: seeing projects in terms of time, cost, and scope
CSSQ will need to be managed according to the processes established during Project Planning. The CSSQ is not static – although Project Planning is complete and has been approved, some components of CSSQ will continue to evolve as a result of the execution of project tasks. Throughout Execution and Control, as more information about the project becomes known and the product of the project is developed, CSSQ is likely to be affected and will need to be closely managed.
The purpose of Manage CSSQ is to:
* Manage Changes to Project Scope
* Control the schedule and mange schedule changes
* Implement Quality Assurance and Quality Control processes according to the Quality Standards Revised During Project Planning
* Control and Manage Costs established in the Project Budget
The CSSQ Deliverables – the Project Budget, Project Scope, Project Schedule, and the Quality Management Plan are applied, monitored and updated during Project Execution and Control.
Templates:
Project Issues Log Template
Project Change Request Template
Status Report
Project Progress Report
Evaluation Report Closure Report
Guidelines
Guideline: Focusing the evaluation design Guidelines: How to conduct a useful M&E action
# Development Cooperation Handbook/Designing and Executing Projects/Project Execution and Control/Manage Changes to Project Scope

Scope verification: Manage Changes to Project Scope
(technical definition "scope": the combination of all project goals and tasks, and the work required to accomplish them; the scope translates into the timeline and budget).
Manage Project Scope During Project Planning, the Project Manager, through regular communication with the Representatives of the beneficiaries and Project Sponsor, refined the Project Scope to clearly define the content of the deliverables to be produced. It is good if the process to be used to document changes to the Project Scope is included in the Project Plan. Otherwise it has to be defined during the implementation stage. Even if a scope change is perceived to be very small, exercising the change process ensures that all parties agree to the change and understand its potential impact. Following the process each and every time scope change occurs will minimize confusion as to what actually constitutes a change. Additionally, instituting the process early will test its effectiveness, get the Beneficiaries and Project Sponsor accustomed to the way change will be managed throughout the remainder of the project, and help them understand their roles as they relate to change.
Any deviation to what appears in the scope document is considered change and must be handled using the change control process.
Sometimes, despite the best effort of the Project Manager to carefully document what is in and outside of scope, there is disagreement between the Project Manager and Beneficiaries Representative or Project Sponsor regarding whether something is a change. When conflicts occur, the Project Manager and appropriate beneficiaries must be willing to discuss their differences of opinion and reach a compromise. If a compromise cannot be reached, it may be necessary to escalate the issue to a higher level of management. Once the Project Manager, the Project Sponsor, and the appropriate Beneficiary Representative agree that scope change is occurring, they all must take the time to thoroughly evaluate the change. In order to effectively evaluate change, the Project Manager must forecast the impact of the change on the remaining three “quadruple constraints”: Cost, Schedule and Quality. Equipped with this information, the Project Manager and Project Sponsor will be able to determine if implementing the proposed change would be beneficial.
The Project Manager must incorporate any agreed-upon changes or addenda into the deliverables produced during Project Initiation and Project Planning. This ensures that all project deliverables are in line with the revised Project Scope. Any lessons learned from scope change control should be documented and included in the project repository for later use by the current project and any other projects to be performed by the organization.
Throughout Project Execution and Control, continuous communication between the Project Manager, Project Sponsor, and Beneficiary Representative is crucial in managing scope.
Template: Project Issues Log Template; Project Change Request
# Development Cooperation Handbook/Designing and Executing Projects/Project Execution and Control/Manage Acceptance of Deliverables

The goal of this task is to manage the acceptance by beneficiaries of the outputs (producs and services) delivered by the project. This implies the verification that in fact project outputs comply with the output quality specifications defined during the project planning fase. If these specifications were wrong, i.e. if during the planning the beneficiaries requirements were not properly analysed, managing the acceptance of deliverables become impossible and the project will fail to achieve its objectives.
The expected project outcomes are beyond the direct reach of the project activities performed by the project team and will be reached by the usage of project final outputs by project beneficiaries and other project stakeholders.
However an important part of project implementation is managing the acceptance of project final outputs so as to facilitate beneficiaries and other stakeholders to avail of project results and be empowered for easier solution of the identified problems (thereby for achieving the project results)
In the methodology section of the Project Plan Document there can be a sub-section dealing with the management of the acceptance process. If not it would be a good idea to agree on this procedure at a early phase of project execution. When then the issues happen there is already an establish and agreed pattern of how to cope with the issues. The acceptance management process plan documents:
* The definition of “acceptance”
* The criteria that must be met for each deliverable to be considered “acceptable”
* The number and identity of experts designated to be reviewers of each deliverable.
* The number and identity of other stakeholders designated to be approvers – approvers have the authority to sign the approval form, indicating acceptance.
* The number of work days in which deliverables must be either approved or rejected by the reviewers and approvers
* The number of times a deliverable can be resubmitted
* The escalation process that will be followed if a timely decision on approval or rejection of a deliverable is not met.
The acceptance management process must be followed throughout the project. As with the Change Control Process, the earlier in the life of the project the process begins, the sooner everyone will understand how it works and what to expect. The key to facilitating acceptance is first to understand Customer expectations, and then to meet them.
REMEMBER: Make a copy of the new baseline schedule and archive it in the project repository BEFORE you book new work to it! If you lose the baseline, you have nothing against which to compare later updates to see if your project is on track!
Acceptance begins when the Project Manager presents a completed deliverable and Project Deliverable Approval Form to the approver.

### Templates

* Deliverable Management Process Plan
* Project deliverable approval form.
# Development Cooperation Handbook/Designing and Executing Projects/Project Execution and Control/Control the Project Schedule and Manage Schedule Changes

During Project Planning, an agreed-upon baseline was established for the Project Schedule (sometimes called "action plan"). This baseline will be used as a starting point against which performance on the project will be measured. It is one of many tools the Project Manager can use during Project Execution and Control to determine if the project is on track. Project Team members must use the communications mechanisms documented in the communications plan to provide feedback to the Project Manager on their progress. It is recommended that each team member prepare a project report.
Progress Reports are used by the Project Manager to update the Project Schedule.
Is the project on track?
* Are there any issues that are becoming evident that need to be addressed now?
* Which tasks are taking more time than estimated? Less time?
* If a task is late, what is the effect on subsequent tasks?
* What is the next deliverable to be produced and when is it scheduled to be complete?
* What is the amount of effort expended so far and how much is remaining?
* Are any Project Team members over-allocated or underallocated?
* How much of the time allocated has been expended to date and what is the time required to complete the project?
When updating the Project Schedule, it is very important that the Project Manager maintain the integrity of the current schedule. Each version of the schedule should be archived. By creating a new copy of the schedule whenever it is updated, the Project Manager will never lose the running history of the project and will also have a copy of every schedule for audit purposes.
The Project Manager should begin tracking actual work in the Project Schedule as soon as the work commences, which is usually as soon as the project is initiated and Project Planning begins. Remember that updates to the Project Schedule are not limited to tracking hours worked – ANY change resulting from the execution of the change control process will usually require future tasks to be re-planned and the schedule to be updated!
If the Project Schedule is updated to reflect approved change control, a new baseline schedule must also be created. Updates must then be made against the new baseline. The previous baseline should be saved for historical purposes.
The process of managing changes to the project shedule be properly integrated with reporting of project performance, i.e the most important feature of project communication management
# Development Cooperation Handbook/Designing and Executing Projects/Project Execution and Control/Gain Project Acceptance

Gain Project Acceptance
The purpose of Gain Project Acceptance is to formally acknowledge that all deliverables produced during Project Execution and Control have been completed, tested, accepted, and approved by the project’s Beneficiaries and the Project Sponsor, and that the product or service the project developed was successfully transitioned from the Project Team to the Performing Organization. Formal acceptance and approval also signify that the project is essentially over, and is ready for Project Closeout

### Conduct Final Status Meeting

Once the product of the project has been successfully transitioned to the Performing Organization, the Project Manager should prepare the final status report and conduct the final status meeting. The Project Schedule must be up to date for all completed project and project management lifecycle phases. This is the final opportunity for all participants to confirm that the product of the project has been successfully developed and transitioned. Any outstanding issues or action items must be transitioned from the Project Team to the Performing Organization.

### Gain Acceptance Signature from Project Sponsor

As the deliverables of the project are produced and accepted, approval signatures are gained from the Project Sponsor and Customer Decision-Makers. Following the final status meeting, the Project Manager must obtain the Project Sponsor’s signature one final time, indicating acceptance of the project to date, and indicating approval to proceed to Project Closeout. If the Project Sponsor does not accept the project, he/she must indicate the specific reason(s) for rejection. The Project Manager is then responsible for resolving the issues and seeking the Project Sponsor’s acceptance again.

### Deliverable

igned Project Acceptance Form – a formal document indicating Project Sponsor acceptance of all project deliverables and approval to proceed to Project Closeout.
# Co-Life/About
## feature

* Real-time interactive
* Real-time Chatting function
* E-Whiteboard
* Shared Documents
* Shared Desktop
* Conferencing controller

## Applications

* Meeting Hall
* Distance Learning
* Meeting Room
* Project Management
* Electrical Study
* Others

## Software Requirements

* OS : Windows 2000/XP/2003
* Browser : IE 6.0 or higher
* JRE 1.5 or higher

## Hardware

* PC or NB (P4 is better)
* Webcam
* Headset

## Contact

* On-line testing:
** AM11:00-12:00 , Wednesday(UTC+8) per week http://colife.nchc.org.tw
* Lulala Jiang(Project Manager) +886-6-5050940#731
# Co-Life/User Guild
## Before using Co-Life

* Start your browser and link to http://colife.nchc.org.tw . Please register first and login.
* Set up your contact list and group.
* After creating your contact list, your can use it.

## How to start a meeting

* Start your browser and link to http://colife.nchc.org.tw . Then input your ID and click submit.

### meeting management

(1) Join exist meeting:
Click Meeting to see the meeting list and click the meeting's name you wan to join. Than you can the see the description of this meeting. If you want to join this one, click Enter.
(2) Create a new meeting
click meeting on the top of this web to link to the calendar of meeting. Choose a date and click new to add a new meeting. (You will be the chairman of this meeting if you create it.)
Enter the information of this meeting and choose members or groups. Then click Add.
After creating a new meeting, you will see your meeting on the meeting list. You can click the name of your meeting to edit or delete it .

### videoconferencing

(1) After pressing Enter, the meeting window pop out. There are attendee list, chatroom and video frame.
(2) click the video and voice button to turn on/off video and voice.
(3) You can see everyone's status on attendee list. The chairman can turn on/off attendee's voice and video.
(4) Chairman can use Mute to silence all microphone to avoid noise or echo.
(5) If you wan to share file to other people, press File, share file. Then choose the file you want to share from your computer. Everyone can receive a message to save it or not.

### Share Desktop

(1) The chairman of this meeting can share her/his desktop (slide show) to every member.
(2) share member's desktop: attendee can choose My Desktop to share it. Chairman can see this desktop on her/his list. After the chairman choose the desktop everyone can see it.

### e-White board

This feature allows the members of the meeting to show something by painting it on an e-White board. Only the chairman has a right to open it. When it is open, every member is free to use it.
# C Programming/assert.h/Function reference
## assert
### Return value

The assert macro returns a void, i.e. no value.

### Notes

The behaviour of the assert macro depends on the value of the NDEBUG macro. See assert.h for more details.
If NDEBUG is defined then the macro assert, regardless of argument, is defined as
If NDEBUG is not defined the assert macro acts as a diagnostic test. If the expression argument of the macro is false (see C Programming/Control), then the macro expands to a statement which writes the text of the argument, the present file name, line number and function name to the standard error stream. Finally the assert macro calls the abort function.
Each time the assert.h header is included the assert macro is redefined depending on the value of NDEBUG.
# C Programming/assert.h

assert.h defines the macro assert. The macro can be used to verify assumptions made by the program and print a diagnostic message if this assumption is false.
When executed, if the expression is false (that is, compares equal to 0), assert writes information about the call that failed on stderr and then calls abort. The information it writes to stderr includes:
* the source filename (the predefined macro __FILE__)
* the source line number (the predefined macro __LINE__)
* the source function (the predefined identifier __func__) (added in C99)
* the text of expression that evaluated to 0
Example output of a program compiled with gcc on Linux:
Programmers can eliminate the assertions without changing the source code: if the macro NDEBUG is defined before the inclusion of <assert.h>, the assert macro is defined simply as:
and therefore has no effect on the program, not even evaluating its argument. Therefore expressions passed to assert must not contain side-effects since they will not happen when debugging is disabled. For instance:
will not read a line and not assign to x when debugging is disabled.

## Macros

* assert

## Functions

The C99 standard requires no functions to be declared in the assert.h header.

## Notes

The definition of the assert macro depends on the state of a macro, NDEBUG, which is not defined in the assert.h header. The macro NDEBUG denotes not using debugging information. If NDEBUG is defined, then assert is defined as an expression which does nothing. Otherwise assert will print debugging information if the expression it tests is false.

## External links

* assert.h: verify program assertion – Base Definitions Reference, The Single UNIX® Specification, Issue 7 from The Open Group
# Cognition and Instruction/Self Regulated Learning (An overview of Self-regulated learning)

What is Self Regulated Learning?
Definition Self-regulated learning is the ability to control
Theories of Self Regulated Learning
Metacognitive awareness
Strategy Use
Motivational Control
What is Metacognition (Metacognition is thinking about your own thinking. It is one of the components of self-regulated learning - Efklides, A (2011) Metacognition has two related dimensions: knowledge of cognition and regulation of cognition)
knowledge of cognition (knowledge of cognition has three components: 1. declarative knowledge about ourselves, 2. procedural knowledge about cognitive strategies 3. conditional knowledge about when or why to use a strategy. (textbook p.79)
regulation of cognition (regulation of cognition has three components: 1. planning 2. regulation 3. Evaluation (textbook p.79)
Development of metacognition (metacognition slowly develops through childhood and continue on to adulthood)
Theories Metacognition theory by John Flavel
Metacognitive awareness
What This Looks Like
Self Observation
Self Evaluation
Strategy Use (there are many strategies one can use to develop self regulated learning. In this section we will review some of the strategies we believe as important)
Planning
Monitoring
Reviewing
Application in a Classroom
Motivational Control ( self regulated learning is a process which the learner must enhance themselves, they need to have willpower)
Autonomy and control
Cultural View Differences