common(7f) - [FORTRAN:INTRINSICS] specifies blocks of variables that can be accessed by any scoping unit in the program
common /common-block-name/ variables, /common-block-name/ variables, ...
The COMMON statement specifies blocks of physical storage, called common blocks, that can be accessed by any of the scoping units in a program. Thus, the COMMON statement provides a global data facility based on storage association (16.5.3).A common block that does not have a name is called blank common.
An EQUIVALENCE statement shall not cause the storage sequences of two different common blocks to be associated.
R568 common-stmt is COMMON [ / [ common-block-name ] / ] common-block-object-list [ [ , ] / [ common-block-name ] / common-block-object-list ] ... R569 common-block-object is variable-name [ ( array-spec ) ] or proc-pointer-name C595 (R569) An array-spec in a common-block-object shall be an explicit-shape-spec-list. C596 (R569) Only one appearance of a given variable-name or proc-pointer-name is permitted in all common-block-object-lists within a scoping unit. C597 (R569) A common-block-object shall not be a dummy argument, an allocatable variable, a derived-type object with an ultimate component that is allocatable, an automatic object, a function name, an entry name, a variable with the BIND attribute, a coarray, or a result name. C598 (R569) If a common-block-object is of a derived type, the type shall have the BIND attribute or the SEQUENCE attribute and it shall have no default initialization. C599 (R569) A variable-name or proc-pointer-name shall not be a name made accessible by use association. In each COMMON statement, the data objects whose names appear in a common block object list following a common block name are declared to be in that common block. If the first common block name is omitted, all data objects whose names appear in the first common block object list are specified to be in blank common. Alternatively, the appearance of two slashes with no common block name between them declares the data objects whose names appear in the common block object list that follows to be in blank common. Any common block name or an omitted common block name for blank common may occur more than once in one or more COMMON statements in a scoping unit. The common block list following each successive appearance of the same common block name in a scoping unit is treated as a continuation of the list for that common block name. Similarly, each blank common block object list in a scoping unit is treated as a continuation of blank common. The form variable-name (array-spec) specifies the DIMENSION attribute for that variable. If derived-type objects of numeric sequence type (4.5.2) or character sequence type (4.5.2) appear in common, it is as if the individual components were enumerated directly in the common list. NOTE 5.44 Examples of COMMON statements are:COMMON /BLOCKA/ A, B, D (10, 30) COMMON I, J, K
<IP_ADDRESS> Common block storage sequence For each common block in a scoping unit, a common block storage sequence is formed as follows: (1) A storage sequence is formed consisting of the sequence of storage units in the storage sequences (<IP_ADDRESS>) of all data objects in the common block object lists for the common block. The order of the storage sequences is the same as the order of the appearance of the common block object lists in the scoping unit. (2) The storage sequence formed in (1) is extended to include all storage units of any storage sequence associated with it by equivalence association. The sequence shall be extended only by adding storage units beyond the last storage unit. Data objects associated with an entity in a common block are considered to be in that common block.Only COMMON statements and EQUIVALENCE statements appearing in the scoping unit contribute to common block storage sequences formed in that scoping unit.
<IP_ADDRESS> Size of a common block The size of a common block is the size of its common block storage sequence, including any extensions of the sequence resulting from equivalence association. <IP_ADDRESS> Common association Within a program, the common block storage sequences of all nonzero-sized common blocks with the same name have the same first storage unit, and the common block storage sequences of all zero-sized common blocks with the same name are storage associated with one another. Within a program, the common block storage sequences of all nonzero-sized blank common blocks have the same first storage unit and the storage sequences of all zero-sized blank common blocks are associated with one another and with the first storage unit of any nonzero-sized blank common blocks. This results in the association of objects in different scoping units. Use or host association may cause these associated objects to be accessible in the same scoping unit. A nonpointer object that is default integer, default real, double precision real, default complex, default logical, or of numeric sequence type shall be associated only with nonpointer objects of these types and kinds. A nonpointer object that is default character or of character sequence type shall be associated only with nonpointer objects of these types and kinds. A nonpointer object of a derived type that is not a numeric sequence or character sequence type shall be associated only with nonpointer objects of the same type with the same type parameter values. A nonpointer object of intrinsic type but which is not default integer, default real, double precision real, default complex, default logical, or default character shall be associated only with nonpointer objects of the same type and type parameters. A data pointer shall be storage associated only with data pointers of the same type and rank. Data pointers that are storage associated shall have deferred the same type parameters; corresponding nondeferred type parameters shall have the same value. A procedure pointer shall be storage associated only with another procedure pointer; either both interfaces shall be explicit or both interfaces shall be implicit. If the interfaces are explicit, the characteristics shall be the same. If the interfaces are implicit, either both shall be subroutines or both shall be functions with the same type and type parameters. An object with the TARGET attribute shall be storage associated only with another object that has the TARGET attribute and the same type and type parameters. NOTE 5.45 A common block is permitted to contain sequences of different storage units, provided each scoping unit that accesses the common block specifies an identical sequence of storage units for the common block. For example, this allows a single common block to contain both numeric and character storage units.Association in different scoping units between objects of default type, objects of double precision real type, and sequence structures is permitted according to the rules for equivalence objects (5.7.1).
<IP_ADDRESS> Differences between named common and blank common A blank common block has the same properties as a named common block, except for the following. undefined unless the common block has the SAVE attribute, but never causes data objects in blank common to become undefined (16.6.6). they appear, but blank common blocks may be of different sizes. declaration statement in a block data program unit (11.3), but objects in blank common shall not be initially defined.
5.7.3 Restrictions on common and equivalence Equivalence association shall not cause a derived-type object with default initialization to be associated with an object in a common block.
Equivalence association shall not cause a common block storage sequence to be extended by adding storage units preceding the first storage unit of the first object specified in a COMMON statement for the common block.
NOTE 5.46 For example, the following is not permitted:COMMON /X/ A REAL B (2) EQUIVALENCE (A, B(2)) ! Not standard-conforming
| Nemo Release 3.1 | common (7) | July 22, 2023 |


Sign up username * Username is required Username must be at least 3 characters Username must be at most 20 characters First name * Last name * fname is required fname must be at least 3 characters fname must be at most 20 characters Email * We'll never share your email with anyone else. Email is required Email must be a valid email address Image Create password * Repeat password * Password is required Password must be at least 6 characters Sign Up I am agree with terms and contitions


Delivery Service Details:
{{request.serviceProvider.journeyDate}}-{{request.currentCity}}-{{request.deliveryCity}}
Parcel Description :
Parcel Dimensions :
Pick up location :
Delivery location :
Personal Details :
Sender Address :
Personal Details :
Receiver Address :


@since
tag in its documentation. This may be useful because
language level can differ from your project SDK and it is possible that there is no such API in JDK, on
which the code will be run.
Use the radio buttons below to forbid API usages respecting to project language level settings or custom language level.


|
NetBeans UML Modeling |
AbstractHandler org::galagosearch::core::tools::SearchWebHandler
public class SearchWebHandler
Handles web search requests against a Galago index. Also handles XML requests for documents, snippets and search results.
This class is set up to work with an embedded Jetty instance, but it should be fairly easy to wrap into a Servlet for use with something else (Tomcat, Glassfish, etc.)
URLs supported:
| / | Main Page |
| /search | HTML Search Results (q, start, n) |
| /xmlsearch | XML Search Results (q, start, n) |
| /snippet | XML Snippet Result (identifier, term+) |
| /document | Document Result (identifier) |
| Properties | |
|---|---|
| Alias | SearchWebHandler |
| Visibility | public |
| Final | |
| Transient | |
| Abstract | |
| Leaf |
| Constructor Summary | |
|---|---|
SearchWebHandler(Search search)   |
| Operation Summary | |
|---|---|
String |
getEscapedString(String text)   |
void |
handleDocument(HttpServletRequest request, HttpServletResponse response)   |
void |
handleSnippet(HttpServletRequest request, HttpServletResponse response)   |
String |
scrub(String s)   |
void |
retrieveImage(OutputStream output)   |
void |
handleImage(HttpServletRequest request, HttpServletResponse response)   |
void |
handleSearch(HttpServletRequest request, HttpServletResponse response)   |
void |
handleSearchXML(HttpServletRequest request, HttpServletResponse response)   |
void |
writeStyle(PrintWriter writer)   |
void |
handleMainPage(HttpServletRequest request, HttpServletResponse response)   |
void |
handle(String target, HttpServletRequest request, HttpServletResponse response, int dispatch)   |
SearchResult |
performSearch(HttpServletRequest request)   |
| Constructor Detail |
|---|
public SearchWebHandler(Search search)
| Operation Detail |
|---|
public String getEscapedString(String text)
public void handleDocument(HttpServletRequest request, HttpServletResponse response)
public void handleSnippet(HttpServletRequest request, HttpServletResponse response)
private String scrub(String s)
public void retrieveImage(OutputStream output)
public void handleImage(HttpServletRequest request, HttpServletResponse response)
public void handleSearch(HttpServletRequest request, HttpServletResponse response)
public void handleSearchXML(HttpServletRequest request, HttpServletResponse response)
public void writeStyle(PrintWriter writer)
public void handleMainPage(HttpServletRequest request, HttpServletResponse response)
public void handle(String target, HttpServletRequest request, HttpServletResponse response, int dispatch)
private SearchResult performSearch(HttpServletRequest request)
|
NetBeans UML Modeling |


This is a specification page for an obsolete version of Bandicoot - v4. For the current version please go to the Bandicoot specification site.
Here are the keywords which are currently in use:
| extend | fn | int | long |
| project | real | rel | rename |
| return | select | string | summary |
A program is defined in a single source file. The file is evaluated from top to bottom in one pass (similar to the C language). The top-level elements of the program can be of the following types:
The convention for Bandicoot source file extension is ".b".
Primitive types are scalar types used for attributes, input and output parameters for functions. There are four types available:
| Type | Size | Description |
|---|---|---|
| int | 32-bit | signed integer |
| long | 64-bit | signed integer |
| real | 64-bit | IEEE 754 double precision |
| string | 0-1024 bytes | UTF-8 encoded string |
The primitive types are referenced within this specification as PrimitiveType.
Here is the regular expression defining an identifier: "[_a-zA-Z0-9]+". Maximum identifier length is 32 characters. Below you will find the following references to the identifiers:
There are two ways to declare a relational type: named and inline. Named declarations give an identifier to some particular type so that it can be referenced in the code later. Inline (or anonymous) declarations are useful when the type is used only once (e.g. as an input or output function parameter).
Named type can be declared in the following way:
rel TypeName { AttrName : PrimitiveType [,] [more attributes] }
and inline type:
rel { AttrName : PrimitiveType [,] [more attributes] }
The relational types (both inline and names) are referenced within this specification as RelType.
Relational variables are used for keeping the program state. The system provides two types of variables:
Here is how you can declare a global variable named VarName.
VarName : RelType ;
The relational variables are referenced within this specification as RelVar.
Functions are identified by names which must be unique across the whole program source file. A function can make complex state transformations on top of the global variables (see Transactions section).
fn FuncName ( [ParamName : RelType] ) [: RelType] { FuncBody }
Function body (FuncBody) is a list of statements evaluated from top to bottom. The list is separated with the semicolons (";"). Statements can be of three types:
VarName = RelExpr ;
VarName := RelExpr ;
return RelExpr ;
A function cannot call another function. Also, only one assignment per global relational variable is possible within a function body. After the assignment the global variable cannot be accessed anymore (within the same function). This is a temporary limitation and you can workaround it with the help of temporary variables.
Relational expressions (RelExpr) are the main building blocks of your programs. These expressions are composed by applying relational operators to relational variables (global or local). The minimum relational expression is an identifier which references a relational variable (e.g. books).
RelExpr rename ( ToAttrName = FromAttrName [,] [more attributes] )
RelExpr project ( AttrName [,] [more attributes] )
RelExpr extend ( AttrName = PrimitiveExpr [,] [more attributes] )
RelExpr select ( BooleanExpr )
RelExpr + RelExpr
RelExpr - RelExpr
RelExpr * RelExpr
Unary version:
RelExpr summary ( AttrName = SumFunc [,] [more attributes] )
Binary version:
( RelExpr , RelExpr ) summary ( AttrName = SumFunc [,] [more attributes] )
The are several pre-defined summary functions (SumFunc) available in the system:
add ( AttrName , DefVal )
avg ( AttrName , DefVal )
cnt ( )
max ( AttrName , DefVal )
min ( AttrName , DefVal )
Where DefVal is a constant expression. The type of the expression should match the type of the result and attribute. The exception is the avg function where the default value and result are always real numbers. DefVal is used in those cases when the RelExpr body is empty. In case of the binary summary this can happen when there is no matching tuple in left RelExpr for a tuple in the right RelExpr.
Each invocation of a function implicitly creates a transaction. All the statements within a function are part of the same transaction. There are no explicit keywords to commit or rollback a transaction. If there is an error the rollback is performed automatically and an error code is returned to the client.
Modification of a global variable is not allowed by two transactions at the same time. Therefore two functions which modify the same variable are serialized and executed one after the other. Read-only functions are executed in parallel with other read/write functions.
The level of isolation is always serializable and it means that if a read of the same variable occurs several times within a function it always returns the same data even if the variable is modified by a different function at the same time.
The Bandicoot API is based on the HTTP/1.1 protocol. The interface exposes all the functions defined in a program source file through http://server:port/FuncName URLs. The HTTP POST method must be used to invoke a function with an input parameter. Otherwise the HTTP GET is required.
Both input and output parameters are exchanged in "comma separated values" format. The tuples are delimited with the "\n" end-of-line character. The first line is a relational head definition in the following format:
AttrName:PrimitiveType[,][more attributes]
The comma or the end-of-line character can be escaped by using "\" character. It means the Bandicoot will not represent those characters and they will be treated as part of your data.


Click on Try it to Run Detection on Road Traffic.
Click on Try it to Run Detection on Office Desk .
Click on Try it to Run Detection on Play Ground .


{{quote.name}} - {{quote.completeDate|date|uppercase}}
10'>Quotes are limited to 10, please delete old quotes!


$9.99
- Choice of 2 varieties
- Delivered monthly
- Fresh baked
Creating delightful treats for all to enjoy!
We have been serving Raleigh, North Carolina for more than 50 years. Our Cookies Are made from generations old family recipes featuring the most natural and freshest ingredients. Our recipes are made with the highest quality chocolate chips from cocoa beans in Ghana, juicy California raisins, pure Madagascar bourbon vanilla, the finest brown sugar, Saigon cinnamon, and exotic macadamia nuts imported from South America. The popularity of our Treats is so great we decided to offer a monthly cookie club delivered directly to your door.


A web developer and technology professional.
const KennethPrettman = (design, create, build) => {return results};
Find what's on special at restaurants and bars near you all in one simple search.
Get the full picture of your shopping experience by comparing an online retailer with a brick and mortar store. Includes map and aproximate drive time plus prices.


Skin Check
Welcome,
Tiva
EN
|
IN
REGISTER ACCOUNT
Fullname
Date of birth
Male
Female
Gender
Indonesia
Country
Jakarta
City
Phone Number
Email Address
Password
Confirm Password
REGISTER
Already a member?
Login Now


Read the instructions common to all tasks on the notes page - these are part of the description of this task.
The aim for the remaining time of the module is to build either a library or an application for the LaFortuna. This coursework is spread over two tasks, each of which is worth 4 marks: Designing and implementing your library or application (T7) and Refining and Documenting your library or application (T8).
You can choose freely what you would like to implement - take into account, however, how much time you have available next to your other obligations.
If you do not have an idea what to build already, maybe one of the following suggestions can help:
One challenge for your application idea may be is the user interface of the LaFortuna. Take a look at how the RockBox plugins have tackled this issue for a similar interface of an MP3 player. The list of pluigins may serve as further inspiration for projects.
Extra work, but no extra credit... only for very advanced students:
This the best project in the category "Embedded Library" and the best project in the category "Embedded Application" will be selected by a jury. All completed projects will be considered for this recognition and all very good projects will be considered for the five extra marks reserved for exceptional contributions to the module.


aweave - Tools for asciidoc literate programming
The aweave program is a literate programming tool for asciidoc documents. Aweave copies file to outfile or the standard output adding cross reference and indexing directives to the output corresponding to the definitions and references contained in the literate programming chunks. File is assumed to be asciidoc source containing source blocks that in turn contain chunk definitions and references. The generated output contains a section after each source block that contains a chunk describing which chunks are defined and which are referenced. Index entries for each chunk definition are also inserted into the output. In keeping with most language agnostic literate programming tools, no pretty printing of the source is performed.
In asciidoc, the markup for source code is signified by enclosing it with lines of four or more hyphens. For example,
---- proc myproc {a b} { chan puts "$a $b" } ----
So literate programming in asciidoc is somewhat different than other literate programming environments in that the literate program source is a valid asciidoc document that can be formatted on its own. The only addition is that of chunk defintions contained in otherwise normal source code markup.
Aweave looks for asciidoc source blocks that contain chunk definitions. A chunk is a name enclosed in "<<" and ">>" markers. There are both chunk definitions and chunk references. A chunk definition appends an equals sign (=) to the chunk marker. A chunk reference does not. For example,
---- <<utility procs>>= proc ut1 {b} { return [string toupper $b] } <<common procs>> ----
In this example, <<utility procs>>=, is a chunk definition and <<common procs>> is a chunk reference.
There may be multiple definitions of the same chunk. In that case, the definitions are concatenated together in the order in which they occur in the file.
Copyright © 2013 by G. Andrew Mangogna


Kremlin publishes law revoking protocol additional to 1949 Geneva Conventions
The Kremlin claims the risk of the abuse of the Commission's powers for political purposes by unscrupulous states has increased considerably.
The Kremlin has published the Federal Law on the revocation of the declaration made during the ratification of the Protocol Additional to the Geneva Conventions of August 12, 1949, and Relating to the Protection of Victims of International Armed Conflicts (Protocol I), adopted in Geneva on June 8, 1977.
"The [International Fact-Finding] Commission has not actually performed its functions since 1991. It does not include a Russian representative, while Russia continues to make annual contributions to the budget of the Commission," according to the document, which was signed by Russian President Vladimir Putin on November 12, 2019.
"In addition, the risk of the abuse of the Commission's powers for political purposes by unscrupulous states has increased considerably," reads the document.


| Up | TOC | Index | |||||
| << 5 Formal Syntax | < 6.3 Shrouding and Binding | Up: 6 Mini-Guides | 6.5 Indirect Routine Calling > | 7 Included Tools >> |
6.4 Euphoria To C Translator
6.4.1 Introduction
The Euphoria to C Translator (translator) will translate any Euphoria program into equivalent C source code.
There are versions of the translator for Windows and Unix operating Systems. After translating a Euphoria program to C, you can compile and link using one of the supported C compilers. This will give you an executable file that will typically run much faster than if you used the Euphoria interpreter.
The translator can translate and then compile itself into an executable file for each platform. The translator is also used in translating/compiling the front-end portion of the interpreter. The source code for the translator is in euphoria\source. It is written 100% in Euphoria.
6.4.2 Supported Compilers
The Translator currently works with GNU C on Unix OSes, GNU C on Windows from MinGW or Cygwin using the -gcc option and with Watcom C (the default) on Windows. These are all free compilers.
GNU C will exist already on your Unix system. The others can be downloaded from their respective Web sites.
<IP_ADDRESS> Notes:
- Warnings are turned off when compiling directly or with makefiles. If you turn them on, you may see some harmless messages about variables declared but not used, labels defined but not used, function prototypes not declared etc.
- For the -gcc option on Windows you will need a eu.a compiled with MinGW or Cygwin. The official distribution may only contain eu.lib compiled with Watcom. Also, the -stack and -con options may not produce the expected result with GCC C.
- Currently, only 32-bit compilers are supported on 64-bit platforms.
6.4.3 Run the Translator
Running the Translator is similar to running the Interpreter:
euc -con allsorts.ex
Note: that on Unix the demos might be installed to /usr/share/euphoria/demo
Instead of running the allsorts.ex program, the Translator will create several C source files in a temporary build directory, compile them and result in a native executable file. For this to work, you have to have a supporting compiler installed (mentioned above). The optional parameter used in this example, -con, will be explained in full detail below.
When the C compiling and linking is finished, you will have a file called allsorts.exe or simply allsorts on *nix systems. The C source files will have been removed to avoid clutter.
When you run the allsorts executable, it should run the same as if you had typed:
eui allsorts
to run it with the Interpreter, except that it should run faster, showing reduced times for the various sorting algorithms in euphoria\demo\allsorts.ex.
After creating your executable file, the translator removes all the C files that were created. If you want to look at these files, you'll need to run the translator again, using either the -keep or -makefile options.
6.4.4 Command-Line Options
<IP_ADDRESS> -arch - Set architecture
The translator generally produces cross platform code. However, the euphoria source code may have different code for different architectures. The default is to use the architecture of the translator binary that is being used. To target a different architecture, you can use one of three supported architectures:
- X86
- X86_64
- ARM
<IP_ADDRESS> -build-dir dir
Use the specified directory to write translated C files and compiled objects. The final executable is still output by default to the current directory (or however the -o flag specifies). When not specified, euphoria will create a temporary, randomly named build directory.
The specified directory cannot contain any wildcards ('*', '?') or be an existing file.
$ euc -build-dir temp_dir myapp.ex
<IP_ADDRESS> -cc-prefix - Compiler prefix
Some compilers, especially MinGW (the Windows version of gcc) may prefix their normal names with platform prefixes. The -cc-prefix switch allows the developer to specify this special prefix. This can also be useful for having a system with both the 32bit and 64bit versions installed. Cross compilers generally require this.
For example, on Windows, to build with MinGW installed as i6856-w64-mingw32:
euc -gcc -cc-prefix i686-w64-mingw32- pretend.exw
<IP_ADDRESS> -cflags FLAGS - Compiler Flags
Specifies the flags to pass to the compiler.
<IP_ADDRESS> -com DIR - Compiler directory
Tells the translator where to find include/euphoria.h, which is the header file required when translating code.
<IP_ADDRESS> -con - Console based program
To make a Windows console program instead of a Windows GUI program, add -con to the command line. e.g.
euc -con myprog.exw
When creating a Windows GUI program, if the -con option is used, when running your Windows program, you will have a blank console window appear and remain the duration of your application. By default, a GUI program is assumed.
<IP_ADDRESS> -debug - Debug mode
To compile your program with debugging information, usable with a debugger compatible with your compiler, use the -debug option:
euc -debug myapp.ex
<IP_ADDRESS> -dll / -so - Shared Library
To make a shared dynamically loading library, just add -dll to the command line. e.g.
euc -dll mylib.ew
Note: On *nix systems, you can also use -so. Both will produce a *nix shared library.
Please see Dynamic Link Libraries
<IP_ADDRESS> -extra-cflags - Extra Compiler Flags
Supply extra compiler flags to suplement the flags used automatically by the translator or supplied via the -cflags option.
<IP_ADDRESS> -extra-lflags - Extra Linker Flags
Supply extra linker flags to suplement the flags used automatically by the translator or supplied via the -lflags option.
<IP_ADDRESS> -gcc, -wat
If you happen to have more than one C compiler for a given platform, you can select the one you want to use with a command-line option:
-wat -- Watcom compiler -gcc -- GCC compiler (MinGW on Windows)
For example, to compile with GCC (or MinGW on Windows):
euc -gcc pretend.exw
Note: Watcom is the default on Windows and -wat is assumed.
<IP_ADDRESS> -keep
Normally, after building your .exe file, the translator will delete all C files and object files produced by the Translator. If you want it to keep these files, add the -keep option to the Translator command-line. e.g.
euc -keep sanity.ex
<IP_ADDRESS> -lflags FLAGS - Linker Flags
Specifies the flags to pass to the linker.
<IP_ADDRESS> -lib - User defined library
It is sometimes useful to link your translated code to a Euphoria runtime library other than the default supplied library. This ability is probably mostly useful for testing and debugging the runtime library itself, or to give additional debugging information when debugging translated Euphoria code. Note that only the default library is supplied. Use the -lib {library} option:
euc -lib decu.a myapp.ex
<IP_ADDRESS> -lib-pic - User defined library for PIC mode
Some platforms and architectures (e.g., x86-64) require that shared libraries be built in Position Independent Code mode, which requires that the euphoria run time library also be built with PIC. This option is similar to the -lib - User defined library option, except that it specifies the library to use for PIC code:
euc -lib-pic euso.a myapp.ex
<IP_ADDRESS> -makefile / -makefile-partial - Using makefiles
You can optionally have the translator create a makefile that you can use to build your program instead of building directly. Using a makefile like this can be convenient if you want or need to alter the translated C code, or change compiling or linking options before building your program. To do so:
$ euc -makefile myapp.ex Translating code, pass: 1 2 3 4 generating 3.c files were created. To build your project, type make -f myapp.mak
Then, as the message indicates, simply type:
$ make -f myapp.mak
On Windows, when using Watcom, the message will refer to wmake, the Watcom version of make. On BSD platforms, you may need to use gmake, as the generated makefiles are in GNU format, not BSD.
You can also get a partial makefile using the -makefile-partial switch. This generates a makefile that you can use to include into another makefile for a larger project. This is useful for including the file dependencies for your code into the larger project.
<IP_ADDRESS> -maxsize NUMBER
Specifies the maximum number of C statements to go into a single file before the translated file is split into multiple C files.
<IP_ADDRESS> -plat - Set platform
The translator has the capability of translating Euphoria code to C code for a platform other than the host platform. This can be done with the -plat option. It takes one parameter, the platform code:
- FREEBSD
- LINUX
- OSX
- WINDOWS
- NETBSD
- OPENBSD
Use one of these options to translate code into C for the specified platform. The default will always be the host platform of the translator that is executed, so euc.exe will default to Windows, and euc will default to the platform upon which it was built.
The resulting output can be compiled by the appropriate compiler on the specified platform, or, possibly a cross platform compiler, if you have one configured.
<IP_ADDRESS> -rc-file - Resource File
On Windows, euc can automatically compile and link in an application specific resource file. This resource file can contain product and version information, an application icon or any other valid resource data.
euc -rc-file myapp.rc myapp.ex
The resulting executable will contain all the resources from myapp.rc compiled into the executable. Please see Using Resource Files.
<IP_ADDRESS> -silent
Do not display status messages.
<IP_ADDRESS> -stack - Stack size
To increase or decrease the total amount of stack space reserved for your program, add -stack nnnn to the command line. e.g.
euc -stack 100000 myprog.ex
The total stack space (in bytes) that you specify will be divided up among all the tasks that you have running (assuming you have more than one). Each task has it's own private stack space. If it exceeds its allotment, you'll get a run-time error message identifying the task and giving the size of its stack space. Most non-recursive tasks can run with call stacks as small as 2000 bytes, but to be safe, you should allow more than this. A deeply-recursive task could use a great deal of space. It all depends on the maximum levels of calls that a task might need. At run-time, as your program creates more simultaneously-active tasks, the stack space allotted to each task will tend to decrease.
6.4.5 Dynamic Link Libraries
Simply by adding -dll (or -so) to the command line, the Translator will build a shared dynamically loading library instead of an executable program.
You can translate and compile a set of useful Euphoria routines, and share them with other people, without giving them your source. Furthermore, your routines will likely run much faster when translated and compiled. Both translated/compiled and interpreted programs will be able to use your library.
Only the global Euphoria procedures and functions, i.e. those declared with the "global", "public" or "export" keyword, will be exported from the shared dynamically loaded library.
Any Euphoria program, whether translated or compiled or interpreted, can link with a Euphoria shared dynamically loading library using the same mechanism that lets you link with a shared dynamically loading library written in C. The program first calls open_dll to open the file, then it calls define_c_func or define_c_proc for any routines that it wants to call. It calls these routines using c_func and c_proc.
The routine names exported from a Euphoria shared dynamically loading library will vary depending on which C compiler you use.
GNU C on Unix exports the names exactly as they appear in the C code produced by the Translator, e.g. a Euphoria routine
global procedure foo(integer x, integer y)
would be exported as "_0foo" or maybe "_1foo" etc. The underscore and digit are added to prevent naming conflicts. The digit refers to the Euphoria file where the identifier is defined. The main file is numbered as 0. The include files are numbered in the order they are encountered by the compiler. You should check the C source to be sure.
For Watcom, the Translator also creates an EXPORT command, added to objfiles.lnk for each exported identifier, so foo would be exported as "foo".
With Watcom, if you specify the -makefile option, you can edit the objfiles.lnk file to rename the exported identifiers, or remove ones that you do not want to export. Then build with the generated makefile.
Having nice exported names is not critical, since the name need only appear once in each Euphoria program that uses the shared dynamically loading library, i.e. in a single define_c_func or define_c_proc statement. The author of a shared dynamically loading library should probably provide his users with a Euphoria include file containing the necessary define_c_func and define_c_proc statements, and he might even provide a set of Euphoria "wrapper" routines to call the routines in the shared dynamically loading library.
When you call open_dll, any top-level Euphoria statements in the shared dynamically loading library will be executed automatically, just like a normal program. This gives the library a chance to initialize its data structures prior to the first call to a library routine. For many libraries no initialization is required.
To pass Euphoria data (atoms and sequences) as arguments, or to receive a Euphoria object as a result, you will need to use the following constants in euphoria\include\dll.e:
-- Euphoria types for shared dynamically loading library arguments -- and return values: global constant E_INTEGER = #06000004, E_ATOM = #07000004, E_SEQUENCE= #08000004, E_OBJECT = #09000004
Use these in define_c_proc and define_c_func just as you currently use C_INT, C_UINT etc. to call C shared dynamically loading libraries.
Currently, file numbers returned by open, and routine id's returned by routine_id, can be passed and returned, but the library and the main program each have their own separate ideas of what these numbers mean. Instead of passing the file number of an open file, you could instead pass the file name and let the shared dynamically loading library open it. Unfortunately there is no simple solution for passing routine id's. This might be fixed in the future.
A Euphoria shared dynamically loading library currently may not execute any multitasking operations. The Translator will give you an error message about this.
Euphoria shared dynamically loading library can also be used by C programs as long as only 31-bit integer values are exchanged. If a 32-bit pointer or integer must be passed, and you have the source to the C program, you could pass the value in two separate 16-bit integer arguments (upper 16 bits and lower 16 bits), and then combine the values in the Euphoria routine into the desired 32-bit atom.
6.4.6 Using Resource Files
When creating an executable file to deliver to your users on Windows, its best to link in a resource file that at minimum sets your application icon but better if it sets product and version information.
When the resource compiler is launched by euc, a single macro is defined named SRCDIR. This can be used in your resource files to reference your application source path for including other resource files, icon files, etc...
A simple resource file to attach an icon to your executable file is as simple as:
myapp ICON SRCDIR\myapp.ico
Remember that SRCDIR will be expanded to your application source path.
A more complex resource file containing an icon and product/version information may look like:
1 VERSIONINFO FILEVERSION 4,0,0,9 PRODUCTVERSION 4,0,0,9 FILEFLAGSMASK 0x3fL FILEFLAGS 0x0L FILEOS 0x4L FILETYPE 0x1L FILESUBTYPE 0x0L BEGIN BLOCK "StringFileInfo" BEGIN BLOCK "040904B0" BEGIN VALUE "Comments", "http://myapplication.com\0" VALUE "CompanyName", "John Doe Computing\0" VALUE "FileDescription", "Cool App\0 VALUE "FileVersion", "4.0.0\0" VALUE "InternalName", "coolapp.exe\0" VALUE "LegalCopyright", "Copyright (c) 2022 by John Doe Computing\0" VALUE "LegalTrademarks1", "Trademark Pending\0" VALUE "LegalTrademarks2", "\0" VALUE "OriginalFilename", "coolapp.exe\0" VALUE "ProductName", "Cool Application\0" VALUE "ProductVersion", "4.0.0\0" END END BLOCK "VarFileInfo" BEGIN VALUE "Translation", 0x409, 1200 END END coolapp ICON SRCDIR\coolapp.ico
One other item you may wish to include is a manifest file which lets Windows know that controls should use the new theming engines available in >= Windows XP. Simply append:
1 24 "coolapp.manifest"
to the end of your resource file. The coolapp.manifest file is:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"> <assemblyIdentity version="<IP_ADDRESS>" processorArchitecture="x86" name="euphoria" type="win32" /> <dependency> <dependentAssembly> <assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="<IP_ADDRESS>" processorArchitecture="X86" publicKeyToken="6595b64144ccf1df" language="*" /> </dependentAssembly> </dependency> </assembly>
Version, Product and Manfiest information may change with new releases of Microsoft Windows. You should consult MSDN for up to date information about using resource files with your application. MSDN About Resource Files.
6.4.7 Executable Size and Compression
The translator does not compress your executable file. If you want to do this we suggest you try the free UPX compressor.
Large Win32Lib-based .exe's produced by the Translator can be compressed by UPX to about 15% of their original size, and you won't notice any difference in start-up time.
The Translator deletes routines that are not used, including those from the standard Euphoria include files. After deleting unused routines, it checks again for more routines that have now become unused, and so on. This can make a big difference, especially with Win32Lib-based programs where a large file is included, but many of the included routines are not used in a given program.
Nevertheless, your compiled executable file will likely be larger than the same Euphoria program bound with the interpreter back-end. This is partly due to the back-end being a compressed executable. Also, Euphoria statements are extremely compact when stored in a bound file. They need more space after being translated to C, and compiled into machine code. Future versions of the Translator will produce faster and smaller executables.
6.4.8 Interpreter versus Translator
All Euphoria programs can be translated to C, and with just a few exceptions noted below, will run the same as with the Interpreter (but hopefully faster).
The Interpreter and Translator share the same parser, so you will get the same syntax errors, variable not declared errors etc. with either one.
The Interpreter automatically expands the call stack (until memory is exhausted), so you can have a huge number of levels of nested calls. Most C compilers, on most systems, have a pre-set limit on the size of the stack. Consult your compiler or linker manual if you want to increase the limit, for example if you have a recursive routine that might need thousands of levels of recursion. Modify the link command in your makefile, or use the -lflags option when calling the translator. For Watcom C, use OPTION STACK=nnnn, where nnnn is the number of bytes of stack space.
<IP_ADDRESS> Note:
The Translator assumes that your program has no run-time errors in it that would be caught by the Interpreter. The Translator does not check for: subscript out of bounds, variable not initialized, assigning the wrong type of data to a variable, etc.
You should debug your program with the Interpreter. The Translator checks for certain run-time errors, but in the interest of speed, most are not checked. When translated C code crashes you'll typically get a very cryptic machine exception. In most cases, the first thing you should do is run your program with the Interpreter, using the same inputs, and preferably with type_check turned on. If the error only shows up in translated code, you can use with trace and trace(3) to get a ctrace.out file showing a circular buffer of the last 500 Euphoria statements executed. If a translator-detected error message is displayed (and stored in ex.err), you will also see the offending line of Euphoria source whenever with trace is in effect. with trace will slow your program down, and the slowdown can be extreme when trace(3) is also in effect.
6.4.9 Legal Restrictions
As far as RDS is concerned, any executable programs or shared dynamically loading libraries that you create with this Translator without modifying an RDS translator library file, may be distributed royalty-free. You are free to incorporate any Euphoria files provided by RDS into your application.
In general, if you wish to use Euphoria code written by 3rd parties, please honor any restrictions that apply. If in doubt, you should ask for permission.
On Linux, FreeBSD, the GNU Library licence will normally not affect programs created with this Translator. Simply compiling with GNU C does not give the Free Software Foundation any jurisdiction over your program. If you statically link their libraries you will be subject to their Library licence, but the standard compile/link procedure does not statically link any FSF libraries, so there should be no problem.
6.4.10 Disclaimer:
This is what we believe to be the case. We are not lawyers. If it's important to you, you should read all licences and the legal comments in them, to form your own judgment. You may need to get professional legal opinion as well.
6.4.11 Frequently Asked Questions
<IP_ADDRESS> How much of a speed-up should I expect?
It all depends on what your program spends its time doing. Programs that use mainly integer calculations, don't call run-time routines very often, and don't do much I/O will see the greatest improvement, currently up to about 5x faster. Other programs may see only a few percent improvement.
The various C compilers are not equal in optimization ability.
<IP_ADDRESS> What if I want to change the compile or link options in my generated makefile?
Feel free to do so, that's one reason for producing a makefile.
<IP_ADDRESS> How can I make my program run even faster?
It's important to declare variables as integer where possible. In general, it helps if you choose the most restrictive type possible when declaring a variable.
Typical user-defined types will not slow you down. Since your program is supposed to be free of type_check errors, types are ignored by the Translator, unless you call them directly with normal function calls. The one exception is when a user-defined type routine has side-effects (i.e. it sets a global variable, performs pokes into memory, I/O etc.). In that case, if with type_check is in effect, the Translator will issue code to call the type routine and report any type_check failure that results.
On Windows we have left out the /ol loop optimization for Watcom's wcc386. We found in a couple of rare cases that this option led to incorrect machine code being emitted by the Watcom C compiler. If you add it back in to your own makefile you might get a slight improvement in speed, with a slight risk of buggy code.
On Linux or FreeBSD you could try the -O3 option of gcc instead of -O2. It will "in-line" small routines, improving speed slightly, but creating a larger executable. You could also try the Intel C++ Compiler for Linux. It's compatible with GNU C, but some adjustments to your makefile might be required.
6.4.12 Common Problems
Many large programs have been successfully translated and compiled using each of the supported C compilers, and the Translator is now quite stable.
<IP_ADDRESS> Note:
On Windows, if you call a C routine that uses the cdecl calling convention (instead of stdcall), you must specify a '+' character at the start of the routine's name in define_c_proc and define_c_func. If you don't, the call may not work when running the eui Interpreter.
In some cases a huge Euphoria routine is translated to C, and it proves to be too large for the C compiler to process. If you run into this problem, make your Euphoria routine smaller and simpler. You can also try turning off C optimization in your makefile for just the .c file that fails. Breaking up a single constant declaration of many variables into separate constant declarations of a single variable each, may also help. Euphoria has no limits on the size of a routine, or the size of a file, but most C compilers do. The Translator will automatically produce multiple small .c files from a large Euphoria file to avoid stressing the C compiler. It won't however, break a large routine into smaller routines.


--- layout: post title: More from Tomi Ahonen, on date: 2004-10-14 00:00:00 category: mobile ---
More from Tomi Ahonen, on 3:
"Three has released its ARPU (Average Revenue Per User) numbers for Italy and the UK for the second quarter of 2004. The total subscriber numbers have doubled 1.4 M in Italy, 1.3 M in the UK, yet the ARPU level is almost identical, at twice the average for 2G customers in both markets. This is very remarkable and against the conventional wisdom of most forecasters and modellers. The assumption was that the first few to get 3G will be the heavy users, with astronomical ARPU levels, but as more mainstream customers sign up, they will bring more typical usage, dropping the average across the whole network. Three has been incredibly successful this year (as opposed to seemingly doing everything wrong last year) "


Duration
10 minutes
Lab goals
The goal of this exerice is to modify the database calls in your project to use their asynchronous counterparts from the SQLite.net library. Here are the basic steps we will perform:
-
Modify the
SQLiteConnection
initialization code in thePersonRepository
class to create aSQLiteAsyncConnection
, and to create the table using an async call. -
Modify the Insert, and Get methods in the
PersonRepository
class to use their async counterparts. Since we are using theTask
-based methods, we can utilize the C#async
andawait
keywords to simplify our code. -
Rename the
AddNewPerson
andGetAllPeople
methods to include the term Async in the method names. -
Modify the calls in the
MainPage.xaml.cs
file to call the new asynchronous methods.
Required assets
The provided Resources folder for this exercise contains a subfolder named Lab.Completed with a solution you can use to check your work. This lab is a continuation of the previous one. If you did not complete the previous exercise, you can use the Lab.Completed solution from the previous part as starter code for this part.
Exercise challenge
Follow the above goals to complete the exercise. You can refer to the step-by-step instructions below to get more detailed information on each goal.
Steps
Below are the step-by-step instructions to implement the exercise.
Create a SQLiteAsyncConnection
- Open the PersonRepository.cs file within the People Portable Class Library.
-
Modify the
SQLiteConnection
initialization code in thePersonRepository
class to create aSQLiteAsyncConnection
.Hint: TheSQLiteAsyncConnection
class uses the same constructor syntax so it's just a direct type replacement. Remember to modify the variable declaration forconn
to SQLiteAsyncConnection. -
Modify the
CreateTable
call to use its async counterpart (CreateTableAsync
). Notice that this returns aTask
, however we cannot await it here because we are in a constructor. There are several options we could take:- Ignore the result and just assume the table creation will complete before any operations are performed.
-
Issue a
Wait
on the returningTask
- this makes the UI thread block until the creation is completed, essentially the same as a synchronous call in this case. -
Create an initialize method (which can then use
async
andawait
) call it before we perform any operations. -
Cache off the returned
Task
and issue anawait
in all the methods which need the table to be created.
Wait
call to block and ensure the table is created - if you have time at the end (or after class), you can try playing with the other approaches listed here.
Refactor to use Asynchronous database calls
-
Modify the
AddNewPerson
method to insert a newPerson
using an asynchronous call.- Refactor the method to use async/await.
-
Change the return type to be a
Task
so we can see exceptions that might happen in the method from the caller. -
You will need a new namespace:
System.Threading.Tasks
to return aTask
type. - Rename the method to append the term Async to the end of the method name.
-
Modify the
GetAllPeople
method to return the results using an asynchronous call.- Refactor the method to use async/await.
- Rename the method to append the term Async to the end of the method name.
-
The returning result from the method will need to be modified to return a
Task<List<Person>>
.
-
In the
MainPage.xaml.cs
file, modify both of theButton.Click
event handlers to use the async methods from thePersonRepository
class, making use of theasync
andawait
keywords. - Build the solution and run the app to verify it still works properly.
We can make our code even more optimized for async methods with some more revisions. There are two reasons why we would want to do this:
- Adding persons does not required context capturing
- Getting all persons does not need to be async ( it creates a state machine for nothing)
Optional: Optimize the Async Operations
We can make the AddNewPersonAsync
method even more efficient by changing the behavior of the await
keyword to not marshal back to the UI thread. Recall from the lecture that we can use the ConfigureAwait
method to force the remainder of the method to continue on the worker (background) thread if the processing of the data does not require UI interaction. This is true for the AddNewPersonAsync
method which only updates some data-bound values (Xamarin.Forms will do the UI marshalling automatically).
-
Change the
InsertAsync
method which is currentlyawait
'd to useConfigureAwait
with afalse
value so it stays on the UI thread. Here's the minor change to make: -
We can also simplify our
GetAllPeopleAsync
method slightly - since we aren't processing the data in this method, but simply returning it back to the caller, there's no need toawait
the call.-
Remove the
async
keyword from the method signature. -
Remove the
await
keyword from thereturn
statement.
-
Remove the
- Build and run the application and verify everything works properly.
var result = await conn.InsertAsync(new Person { Name = name }).ConfigureAwait(continueOnCapturedContext: false);
Summary
In this lab, you refactored your existing project to utilize the asynchronous versions of the SQLite-net methods so that your UI thread isn't tied up when I/O is being performed.
If you have time, try adding some filters into the query, adding support to edit records and delete records through new buttons in the UI.