Go to the first, previous, next, last section, table of contents.
This chapter describes some aspects of the design and implementation
of the g77
front end.
Much of the information below applies not to current
releases of g77
,
but to the 0.6 rewrite being designed and implemented
as of late May, 1999.
To find about things that are "To Be Determined" or "To Be Done", search for the string TBD. If you want to help by working on one or more of these items, email me at<EMAIL_ADDRESS>If you're planning to do more than just research issues and offer comments, see http://egcs.cygnus.com/contribute.html for steps you might need to take first.
The current directory layout includes the following:
libg2c
configuration and g2c.h
file generation
libg2c
libg2c
libc
for libg2c
Components of note in g77
are described below.
`f/' as a whole contains the source for g77
,
while `libf2c/' contains a portion of the separate program
f2c
.
Note that the libf2c
code is not part of the program g77
,
just distributed with it.
`f/' contains text files that document the Fortran compiler, source
files for the GNU Fortran Front End (FFE), and some other stuff.
The g77
compiler code is placed in `f/' because it,
along with its contents,
is designed to be a subdirectory of a gcc
source directory,
`gcc/',
which is structured so that language-specific front ends can be "dropped
in" as subdirectories.
The C++ front end (g++
), is an example of this--it resides in
the `cp/' subdirectory.
Note that the C front end (also referred to as gcc
)
is an exception to this, as its source files reside
in the `gcc/' directory itself.
`libf2c/' contains the run-time libraries for the f2c
program,
also used by g77
.
These libraries normally referred to collectively as libf2c
.
When built as part of g77
,
libf2c
is installed under the name libg2c
to avoid
conflict with any existing version of libf2c
,
and thus is often referred to as libg2c
when the
g77
version is specifically being referred to.
The netlib
version of libf2c/
contains two distinct libraries,
libF77
and libI77
,
each in their own subdirectories.
In g77
, this distinction is not made,
beyond maintaining the subdirectory structure in the source-code tree.
`libf2c/' is not part of the program g77
,
just distributed with it.
It contains files not present
in the official (netlib
) version of libf2c
,
and also contains some minor changes made from libf2c
,
to fix some bugs,
and to facilitate automatic configuration, building, and installation of
libf2c
(as libg2c
) for use by g77
users.
See `libf2c/README' for more information,
including licensing conditions
governing distribution of programs containing code from libg2c
.
libg2c
, g77
's version of libf2c
,
adds Dave Love's implementation of libU77
,
in the `libf2c/libU77/' directory.
This library is distributed under the
GNU Library General Public License (LGPL)---see the
file `libf2c/libU77/COPYING.LIB'
for more information,
as this license
governs distribution conditions for programs containing code
from this portion of the library.
Files of note in `f/' and `libf2c/' are described below:
g77
documentation:
info -f f/g77.info -n "Actual Bugs"
g77
internals.
libg2c
internals.
g77
documentation, plus internal
changes of import.
Or use:
info -f f/g77.info -n News
g77
documentation, in Info format,
produced by building g77
.
All users of g77
(not just installers) should read this,
using the more
command if neither the info
command,
nor GNU Emacs (with its Info mode), are available, or if users
aren't yet accustomed to using these tools.
All of these files are readable as "plain text" files,
though they're easier to navigate using Info readers
such as info
and GNU Emacs Info mode.
If you want to explore the FFE code, which lives entirely in `f/',
here are a few clues.
The file `g77spec.c' contains the g77
-specific source code
for the g77
command only--this just forms a variant of the
gcc
command, so,
just as the gcc
command itself does not contain the C front end,
the g77
command does not contain the Fortran front end (FFE).
The FFE code ends up in an executable named `f771',
which does the actual compiling,
so it contains the FFE plus the gcc
back end (GBE),
the latter to do most of the optimization, and the code generation.
The file `parse.c' is the source file for yyparse()
,
which is invoked by the GBE to start the compilation process,
for `f771'.
The file `top.c' contains the top-level FFE function ffe_file
and it (along with top.h) define all `ffe_[a-z].*', `ffe[A-Z].*',
and `FFE_[A-Za-z].*' symbols.
The file `fini.c' is a main()
program that is used when building
the FFE to generate C header and source files for recognizing keywords.
The files `malloc.c' and `malloc.h' comprise a memory manager
that defines all `malloc_[a-z].*', `malloc[A-Z].*', and
`MALLOC_[A-Za-z].*' symbols.
All other modules named xyz are comprised of all files named `xyz*.ext' and define all `ffexyz_[a-z].*', `ffexyz[A-Z].*', and `FFEXYZ_[A-Za-z].*' symbols. If you understand all this, congratulations--it's easier for me to remember how it works than to type in these regular expressions. But it does make it easy to find where a symbol is defined. For example, the symbol `ffexyz_set_something' would be defined in `xyz.h' and implemented there (if it's a macro) or in `xyz.c'.
The "porting" files of note currently are:
ARRAY_SIZE
and such.
INTEGER*8
map, for example),
how to convert between them,
and so on.
Over time, versions of g77
rely less on this file
and more on run-time configuration based on GBE info
in `com.c'.
If you want to debug the `f771' executable,
for example if it crashes,
note that the global variables lineno
and input_filename
are usually set to reflect the current line being read by the lexer
during the first-pass analysis of a program unit and to reflect
the current line being processed during the second-pass compilation
of a program unit.
If an invocation of the function ffestd_exec_end
is on the stack,
the compiler is in the second pass, otherwise it is in the first.
(This information might help you reduce a test case and/or work around
a bug in g77
until a fix is available.)
The order of phases translating source code to the form accepted by the GBE is:
To get a rough idea of how a particularly twisted Fortran statement gets treated by the passes, consider:
FORMAT(I2 4H)=(J/ & I3)
The job of `lex.c' is to know enough about Fortran syntax rules to break the statement up into distinct lexemes without requiring any feedback from subsequent phases:
`FORMAT' `(' `I24H' `)' `=' `(' `J' `/' `I3' `)'
The job of `sta.c' is to figure out the kind of statement, or, at least, statement form, that sequence of lexemes represent.
The sooner it can do this (in terms of using the smallest number of lexemes, starting with the first for each statement), the better, because that leaves diagnostics for problems beyond the recognition of the statement form to subsequent phases, which can usually better describe the nature of the problem.
In this case, the `=' at "level zero"
(not nested within parentheses)
tells `sta.c' that this is an assignment-form,
not FORMAT
, statement.
An assignment-form statement might be a statement-function definition or an executable assignment statement.
To make that determination, `sta.c' looks at the first two lexemes.
Since the second lexeme is `(', the first must represent an array for this to be an assignment statement, else it's a statement function.
Either way, `sta.c' hands off the statement to `stb.c' (either its statement-function parser or its assignment-statement parser).
`stb.c' forms a statement-specific record containing the pertinent information. That information includes a source expression and, for an assignment statement, a destination expression. Expressions are parsed by `expr.c'.
This record is passed to `stc.c', which copes with the implications of the statement within the context established by previous statements.
For example, if it's the first statement in the file
or after an END
statement,
`stc.c' recognizes that, first of all,
a main program unit is now being lexed
(and tells that to `std.c'
before telling it about the current statement).
`stc.c' attaches whatever information it can, usually derived from the context established by the preceding statements, and passes the information to `std.c'.
`std.c' saves this information away, since the GBE cannot cope with information that might be incomplete at this stage.
For example, `I3' might later be determined
to be an argument to an alternate ENTRY
point.
When `std.c' is told about the end of an external (top-level) program unit, it passes all the information it has saved away on statements in that program unit to `ste.c'.
`ste.c' "expands" each statement, in sequence, by constructing the appropriate GBE information and calling the appropriate GBE routines.
Details on the transformational phases follow. Keep in mind that Fortran numbering is used, so the first character on a line is column 1, decimal numbering is used, and so on.
The g77stripcard
program handles removing content beyond
column 72 (adjustable via a command-line option),
optionally warning about that content being something other
than trailing whitespace or Fortran commentary.
This program is needed because lex.c
doesn't pay attention
to maximum line lengths at all, to make it easier to maintain,
as well as faster (for sources that don't depend on the maximum
column length vis-a-vis trailing non-blank non-commentary content).
Just how this program will be run--whether automatically for old source (perhaps as the default for `.f' files?)---is not yet determined.
In the meantime, it might as well be implemented as a typical UNIX pipe.
It should accept a `-fline-length-n' option, with the default line length set to 72.
When the text it strips off the end of a line is not blank
(not spaces and tabs),
it should insert an additional comment line
(beginning with `!',
so it works for both fixed-form and free-form files)
containing the text,
following the stripped line.
The inserted comment should have a prefix of some kind,
TBD, that distinguishes the comment as representing stripped text.
Users could use that to sed
out such lines, if they wished--it
seems silly to provide a command-line option to delete information
when it can be so easily filtered out by another program.
(This inserted comment should be designed to "fit in" well
with whatever the Fortran community is using these days for
preprocessor, translator, and other such products, like OpenMP.
What that's all about, and how g77
can elegantly fit its
special comment conventions into it all, is TBD as well.
We don't want to reinvent the wheel here, but if there turn out
to be too many conflicting conventions, we might have to invent
one that looks nothing like the others, but which offers their
host products a better infrastructure in which to fit and coexist
peacefully.)
g77stripcard
probably shouldn't do any tab expansion or other
fancy stuff.
People can use expand
or other pre-filtering if they like.
The idea here is to keep each stage quite simple, while providing
excellent performance for "normal" code.
(Code with junk beyond column 73 is not really "normal", as it comes from a card-punch heritage, and will be increasingly hard for tomorrow's Fortran programmers to read.)
To help make the lexer simple, fast, and easy to maintain,
while also having g77
generally encourage Fortran programmers
to write simple, maintainable, portable code by maximizing the
performance of compiling that kind of code:
g77
presently uses.
But the standard requires a diagnostic for it in free form,
so the parser has to be able to recognize that
the lexemes aren't contiguous
(information the lexer does have to provide)
and that free-form source is being parsed,
so it can provide the diagnostic.
The g77
lexer doesn't try to gather `2 . 4' into a single lexeme.
Otherwise, it'd have to know a whole lot more about how to parse Fortran,
or subsequent phases (mainly parsing) would have two paths through
lots of critical code--one to handle the lexeme `2', `.',
and `4' in sequence, another to handle the lexeme `2.4'.
g77stripcard
first.
Also, keeping track of the maximum column position while also watching out
for the end of a line and while reading from a file
just makes things slower.
Since a file must be read, and watching for the end of the line
is necessary (unless the typical input file was preprocessed to
include the necessary number of trailing spaces),
dropping the tracking of the maximum column position
is the only way to reduce the complexity of the pertinent code
while maintaining high performance.
g77
, such as to C or Pascal code.
Names of intrinsics will probably be matchable in any case,
However, there probably won't be any option to require
a particular mixed-case appearance of intrinsics
(as there was for g77
prior to version 0.6),
because that's painful to maintain,
and probably nobody uses it.
(How `external SiN; r = sin(x)' would be handled is TBD.
I think old g77
might already handle that pretty elegantly,
but whether we can cope with allowing the same fragment to reference
a different procedure, even with the same interface,
via `s = SiN(r)', needs to be determined.
If it can't, we need to make sure that when code introduces
a user-defined name, any intrinsic matching that name
using a case-insensitive comparison
is "turned off".)
CHARACTER
and Hollerith constants
are not allowed.
This avoids the confusion introduced by some Fortran compiler vendors
providing C-like interpretation of backslashes,
while others provide straight-through interpretation.
Some kind of lexical construct (TBD) will be provided to allow
flagging of a CHARACTER
(but probably not a Hollerith)
constant that permits backslashes.
It'll necessarily be a prefix, such as:
PRINT *, C'This line has a backspace \b here.' PRINT *, F'This line has a straight backslash \ here.'Further, command-line options might be provided to specify that one prefix or the other is to be assumed as the default for
CHARACTER
constants.
However, it seems more helpful for g77
to provide a program
that converts prefix all constants
(or just those containing backslashes)
with the desired designation,
so printouts of code can be read
without knowing the compile-time options used when compiling it.
If such a program is provided
(let's name it g77slash
for now),
then a command-line option to g77
should not be provided.
(Though, given that it'll be easy to implement, it might be hard
to resist user requests for it "to compile faster than if we
have to invoke another filter".)
This program would take a command-line option to specify the
default interpretation of slashes,
affecting which prefix it uses for constants.
g77slash
probably should automatically convert Hollerith
constants that contain slashes
to the appropriate CHARACTER
constants.
Then g77
wouldn't have to define a prefix syntax for Hollerith
constants specifying whether they want C-style or straight-through
backslashes.
The above implements nearly exactly what is specified by section GNU Fortran Character Set, and section Lines, except it also provides automatic conversion of tabs and ignoring of newline-related carriage returns.
It also effects the "pure visual" model,
by which is meant that a user viewing his code
in a typical text editor
(assuming it's not preprocessed via g77stripcard
or similar)
doesn't need any special knowledge
of whether spaces on the screen are really tabs,
whether lines end immediately after the last visible non-space character
or after a number of spaces and tabs that follow it,
or whether the last line in the file is ended by a newline.
Most editors don't make these distinctions, the ANSI FORTRAN 77 standard doesn't require them to, and it permits a standard-conforming compiler to define a method for transforming source code to "standard form" however it wants.
So, GNU Fortran defines it such that users have the best chance of having the code be interpreted the way it looks on the screen of the typical editor.
(Fancy editors should never be required to correctly read code written in classic two-dimensional-plaintext form. By correct reading I mean ability to read it, book-like, without mistaking text ignored by the compiler for program code and vice versa, and without having to count beyond the first several columns. The vague meaning of ASCII TAB, among other things, complicates this somewhat, but as long as "everyone", including the editor, other tools, and printer, agrees about the every-eighth-column convention, the GNU Fortran "pure visual" model meets these requirements. Any language or user-visible source form requiring special tagging of tabs, the ends of lines after spaces/tabs, and so on, is broken by this definition. Fortunately, Fortran itself is not broken, even if most vendor-supplied defaults for their Fortran compilers are in this regard.)
Further, this model provides a clean interface
to whatever preprocessors or code-generators are used
to produce input to this phase of g77
.
Mainly, they need not worry about long lines.
This section is not about transforming "gotchas" into something else. It is about the weirder aspects of transforming Fortran, however that's defined, into a more modern, canonical form.
Each lexeme carries with it a pointer to where it appears in the source.
To provide the ability for diagnostics to point to column numbers, in addition to line numbers and names, lexemes that represent more than one (significant) character in the source code need, generally, to provide pointers to where each character appears in the source.
This provides the ability to properly identify the precise location of the problem in code like
SUBROUTINE X END BLOCK DATA X END
which, in fixed-form source, would result in single lexemes consisting of the strings `SUBROUTINEX' and `BLOCKDATAX'. (The problem is that `X' is defined twice, so a pointer to the `X' in the second definition, as well as a follow-up pointer to the corresponding pointer in the first, would be preferable to pointing to the beginnings of the statements.)
This need also arises when parsing (and diagnosing) FORMAT
statements.
Further, it arises when diagnosing
FMT=
specifiers that contain constants
(or partial constants, or even propagated constants!)
in I/O statements, as in:
PRINT '(I2, 3HAB)', J
(A pointer to the beginning of the prematurely-terminated Hollerith constant, and/or to the close parenthese, is preferable to a pointer to the open-parenthese or the apostrophe that precedes it.)
Multi-character lexemes, which would seem to naturally include
at least digit strings, alphanumeric strings, CHARACTER
constants, and Hollerith constants, therefore need to provide
location information on each character.
(Maybe Hollerith constants don't, but it's unnecessary to except them.)
The question then arises, what about other multi-character lexemes, such as `**' and `//', and Fortran 90's `(/', `/)', `::', and so on?
Turns out there's a need to identify the location of the second character of these two-character lexemes. For example, in `I(/J) = K', the slash needs to be diagnosed as the problem, not the open parenthese. Similarly, it is preferable to diagnose the second slash in `I = J // K' rather than the first, given the implicit typing rules, which would result in the compiler disallowing the attempted concatenation of two integers. (Though, since that's more of a semantic issue, it's not that much preferable.)
Even sequences that could be parsed as digit strings could use location info, for example, to diagnose the `9' in the octal constant `O'129''. (This probably will be parsed as a character string, to be consistent with the parsing of `Z'129A''.)
To avoid the hassle of recording the location of the second character, while also preserving the general rule that each significant character is distinctly pointed to by the lexeme that contains it, it's best to simply not have any fixed-size lexemes larger than one character.
This new design is expected to make checking for two `*' lexemes in a row much easier than the old design, so this is not much of a sacrifice. It probably makes the lexer much easier to implement than it makes the parser harder.
Certain lexemes need to be padded with virtual spaces when the end of the line (or file) is encountered.
This is necessary in fixed form, to handle lines that don't extend to column 72, assuming that's the line length in effect.
Last I checked, the Fortran 90 standard actually required the compiler to silently accept something like
FORMAT ( 1 2 Htwelve chars )
as a valid FORMAT
statement specifying a twelve-character
Hollerith constant.
The implication here is that, since the new lexer is a zero-feedback one,
it won't know that the special case of a FORMAT
statement being parsed
requires apparently distinct lexemes `1' and `2' to be treated as
a single lexeme.
(This is a horrible misfeature of the Fortran 90 language. It's one of many such misfeatures that almost make me want to not support them, and forge ahead with designing a new "GNU Fortran" language that has the features, but not the misfeatures, of Fortran 90, and provide utility programs to do the conversion automatically.)
So, the lexer must gather distinct chunks of decimal strings into a single lexeme in contexts where a single decimal lexeme might start a Hollerith constant.
(Which probably means it might as well do that all the time for all multi-character lexemes, even in free-form mode, leaving it to subsequent phases to pull them apart as they see fit.)
Compare the treatment of this to how
CHARACTER * 4 5 HEY
and
CHARACTER * 12 HEY
must be treated--the former must be diagnosed, due to the separation between lexemes, the latter must be accepted as a proper declaration.
Recognizing a Hollerith constant--specifically, that an `H' or `h' after a digit string begins such a constant--requires some knowledge of context.
Hollerith constants (such as `2HAB') can appear after:
Hollerith constants don't appear after:
While
REAL FUNCTION FOO ()
must be a FUNCTION
statement and
REAL FUNCTION FOO (5)
must be a type-definition statement,
REAL FUNCTION FOO (names)
where names is a comma-separated list of names, can be one or the other.
The only way to disambiguate that statement (short of mandating free-form source or a short maximum length for name for external procedures) is based on the context of the statement.
In particular, the statement is known to be within an
already-started program unit
(but not at the outer level of the CONTAINS
block),
it is a type-declaration statement.
Otherwise, the statement is a FUNCTION
statement,
in that it begins a function program unit
(external, or, within CONTAINS
, nested).
The statement
READ (N)
is equivalent to either
READ (UNIT=(N))
or
READ (FMT=(N))
depending on which would be valid in context.
Specifically, if `N' is type INTEGER
,
`READ (FMT=(N))' would not be valid,
because parentheses may not be used around `N',
whereas they may around it in `READ (UNIT=(N))'.
Further, if `N' is type CHARACTER
,
the opposite is true---`READ (UNIT=(N))' is not valid,
but `READ (FMT=(N))' is.
Strictly speaking, if anything follows
READ (N)
in the statement, whether the first lexeme after the close parenthese is a comma could be used to disambiguate the two cases, without looking at the type of `N', because the comma is required for the `READ (FMT=(N))' interpretation and disallowed for the `READ (UNIT=(N))' interpretation.
However, in practice, many Fortran compilers allow the comma for the `READ (UNIT=(N))' interpretation anyway (in that they generally allow a leading comma before an I/O list in an I/O statement), and much code takes advantage of this allowance.
(This is quite a reasonable allowance, since the juxtaposition of a comma-separated list immediately after an I/O control-specification list, which is also comma-separated, without an intervening comma, looks sufficiently "wrong" to programmers that they can't resist the itch to insert the comma. `READ (I, J), K, L' simply looks cleaner than `READ (I, J) K, L'.)
So, type-based disambiguation is needed unless strict adherence to the standard is always assumed, and we're not going to assume that.
Continue researching gotchas, designing the transformational process, and implementing it.
Specific issues to resolve:
INCLUDE
processing take place?
Clearly before (or part of) statement identification (`sta.c'),
since determining whether `I(J)=K' is a statement-function
definition or an assignment statement requires knowing the context,
which in turn requires having processed INCLUDE
files.
USE
processing take place?
This gets into the whole issue of how g77
should handle the concept
of modules.
I think GNAT already takes on this issue, but don't know more than that.
Jim Giles has written extensively on comp.lang.fortran
about his opinions on module handling, as have others.
Jim's views should be taken into account.
Actually, Richard M. Stallman (RMS) also has written up
some guidelines for implementing such things,
but I'm not sure where I read them.
Perhaps the old<EMAIL_ADDRESS>list.
If someone could dig references to these up and get them to me,
that would be much appreciated!
Even though modules are not on the short-term list for implementation,
it'd be helpful to know now how to avoid making them harder to
implement them later.
g77
command become just a script that invokes
all the various preprocessing that might be needed,
thus making it seem slower than necessary for legacy code
that people are unwilling to convert,
or should we provide a separate script for that,
thus encouraging people to convert their code once and for all?
At least, a separate script to behave as old g77
did,
perhaps named g77old
, might ease the transition,
as might a corresponding one that converts source codes
named g77oldnew
.
These scripts would take all the pertinent options g77
used
to take and run the appropriate filters,
passing the results to g77
or just making new sources out of them
(in a subdirectory, leaving the user to do the dirty deed of
moving or copying them over the old sources).
CHARACTER
(or Hollerith) constants?
Knowing what other compilers provide would help.
Don't poke the bear.
The g77
front end generates code
via the gcc
back end.
The gcc
back end (GBE) is a large, complex
labyrinth of intricate code
written in a combination of the C language
and specialized languages internal to gcc
.
While the code that implements the GBE is written in a combination of languages, the GBE itself is, to the front end for a language like Fortran, best viewed as a compiler that compiles its own, unique, language.
The GBE's "source", then, is written in this language, which consists primarily of a combination of calls to GBE functions and tree nodes (which are, themselves, created by calling GBE functions).
So, the g77
generates code by, in effect,
translating the Fortran code it reads
into a form "written" in the "language"
of the gcc
back end.
This language will heretofore be referred to as GBEL, for GNU Back End Language.
GBEL is an evolving language,
not fully specified in any published form
as of this writing.
It offers many facilities,
but its "core" facilities
are those that corresponding most directly
to those needed to support gcc
(compiling code written in GNU C).
The g77
Fortran Front End (FFE)
is designed and implemented
to navigate the currents and eddies
of ongoing GBEL and gcc
development
while also delivering on the potential
of an integrated FFE
(as compared to using a converter like f2c
and feeding the output into gcc
).
Goals of the FFE's code-generation strategy include:
g77
-specific) constructs,
such as command-line options.
The strategies historically, and currently, used by the FFE to achieve these goals include:
"Don't poke the bear" somewhat summarizes the above strategies.
The GBE is the bear.
The FFE is designed and implemented to avoid poking it
in ways that are likely to just annoy it.
The FFE usually either tackles it head-on,
or avoids treating it in ways dissimilar to how
the gcc
front end treats it.
For example, the FFE uses the native array facility in the back end
instead of the lower-level pointer-arithmetic facility
used by gcc
when compiling f2c
output).
Theoretically, this presents more opportunities for optimization,
faster compile times,
and the production of more faithful debugging information.
These benefits were not, however, immediately realized,
mainly because gcc
itself makes little or no use
of the native array facility.
Complex arithmetic is a case study of the evolution of this strategy. When originally implemented, the GBEL had just evolved its own native complex-arithmetic facility, so the FFE took advantage of that.
When porting g77
to 64-bit systems,
it was discovered that the GBE didn't really
implement its native complex-arithmetic facility properly.
The short-term solution was to rewrite the FFE
to instead use the lower-level facilities
that'd be used by gcc
-compiled code
(assuming that code, itself, didn't use the native complex type
provided, as an extension, by gcc
),
since these were known to work,
and, in any case, if shown to not work,
would likely be rapidly fixed
(since they'd likely not work for vanilla C code in similar circumstances).
However, the rewrite accommodated the original, native approach as well
by offering a command-line option to select it over the emulated approach.
This allowed users, and especially GBE maintainers, to try out
fixes to complex-arithmetic support in the GBE
while g77
continued to default to compiling more code correctly,
albeit producing (typically) slower executables.
As of April 1999, it appeared that the last few bugs in the GBE's support of its native complex-arithmetic facility were worked out. The FFE was changed back to default to using that native facility, leaving emulation as an option.
Other Fortran constructs--arrays, character strings,
complex division, COMMON
and EQUIVALENCE
aggregates,
and so on--involve issues similar to those pertaining to complex arithmetic.
So, it is possible that the history of how the FFE handled complex arithmetic will be repeated, probably in modified form (and hopefully over shorter timeframes), for some of these other facilities.
The FFE does not tell the GBE anything about a program unit until after the last statement in that unit has been parsed. (A program unit is a Fortran concept that corresponds, in the C world, mostly closely to functions definitions in ISO C. That is, a program unit in Fortran is like a top-level function in C. Nested functions, found among the extensions offered by GNU C, correspond roughly to Fortran's statement functions.)
So, while parsing the code in a program unit, the FFE saves up all the information on statements, expressions, names, and so on, until it has seen the last statement.
At that point, the FFE revisits the saved information (in what amounts to a second pass over the program unit) to perform the actual translation of the program unit into GBEL, ultimating in the generation of assembly code for it.
Some lookahead is performed during this second pass, so the FFE could be viewed as a "two-plus-pass" design.
Most of the code that turns the first pass (parsing) into a second pass for code generation is in `egcs/gcc/f/std.c'.
It has external functions, called mainly by siblings in `egcs/gcc/f/stc.c', that record the information on statements and expressions in the order they are seen in the source code. These functions save that information.
It also has an external function that revisits that information, calling the siblings in `egcs/gcc/f/ste.c', which handles the actual code generation (by generating GBEL code, that is, by calling GBE routines to represent and specify expressions, statements, and so on).
The need for two passes was not immediately evident
during the design and implementation of the code in the FFE
that was to produce GBEL.
Only after a few kludges,
to handle things like incorrectly-guessed ASSIGN
label nature,
had been implemented,
did enough evidence pile up to make it clear
that `std.c' had to be introduced to intercept,
save, then revisit as part of a second pass,
the digested contents of a program unit.
Other such missteps have occurred during the evolution of the FFE, because of the different goals of the FFE and the GBE.
Because the GBE's original, and still primary, goal
was to directly support the GNU C language,
the GBEL, and the GBE itself,
requires more complexity
on the part of most front ends
than it requires of gcc
's.
For example,
the GBEL offers an interface that permits the gcc
front end
to implement most, or all, of the language features it supports,
without the front end having to
make use of non-user-defined variables.
(It's almost certainly the case that all of K&R C,
and probably ANSI C as well,
is handled by the gcc
front end
without declaring such variables.)
The FFE, on the other hand, must resort to a variety of "tricks" to achieve its goals.
Consider the following C code:
int foo (int a, int b) { int c = 0; if ((c = bar (c)) == 0) goto done; quux (c << 1); done: return c; }
Note what kinds of objects are declared, or defined, before their use, and before any actual code generation involving them would normally take place:
Whereas, the following items can, and do, suddenly appear "out of the blue" in C:
Not surprisingly, the GBE faithfully permits the latter set of items to be "discovered" partway through GBEL "programs", just as they are permitted to in C.
Yet, the GBE has tended, at least in the past, to be reticent to fully support similar "late" discovery of items in the former set.
This makes Fortran a poor fit for the "safe" subset of GBEL. Consider:
FUNCTION X (A, ARRAY, ID1) CHARACTER*(*) A DOUBLE PRECISION X, Y, Z, TMP, EE, PI REAL ARRAY(ID1*ID2) COMMON ID2 EXTERNAL FRED ASSIGN 100 TO J CALL FOO (I) IF (I .EQ. 0) PRINT *, A(0) GOTO 200 ENTRY Y (Z) ASSIGN 101 TO J 200 PRINT *, A(1) READ *, TMP GOTO J 100 X = TMP * EE RETURN 101 Y = TMP * PI CALL FRED DATA EE, PI /2.71D0, 3.14D0/ END
Here are some observations about the above code, which, while somewhat contrived, conforms to the FORTRAN 77 and Fortran 90 standards:
ENTRY
statement is parsed.
DATA
statement is parsed.
REAL
or a subroutine
(which can be thought of as returning type void
or, to support alternate returns in a simple way,
type int
)
is not known
until the `CALL FRED' statement is parsed.
FORMAT
label
or the label of an executable statement
is not known
until the `X =' statement is parsed.
(These two types of labels get very different treatment,
especially when ASSIGN
'ed.)
ASSIGN
statement is parsed.
(This happens after executable code has been seen.)
Very few of these "discoveries" can be accommodated by the GBE as it has evolved over the years. The GBEL doesn't support several of them, and those it might appear to support don't always work properly, especially in combination with other GBEL and GBE features, as implemented in the GBE.
(Had the GBE and its GBEL originally evolved to support g77
,
the shoe would be on the other foot, so to speak--most, if not all,
of the above would be directly supported by the GBEL,
and a few C constructs would probably not, as they are in reality,
be supported.
Both this mythical, and today's real, GBE caters to its GBEL
by, sometimes, scrambling around, cleaning up after itself--after
discovering that assumptions it made earlier during code generation
are incorrect.)
So, the FFE handles these discrepancies--between the order in which it discovers facts about the code it is compiling, and the order in which the GBEL and GBE support such discoveries--by performing what amounts to two passes over each program unit.
(A few ambiguities can remain at that point,
such as whether, given `EXTERNAL BAZ'
and no other reference to `BAZ' in the program unit,
it is a subroutine, a function, or a block-data--which, in C-speak,
governs its declared return type.
Fortunately, these distinctions are easily finessed
for the procedure, library, and object-file interfaces
supported by g77
.)
Consider the following Fortran code, which uses various extensions (including some to Fortran 90):
SUBROUTINE X(A) CHARACTER*(*) A COMPLEX CFUNC INTEGER*2 CLOCKS(200) INTEGER IFUNC CALL SYSTEM_CLOCK (CLOCKS (IFUNC (CFUNC ('('//A//')'))))
The above poses the following challenges to any Fortran compiler
that uses run-time interfaces, and a run-time library, roughly similar
to those used by g77
:
SYSTEM_CLOCK
expects to set an INTEGER*4
variable via its COUNT
argument,
the compiler must make available to it a temporary variable of that type.
SYSTEM_CLOCK
library routine returns,
the compiler must ensure that the temporary variable it wrote
is copied into the appropriate element of the `CLOCKS' array.
(This assumes the compiler doesn't just reject the code,
which it should if it is compiling under some kind of a "strict" option.)
SYSTEM_CLOCK
library routine returns),
the compiler must ensure that the IFUNC
function is called.
That requires evaluating its argument,
which requires, for g77
(assuming -ff2c
is in force),
reserving a temporary variable of type COMPLEX
for use as a repository for the return value
being computed by `CFUNC'.
CFUNC
should, ideally, be deallocated
(or, at least, left to the GBE to dispose of, as it sees fit)
as soon as CFUNC
returns,
which means before IFUNC
is called
(as it might need a lot of dynamically allocated memory).
g77
currently doesn't support all of the above,
but, so that it might someday, it has evolved to handle
at least some of the above requirements.
Meeting the above requirements is made more challenging by conforming to the requirements of the GBEL/GBE combination.
Most Fortran statements are given their own block, and, for temporary variables they might need, their own scope. (A block is what distinguishes `{ foo (); }' from just `foo ();' in C. A scope is included with every such block, providing a distinct name space for local variables.)
Label definitions for the statement precede this block, so `10 PRINT *, I' is handled more like `fl10: { ... }' than `{ fl10: ... }' (where `fl10' is just a notation meaning "Fortran Label 10" for the purposes of this document).
Any temporaries needed during, but not beyond, execution of a Fortran statement, are made local to the scope of that statement's block.
This allows the GBE to share storage for these temporaries among the various statements without the FFE having to manage that itself.
(The GBE could, of course, decide to optimize management of these temporaries. For example, it could, theoretically, schedule some of the computations involving these temporaries to occur in parallel. More practically, it might leave the storage for some temporaries "live" beyond their scopes, to reduce the number of manipulations of the stack pointer at run time.)
Temporaries needed across distinct statement boundaries usually
are associated with Fortran blocks (such as DO
/END DO
).
(Also, there might be temporaries not associated with blocks at all--these
would be in the scope of the entire program unit.)
Each Fortran block should get its own block/scope in the GBE.
This is best, because it allows temporaries to be more naturally handled.
However, it might pose problems when handling labels
(in particular, when they're the targets of GOTO
s outside the Fortran
block), and generally just hassling with replicating
parts of the gcc
front end
(because the FFE needs to support
an arbitrary number of nested back-end blocks
if each Fortran block gets one).
So, there might still be a need for top-level temporaries, whose "owning" scope is that of the containing procedure.
Also, there seems to be problems declaring new variables after generating code (within a block) in the back end, leading to, e.g., `label not defined before binding contour' or similar messages, when compiling with `-fstack-check' or when compiling for certain targets.
Because of that, and because sometimes these temporaries are not discovered until in the middle of of generating code for an expression statement (as in the case of the optimization for `X**I'), it seems best to always pre-scan all the expressions that'll be expanded for a block before generating any of the code for that block.
This pre-scan then handles discovering and declaring, to the back end, the temporaries needed for that block.
It's also important to treat distinct items in an I/O list as distinct statements deserving their own blocks. That's because there's a requirement that each I/O item be fully processed before the next one, which matters in cases like `READ (*,*), I, A(I)'---the element of `A' read in the second item must be determined from the value of `I' read in the first item.
`DO WHILE(expr)' must be implemented so that temporaries needed to evaluate `expr' are generated just for the test, each time.
Consider how `DO WHILE (A//B .NE. 'END'); ...; END DO' is transformed:
for (;;) { int temp0; { char temp1[large]; libg77_catenate (temp1, a, b); temp0 = libg77_ne (temp1, 'END'); } if (! temp0) break; ... }
In this case, it seems like a time/space tradeoff between allocating and deallocating `temp1' for each iteration and allocating it just once for the entire loop.
However, if `temp1' is allocated just once for the entire loop, it could be the wrong size for subsequent iterations of that loop in cases like `DO WHILE (A(I:J)//B .NE. 'END')', because the body of the loop might modify `I' or `J'.
So, the above implementation is used, though a more optimal one can be used in specific circumstances.
An iterative DO
loop
(one that specifies an iteration variable)
is required by the Fortran standards
to be implemented as though an iteration count
is computed before entering the loop body,
and that iteration count used to determine
the number of times the loop body is to be performed
(assuming the loop isn't cut short via GOTO
or EXIT
).
The FFE handles this by allocating a temporary variable to contain the computed number of iterations. Since this variable must be in a scope that includes the entire loop, a GBEL block is created for that loop, and the variable declared as belonging to the scope of that block.
Consider:
SUBROUTINE X(A,B,C) CHARACTER*(*) A, B, C LOGICAL LFUNC IF (LFUNC (A//B)) THEN CALL SUBR1 ELSE IF (LFUNC (A//C)) THEN CALL SUBR2 ELSE CALL SUBR3 END
The arguments to the two calls to `LFUNC'
require dynamic allocation (at run time),
but are not required during execution of the CALL
statements.
So, the scopes of those temporaries must be within blocks inside
the block corresponding to the Fortran IF
block.
This cannot be represented "naturally"
in vanilla C, nor in GBEL.
The if
, elseif
, else
,
and endif
constructs
provided by both languages must,
for a given if
block,
share the same C/GBE block.
Therefore, any temporaries needed during evaluation of `expr'
while executing `ELSE IF(expr)'
must either have been predeclared
at the top of the corresponding IF
block,
or declared within a new block for that ELSE IF
---a block that,
since it cannot contain the else
or else if
itself
(due to the above requirement),
actually implements the rest of the IF
block's
ELSE IF
and ELSE
statements
within an inner block.
The FFE takes the latter approach.
SELECT CASE
poses a few interesting problems for code generation,
if efficiency and frugal stack management are important.
Consider `SELECT CASE (I('PREFIX'//A))',
where `A' is CHARACTER*(*)
.
In a case like this--basically,
in any case where largish temporaries are needed
to evaluate the expression--those temporaries should
not be "live" during execution of any of the CASE
blocks.
So, evaluation of the expression is best done within its own block,
which in turn is within the SELECT CASE
block itself
(which contains the code for the CASE blocks as well,
though each within their own block).
Otherwise, we'd have the rough equivalent of this pseudo-code:
{ char temp[large]; libg77_catenate (temp, 'prefix', a); switch (i (temp)) { case 0: ... } }
And that would leave temp[large] in scope during the CASE blocks (although a clever back end *could* see that it isn't referenced in them, and thus free that temp before executing the blocks).
So this approach is used instead:
{ int temp0; { char temp1[large]; libg77_catenate (temp1, 'prefix', a); temp0 = i (temp1); } switch (temp0) { case 0: ... } }
Note how `temp1' goes out of scope before starting the switch, thus making it easy for a back end to free it.
The problem that solution has, however, is with `SELECT CASE('prefix'//A)' (which is currently not supported).
Unless the GBEL is extended to support arbitrarily long character strings
in its case
facility,
the FFE has to implement SELECT CASE
on CHARACTER
(probably excepting CHARACTER*1
)
using a cascade of
if
, elseif
, else
, and endif
constructs
in GBEL.
To prevent the (potentially large) temporary,
needed to hold the selected expression itself (`'prefix'//A'),
from being in scope during execution of the CASE
blocks,
two approaches are available:
CASE
tests,
producing an integer ordinal that is used,
a la `temp0' in the earlier example,
as if `SELECT CASE(temp0)' had been written.
Each corresponding CASE
is replaced with `CASE(i)',
where i is the ordinal for that case,
determined while, or before,
generating the cascade of if
-related constructs
to cope with CHARACTER
selection.
CASE
string
that'll actually be compared against the expression
(in this case, `'prefix'//A').
Since that length must be constant
(because CASE
expressions are all constant),
it won't be so large,
and, further, `temp1' need not be dynamically allocated,
since normal CHARACTER
assignment can be used
into the fixed-length `temp0'.
Both of these solutions require SELECT CASE
implementation
to be changed so all the corresponding CASE
statements
are seen during the actual code generation for SELECT CASE
.
The interactions between statements, expressions, and subexpressions at program run time can be viewed as:
action(expr)
Here, action is the series of steps performed to effect the statement, and expr is the expression whose value is used by action.
Expanding the above shows a typical order of events at run time:
Evaluate expr Perform action, using result of evaluation of expr Clean up after evaluating expr
So, if evaluating expr requires allocating memory, that memory can be freed before performing action only if it is not needed to hold the result of evaluating expr. Otherwise, it must be freed no sooner than after action has been performed.
The above are recursive definitions, in the sense that they apply to subexpressions of expr.
That is, evaluating expr involves evaluating all of its subexpressions, performing the action that computes the result value of expr, then cleaning up after evaluating those subexpressions.
The recursive nature of this evaluation is implemented via recursive-descent transformation of the top-level statements, their expressions, their subexpressions, and so on.
However, that recursive-descent transformation is, due to the nature of the GBEL, focused primarily on generating a single stream of code to be executed at run time.
Yet, from the above, it's clear that multiple streams of code must effectively be simultaneously generated during the recursive-descent analysis of statements.
The primary stream implements the primary action items, while at least two other streams implement the evaluation and clean-up items.
Requirements imposed by expressions include:
Names exported by FFE modules have the following (regular-expression) forms.
Note that all names beginning ffemod
or FFEmod
,
where mod is lowercase or uppercase alphanumerics, respectively,
are exported by the module ffemod
,
with the source code doing the exporting in `mod.h'.
(Usually, the source code for the implementation is in `mod.c'.)
Identifiers that don't fit the following forms are not considered exported, even if they are according to the C language. (For example, they might be made available to other modules solely for use within expansions of exported macros, not for use within any source code in those other modules.)
ffemod
FFEumod_[A-Z][A-Z0-9_]*
#define
or enum
constant of the type ffemod
.
ffemod[A-Z][A-Z][a-z0-9]*
ffemod
is
referred to as ctype
, a capitalized (mixed-case) form
of type
.
FFEumod_type[A-Z][A-Z0-9_]*[A-Z0-9]?
#define
or enum
constant of the type
ffemodtype
,
where type is the lowercase form of ctype
in an exported typedef.
ffemod_value
ffemod_value_input
Below are names used for value and input, along with their definitions.
col
file
find
initialize
int
int
.
is
len
line
lookup
name
text
that points to a name of something.
new
find
without crashing.
pt
run
terminate
text
char *
that points to generic text.
Go to the first, previous, next, last section, table of contents.


--- layout: page title: About header-img: "img/about-bg.png" ---
From the PNW. Ready to make a change from working in the food industry to coding. Somewhat of a runner...


Preparation time
overnight
Cooking time
10 to 30 mins
Serves
Serves 2 as a main, or 4 as a starter
Fresh flavours such as lemon, peas and ricotta are used to balance any earthiness found in the trout.
To cure the trout fillets, mix all the cure ingredients in an airtight container and cover the fillets completely with the mix. Seal with the lid, place in the fridge and leave for 24 hours.
When the fish is cured, cut into pieces and use a chef’s blowtorch to char the skin.
For the preserved lemons, place 100ml/3½oz water, the sugar and vinegar in a pan. Heat until the sugar is dissolved and you have a syrup, remove from the heat. While still warm, add the lemon slices then transfer to a sterilised jar with a lid. Leave for at least 24 hours before using.
Preheat a deep fat fryer to 150C/300F (CAUTION: hot oil can be dangerous. Do not leave unattended).
For the crisps, run the potato slices under cold water for 10 minutes to remove the starch. Drain on kitchen paper.
Meanwhile, mix the lemon juice with the olive oil in a small bowl or jug.
When the potato slices are dry, deep fry them until crisp. Set aside on kitchen paper until ready to serve. Sprinkle with a little salt, if using.
To make a salad, put the mustard cress, peas and wild fennel in a salad bowl. Add the lemon oil and season with salt and pepper, to taste.
To serve, spread the ricotta on the bottom of serving plates. Place the cured trout on top and then the salad. Finish with the crisps scattered around the plate and a few slices of preserved lemon.


plcget(1) Qualcomm Atheros Open Powerline Toolkit plcget(1) NAME plcget - Qualcomm Atheros PLC Get Propery SYNOPSIS plcget [options] [device] [device] [...] DESCRIPTION Read a specific property value from a Qualcomm Atheros powerline device using the VS_GET_PROPERTY message. Properties are selected using their numeric property identifier. Property names are not supported. Property values are printed on stdout in hexadecimal format by default. Alternate formats are ASCII, binary and decimal. Only selected properties can be read using this message type. See the Qualcomm Atheros Firmware Technical Reference Man‐ ual for supported properties and versions. This program is part of the Qualcomm Atheros Powerline Toolkit. See the plc man page for an overview and installation instructions. OPTIONS -a Display output in string format where each byte appears as an ASCII character. Non-ASCII characters are displayed as a period or full-stop. This option is useful for displaying HFID property values. -b Display output in binary format where each byte appears as 8 bits or binary digits. This option is useful for interpreting bit-mapped property values. -d Display output in decimal format where each byte appears as three decimal digits. This option is useful for prop‐ erties with small integer values. -e Redirects stderr messages to stdout. By convention status and error messages are printed on stderr while primary program output is printed on stdout. This option prints all output on stdout in cases where this is desired. -h Display output in hexadecimal format where each byte appears as a hexadecimal octet consisting of two hexadecimal digits. Hexadecimal is the default output format. -n number The property identifier or property version. Property identifiers and versions are entered as 32-bit decimal integers. Property names are not supported. The default is 0. This option may appear more than once on the com‐ mand line. The first occurance specifies the property identifier. The second occurances specifies the property version. See the Firmware Technical Reference Manual for an list of valid property identifiers and versions. -i interface Select the host Ethernet interface. All requests are sent via this interface and only reponses received via this interface are recognized. The default interface is eth1 because most people use eth0 as their principle network connection; however, if environment string "PLC" is defined then it takes precedence over the default interface. This option then takes precedence over either default. -q Suppresses status messages on stderr. -v Prints additional information on stdout. In particular, this option dumps outgoing Ethernet packets on stdout. -?,--help Displays program help information on stderr. This option takes precedence over all other options on the command line except version information. -!,--version Displays program version information on stderr. This option takes precedence over all other options on the com‐ mand line except help information. Use this option when sending screen dumps to Atheros technical staff. ARGUMENTS device The MAC address of some powerline device. More than one address may be specified. If more than one address is specified then operations are performed on each device in turn. The default address is local. See DEVICES for information about symbolic device addresses. DEVICES Powerline devices use Ethernet Media Access Control (MAC) addresses. A MAC address is a 48-bit value entered as 12 hex‐ adecimal digits in upper, lower or mixed character case. Octets may be separated with colons for clarity. For example, "00b052000001", "00:b0:52:00:00:01" and "00b052:000001" are valid and equivalent. The following MAC addresses are special and may be entered by name instead of number. all Same as "broadcast". broadcast A synonym for the Ethernet broadcast address, FF:FF:FF:FF:FF:FF. All devices, whether local, remote or foreign recognize messages sent to this address. A remote device is any device at the far end of a powerline connection. A foreign device is any device not manufactured by Atheros. local A synonym for the Qualcomm Atheros vendor specific Local Management Address (LMA), 00:B0:52:00:00:01. All local Atheros devices recognize this address but remote and foreign devices do not. A remote device is any device at the far end of a powerline connection. A foreign device is any device not manufactured by Atheros. REFERENCES See the Qualcomm Atheros HomePlug AV Firmware Technical Reference Manual for technical information. DISCLAIMER Atheros HomePlug AV Vendor Specific Management Message structure and content is proprietary to Qualcomm Atheros, Ocala FL USA. Consequently, public information may not be available. Qualcomm Atheros reserves the right to modify message structure and content in future firmware releases without any obligation to notify or compensate users of this program. EXAMPLES None. SEE ALSO plc(1), getpib(1), modpib(1), plcset(1), setpib(1) CREDITS Charles Maier<EMAIL_ADDRESS>open-plc-utils-0.0.3 November 2013 plcget(1)


Lola rennt / Run Lola Run
Lola rennt is a movie starring Franka Potente, Moritz Bleibtreu, and Herbert Knaup. After a botched money delivery, Lola has 20 minutes to come up with 100,000 Deutschmarks.


Documentation Site Build and Deploy Instructions
- Install Choclately
- Install via Powershell
Set-ExecutionPolicy Bypass -Scope Process -Force; iex ((New-Object System.Net.WebClient).DownloadString('https://chocolatey.org/install.ps1'))
- Detailed instructions found at - https://chocolatey.org/install
- Install DocFx via Chocolately
- In Powershell run
choco install docfx
- Clone RogueSharp
git clone git@github.com:FaronBracy/RogueSharp.git
- Clone RogueSharp.Documentation
git clone git@github.com:FaronBracy/RogueSharp.Documentation.git
- Ensure that the root directories for both RogueSharp and RogueSharp.Documentation are at the same level.
- Build the API Documentation
- Navigate to the RogueSharp.Documentation root directory
- Run
docfx metadata
- Build the DocFx site
- Run
docfx build
- Serve the site locally to preview
- Run
docfx serve .\_site\
- Browse to
http://localhost:8080/
to see the site
- Publish the DocFx site
- Copy everything from the
RogueSharp.Documentation\_site
folder in RogueSharp.Documentation
- Paste the contents into the
RogueSharp\Docs
folder
- Push to Github


My name a Borat. I come from Kazakhstan. Can I say a first, we support your war of terror! May we show our support to our boys in Iraq! May US and A kill every single terrorist! May your George Bush drink the blood of every single man, women, and child of Iraq!
I arrived in America's airport with clothings, US dollars, and a jar of gypsy tears to protect me from AIDS.
Um, at the start, she was a cook good, her vazhïn work well, and she strong on plow. But after three years, when she was 15, then she become weak. Her voice become a deep. "Borat, Borat." She a receive hair on her chest and her vazhïn hang like sleeve of wizard.


--- title: Hough Transform keywords: fastai sidebar: home_sidebar nb_path: "00_core.ipynb" ---
class
Hline
Hline(*args)
args
a class is used to record the details of lines extracted by Hough Transform
ImageBuffer
ImageBuffer(**kwargs)
kwargs
it is use to record the buffer image details of powerline corridors
grid_subsampling
grid_subsampling(points, voxel_size)
points
voxel_size
Define a function that takes as input an array of points, and a voxel size expressed in meters
getDirctionVectorsByPCA
getDirctionVectorsByPCA(pca)
pca
calculate the direction vectors of PCA in a point cloud
pointsProjectAxis
pointsProjectAxis(abc, startPoint, pts)
abc
startPoint
pts
calculate the points that are mapped onto the pca lines from a point cloud
radiusOfCylinderByLeastSq
radiusOfCylinderByLeastSq(**kwargs)
use least square algorithm to calculate the radius of a cylinder
get_start_end_line
get_start_end_line(pts)
get the starting point and end point of a line
cylinderSurface
cylinderSurface(**kwargs)
generate the surface of a cylinder
extractFeathersByPointCloud
extractFeathersByPointCloud(**kwargs)
calculate the axis length sphericity, linarity and planarity of a point cloud
pointsToRaster
pointsToRaster(**kwargs)
Transform a point cloud to a raster image
getCellIDByPolarCoordinates
getCellIDByPolarCoordinates(**kwargs)
Get the indices of cells according to polar coordinates
houghToRasterByCellID
houghToRasterByCellID(**kwargs)
Transform the result of Hough transform to a raster image
recordHoughLines
recordHoughLines(**kwargs)
encapsulate each hough line into a class HLine and save all hough lines in an array
countNumOfConsecutiveObj
countNumOfConsecutiveObj(*args)
count the number of consecutive 0
calRowByColViaLineEquation
calRowByColViaLineEquation(**kwargs)
compute row:y according to col:x based on a line equation
generateCorridorByLine
generateCorridorByLine(**kwargs)
generate a powerline corridor in a raster image
generateBuffer
generateBuffer(**kwargs)
generate buffer zone based on the hough transform
locatePointsFromBuffer
locatePointsFromBuffer(**kwargs)
obtain points from original point cloud base on the image buffer
locatePointsFromBufferSlideWindow
locatePointsFromBufferSlideWindow(**kwargs)
getFeaturesFromPointCloud
getFeaturesFromPointCloud(**kwargs)
obtain the features of each point
evaluateLinesDiscontinuity
evaluateLinesDiscontinuity(**kwargs)
evaluate the extent of lines' discontinuity, which is to calculate the maximal length of discontinuous lines
constructCorridorsByHT
constructCorridorsByHT(**kwargs)
Construct corridors based on the lines extracted by Hough transform
getPointsFromSlideCorridors
getPointsFromSlideCorridors(**kwargs)
get the points in slide corridors
constructSlideCuboidsByPointCloud
constructSlideCuboidsByPointCloud(**kwargs)
construct slide cuboids based on a point cloud
extractLinesFromCorridor
extractLinesFromCorridor(**kwargs)
extract power lines from a corridor by a slide cuboid
generateSlideWindowByX
generateSlideWindowByX(**kwargs)
extractLinesFromPointCloud
extractLinesFromPointCloud(**kwargs)
extract lines from a point cloud. it combines other functions
secondHTandSW
secondHTandSW(**kwargs)
second slide window and Hough transform


Widget
click any of these components below
Front of Panel Widget
Front of Panel content Widget
Back of Panel Widget
Back of Panel content Widget


{{eventstream.created}}
{{eventstream.content}}
Stay updated on the newest happenings on DJ ELO!
A big part of why DJ E-LO began DJing was to help raise money for charity. DJ E-LO is a big supporter of the St. Jude Children's Research Hospital. St. Jude works tediously to treat cancer and other life-threatening diseases for children. Part of what makes St. Jude so great is that care is absolutely free, so no child gets refused treatment for financial reasons. As a result, these children rely on the generousity of donors to receive their treatment. Click here to support this amazing cause!


{% endfor %}
{% if SOCIAL %}
{% for service in SOCIAL %}
{% endfor %}
{% endif %}
Research focus
I am interested in the allocation of managerial talent in the macroeconomy. My research is supported by the Forefront Research Excellence Program and an ERC Advanced Grant.


Registering a Custom Converter
Normally, you'd register converter to the class you are writing, and in that case the easiest thing to do is to write a nested type "ConverterImpl", that gets picked up automatically. If you search by that class name, you'll see a number of implementations.
Registering a Custom Converter without modifying the original class
If you want to register a custom XStream converter that will convert items that have already been persisted to disk, and you don't want to modify the source code for the class you want to convert, then you need to hook it in to Hudson before it reads in those items. Here's one way that works:
public class MyPlugin extends Plugin { public void start() throws Exception { Items.XSTREAM.registerConverter(new MyCoolConverter()); } }
The Items.XSTREAM
portion should be adjusted to point to the right XStream instance (such as Hudson.XSTREAM
), depending on which persistence your object participates. The converter would look something like this:
import com.thoughtworks.xstream.converters.Converter; public class MyCoolConverter implements Converter { public void marshal(Object source, HierarchicalStreamWriter writer, MarshallingContext context) { throw new UnsupportedOperationException("Sorry, no example for marshalling yet!."); } public Object unmarshal(HierarchicalStreamReader reader, UnmarshallingContext context) { // Traverse the reader to get structure and attributes of the thing you're converting from return new MyThing(some, attrs, etc); } public boolean canConvert(Class type) { return my.plugin.special.MyThing.class == type; } }


Craigslist made easy, efficient, & safer for free.
Click next.
Welcome to the Homer tutorial.
Here you wil learn how to use our extension to make your renting experience better! Learn about our renter ticket, auto-applications, & more!
Make a profile!
Your first impression is your best. Your profile will be used in our renter ticket. A renter ticket is a clear and concise template email that will be sent to the landlord with one click of a button.
Auto applications!
As you look through Craigslist, you can send applications to listings you are interested in using the Reply Using Homer button.
Find a home
Simple. Quick. Efficient. Save time and move in faster with Homer.
Sign up


Use this page to understand how Involution Studios and our service providers release and secure your PHR Data.
Release |
||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Do we release your PHR Data for these purposes? | No |
|
||||||||||||||||||
| Do we require Limiting Agreements that restrict what third parties can do with your Personal Data? | N/A | |||||||||||||||||||
| Do we stop releasing your Personal Data if you close or transfer your PHR? | N/A | |||||||||||||||||||
Secure |
||||||||||||||||||||
|
We have security measures that are reasonable and appropriate to protect personal information, such as PHR Data, in any form, from unauthorized access, disclosure, or use. |
||||||||||||||||||||
| Do we store PHR Data in the U.S. only? | Yes | |||||||||||||||||||
| Do we keep PHR Data activity logs for your review? | Yes |
“PHR” stands for a web-based Personal Health Record. A web-based PHR is an electronic health data application that can help you collect, manage, and share your health information. Web-based PHRs may be offered by a hospital, insurance company, employer, or a commercial vendor.
When you sign up for a PHR, you provide, or the PHR company or its service providers, import information about you that becomes the PHR Data. Any information in your PHR is considered PHR Data. PHR Data might include, but is not limited to:
A PHR company (and its service providers) may use your PHR Data to:
Personal Data and Statistical Data are the two types of PHR Data.
Personal Data is any PHR Data that connects to you as an individual such as names, health conditions, and other identifiers.
Statistical Data is PHR Data that is 1) grouped so it does not connect to you as an individual and 2) has names and other identifiers removed or altered.
Personal Information includes your PHR Data, as well as any other information about you that can be reasonably linked to you. Personal Information can also include but is not limited to your financial information or social security number.
Companies and their services providers might report about their business activities and their customers (you) to others, such as investors, auditors, potential business partners, or public communities.
Limiting Agreements are legally binding agreements that prohibit certain third parties, which are not the PHR company’s service providers, from releasing your Personal Data or re-identifying individuals. Third parties can include advertisers, researchers, and others who receive PHR Data.
A service provider is an entity that is hired to perform certain functions for and operate under the direction and control of the PHR company. Service providers may include software or website designers and data storage providers.
Security measures can include computer safeguards, secured files, and employee security training. PHR companies may be required by law to notify you about particular data breaches.
When PHR Data is stored in the United States, U.S. law enforcement agencies may be able to prosecute if the data is stolen or breached.
Activity logs are the PHR company and its service providers’ records of when PHR Data is created, accessed, modified, deleted, released, or exported in the PHR program.
The practices described in this notice only apply to Involution Studios and its service providers. These practices do not apply to any other organizations, links, websites, programs, or applications that may be available through Involution Studios or its service providers. Always read the policies of any company, website, application, or service where you provide your Personal Information.
This notice is not intended to be a substitute for communicating the full privacy and security policies of Involution Studios. We encourage you to learn more about our privacy and security policies (including options that may allow you to opt out), by visiting our full privacy policy.
Rev. August 25, 2015


filmcritic.com presents a review from staff member Jeremiah Kipp. You can find the review with full credits at http://www.filmcritic.com/misc/emporium.nsf/2a460f93626cd4678625624c007f2b46/d7cc03e1b789d91b882568ff000f6c7d?OpenDocument
TIME REGAINED (LE TEMPS RETROUVE) A film review by Jeremiah Kipp Copyright 2000 filmcritic.com filmcritic.com
A literal adaptation of the final book of Marcel Proust's Remembrances of Things Past would be inconceivable and boring, since the tastes and smells which reveal layers of memory cannot be captured onscreen. Raoul Ruiz's Time Regained does the next best thing. Ruiz weaves a fragmented, experimental narrative in the form of a tapestry. There's an uncanny beauty achieved by telling his story in this manner, which reveals thoughts and inactions by using the very limitations of the film medium. He presents us with a series of photographs, or images shot into mirrors or through doorways which open up to the past and present (and cross-cut between the two with relative ease.)
Taking place within the huge estates and manor houses of the cultural elite, with string quartets playing in their studies and tiny cakes neatly arranged on trays in their kitchens, our main character, Marcel (Marcelo Mazzarello) wanders through this world drinking it in. The plot is inconsequential, it is more about observing the crowded rooms and bitten back emotions, the sips of wine and soft handshakes. Every now and then, Marcel is forced to confront his decadent relatives (sneeringly funny John Malkovich and sour Pascal Greggory.)
Ruiz cleverly stages a prologue with the elder Proust (Andre Engel, voiced by filmmaker Patrice Chereau) wasting away in his bedroom, the best years of his life behind him, reciting passages from his book to his servant girl and allowing the objects in the room to trigger thoughts about his family, his would-be lovers (particularly Odette, the woman who haunts him his entire life, played by the elegant Catherine Deneuve) and loved ones, his enemies and his false friends.
Ruiz is a master at keeping his themes and meaning palatable and comprehensible even when shifting from the main character's childhood to middle age, or having the child and adult version of the protagonist onscreen at the same time. It doesn't feel pretentious, since Ruiz clearly has a sincere fondness for this main character. The stand-in for Marcel Proust, Mazzarello, doesn't emote very much as he wanders aimlessly through the elegant locations, but he has deep and friendly eyes and a sad smile half hidden under his moustache.
Marcel finds himself jumping back and forth in these memories, and one starts to wonder how much he has romanticized that past? He may be remarkably similar to the stuffed shirts who surround him, sitting in their circles, smoking cigars and wondering who's who in terms of reputation and their place in the ladder of class structure. Ultimately, those things don't matter, and fade away. In the film's best scene, we see his half mad colleague and former nemesis, Charlus (Malkovich) lead him through the park as they discuss their old friends. `How is this one…? Mort. How is that one? Mort.' In the dialogue within this exchange,. Proust's philosophy is revealed. Things fade away, and all we have is this small, precious present moment in time – everything else passes into dust.
It's a difficult film to catch hold of, and demands enormous patience and a willingness to allow yourself the ability to drink in this film, as though it were some very rich cake to be savored.  It's not for every occasion, though, or for every audience. Those unwilling to submit to a slow paced, metaphysical project may quickly grow frustrated with this item, but if you allow it to be an interactive experience, you may well consider memories of your own through the process of watching – and that's worth more than any film could offer.

To unsubscribe from filmcritic.com's Breaking Reviews mailing list, reply to this e-mail with UNSUBSCRIBE as the subject. E-mail address changes via reply with both old and new addresses.
The review above was posted to the
rec.arts.movies.reviews newsgroup (de.rec.film.kritiken for German reviews).
The Internet Movie Database accepts no responsibility for the contents of the
review and has no editorial control. Unless stated otherwise, the copyright
belongs to the author.
Please direct comments/criticisms of the review to relevant newsgroups.
Broken URLs inthe reviews are the responsibility of the author.
The formatting of the review is likely to differ from the original due
to ASCII to HTML conversion.
Related links: index of all rec.arts.movies.reviews reviews


Props to reveal.js for the slideshow awesomeness.reveal.js
Super awesome MVC framework for PHP
Symfony is an Open Source distributed PHP framework.
You don't need a framework to develop in PHP, but they sure make life easier.
Some reasons to use Symfony:
Staying Power
It was created by Sensio Labs, and they've been doin this stuff for like,
a long time - more than 12 years. So they've got this.
Some reasons to use Symfony:
Reputation/References
Yahoo!, Dailymotion, Opensky.com, Exercise.com
and even applications such as phpBB, Drupal, and now
Franklin American Mortgage Company has joined the list...
Some reasons to use Symfony:
Interoperability
Sensio Labs is instrumental in PHP standards (PHPUnit,
naming conventions, code style). Creator Fabien Potencier
is a voting member on the PHP Framework Interoperability Group
The framework is built via core components that can even be
pulled out and used individually or in smaller groups. One popular
example is the micro-framework Silex, built by Sensio Labs via these
components.
Drupal 8 is slated to adopt many core Symfony2 core components such as
HttpFoundation, Routing, and ClassLoader.
Some reasons to use Symfony:
Resources
Fear not! You aren't alone in your Symfony development. Symfony has a
strong developer community, including some right here in Nashville.
Nashville has a growing PHP Dev community to which FAMC could be
a contributing member.
Some reasons to use Symfony:
TL;DR
You can’t go wrong by choosing Symfony!
And no one has ever been fired for using Symfony.
Symfony Structure
app
src
vendor*
web
Symfony Structure
APP
Application Configuration
Brain Matter
Cache*
Logs*
PHPUnit Config
Universal Resources
Symfony Structure
APP - console
php app/console
Cache Control
Convenience Functions
Bundle Generation
Entity Generation
Form Generation
Database Tasks (db/schema - crud)
Maintanence/Debug Tasks
Deploying bundle js/images/css
Configuration Debugging
Router Debugging
Symfony Structure
SRC
Home of your Code!
Bundles
App Specific Code
Models Views Controllers
*Should Follow PSR-0
* - PSR-0 PHP-FIG Standard for Class Naming and Namespaces
Symfony Structure
VENDOR
Symfony code
Third Party Libraries/Bundles
Autoloading!
Vendors and you working together to support YOUR app!
Symfony Structure
WEB
Gateway to the West App.
app.php
app_dev.php
Bundle Public Resources (css/images/js)
Bundles
Modularity
A great strength of Symfony is all the seperate pieces
A collection of code wrapped up for use in Symfony
Symfony Specific
Wrapper or Connector For Other Library
Mini-Projects
Bundles
Examples
FOSUserBundle
Doctrine - DoctrineBundle
Symfony
Bundles
Structure
Controller
DependencyInjection
Entity
Form
Resources
Service
Tests
Bundles
Models, Views, and Controllers Oh My!
Unique Entities (Models) - Bundle/Entity
Unique Controllers - Bundle/Controller
Unique Views - Bundle/Resources/views/...
Bundles
CONTROLLER
Can Have Multiple
Group Actions By Topic
Action Functions - must end with Action
Bundles
DEPENDENCY INJECTION
Where the idea of the DI container lives
services.(php|xml|yml)** is read in
** -- lives elsewhere
Bundles
ENTITY
Models
Representative of entries in db
Annotations
Can Define DB Schema
Bundles
FORM
Web Forms for Models
Can be bound to request parameters - no need to parse request
Overly Complicated in their Simplicity
Bundles
RESOURCES
Config - services.(php|xml|yml)
public
css
images
js
Translations
views
Bundles - Named based on controller
base.html.twig
Bundles
SERVICE
Service classes live here
What is a Service?
... a Service is any PHP object that performs some sort of "global" task. It's a
purposefully-generic name used in computer science to describe an object that's created for
a specific purpose (e.g. delivering emails). Each service is used throughout your application
whenever you need the specific functionality it provides.


7 January 2014 - On 31 December 2013 Taipei Centers for Disease Control (CDC) reported a laboratory-confirmed case of human infection with avian influenza A(H7N9).
The patient is an 86 year-old man from Jiangsu, China who travelled to Taiwan, Province of China, with a tourist group from 17-24 December. He felt uncomfortable on 19 December, and was admitted to a hospital on 24 December after being diagnosed with bilateral pneumonia and acute respiratory distress syndrome. The patient is currently intubated and supported by extracorporeal membrane oxygenation. The other tour members have returned, except for the two daughters of the patient who remained and showed no symptoms.
So far, there is no evidence of sustained human-to-human transmission.
WHO does not advise special screening at points of entry with regard to this event, nor does it currently recommend any travel or trade restrictions.


When you work with us, you are part of a team of commited collaborators.
All aspects of our software development process are intergrated ,
interactive
and agile.
approach unifies design, development and product managent
to create exceptional products.
We start each project by understanding your business goals,
the users needs and the product requirements.
we help translate them into active and elegant solutions.
DESIGN
All engineers are fluent in the latest enterprise, mobile and web development technologies. They collaborate with your team to write, and improve code on a daily basis, using proven practices such as test-driven development and pair programming.
DEVELOPMENT
PRODUCT MANAGEMENT
DELANI STUDIO
2019


Fits hierarchical models of animal abundance and occurrence to data collected using survey methods such as point counts, site occupancy sampling, distance sampling, removal sampling, and double observer sampling. Parameters governing the state and observation processes can be modeled as functions of covariates.
| Version: | 0.12-2 |
| Depends: | R (≥ 2.12.0), methods, reshape, lattice, parallel, Rcpp (≥ 0.8.0) |
| Imports: | graphics, stats, utils, plyr, raster |
| LinkingTo: | Rcpp, RcppArmadillo |
| Published: | 2017-05-15 |
| Author: | Ian Fiske, Richard Chandler, David Miller, Andy Royle, Marc Kery, Jeff Hostetler, Rebecca Hutchinson |
| Maintainer: | Andy Royle <aroyle at usgs.gov> |
| License: | GPL (≥ 3) |
| URL: | http://groups.google.com/group/unmarked, https://sites.google.com/site/unmarkedinfo/home, http://github.com/ianfiske/unmarked, http://github.com/rbchan/unmarked |
| NeedsCompilation: | yes |
| SystemRequirements: | GNU make |
| Citation: | unmarked citation info |
| Materials: | README NEWS |
| In views: | Environmetrics |
| CRAN checks: | unmarked results |
| Reference manual: | unmarked.pdf |
| Vignettes: |
Capture-recapture Dynamic occupancy models Distance sampling analysis Species distributions Overview of unmarked |
| Package source: | unmarked_0.12-2.tar.gz |
| Windows binaries: | r-devel: unmarked_0.12-2.zip, r-release: unmarked_0.12-2.zip, r-oldrel: unmarked_0.12-2.zip |
| OS X binaries: | r-release: unmarked_0.12-2.tgz, r-oldrel: unmarked_0.12-2.tgz |
| Old sources: | unmarked archive |
| Reverse depends: | AHMbook, DiversityOccupancy |
| Reverse imports: | AICcmodavg, AMModels, nmixgof |
| Reverse suggests: | auk, camtrapR |
| Reverse enhances: | MuMIn |
Please use the canonical form https://CRAN.R-project.org/package=unmarked to link to this page.


Photo: The Hypercity of Shanghai by Trey Ratcliff , licensed under CC BY NC SA 2.0
14 INTERNATIONAL PROJECTS
- Traffic Flow Modelization•
- Collaborative Surveillance in Sensor Network•
- Engineering Design of Cities•
- Platform for Sustainable Practices•
- Smart City Logistics•
- City Health Monitoring•
- Traffic Sound Analysis•
- Web Mobility Analysis•
- BLM & Serious Gaming•
- Digital Footprint of City•
- Urban Metabolism & Sustainability•
- Digital Eternities•
- Home Energy Management•
- urban Socio-Cultural Transition•


Monthly Meeting News
|
June 19, 2010 Neal Tew (KD0MBL) and David Yeater (studying for his Technician license) are the newest members of the Pueblo West Amateur Radio Club. Both are members of the club's ham class as well. Neal, from Pueblo West, received his call letters on Friday, June 18. David, from Pueblo, will be taking his Technician exam in August. Other members attending the meeting were:
Jim - NE0DA News From Members Kirk reports he is continuing to study for his General license and will be taking the test in August. Ralph's Yaesu FT-1000 may have had an unfortunate encounter with a close lighting strike. He is attempting to have it fixed. In the meantime, he has purchased a second rig. Bill (W0NHF) has been having a great time on 6 meters and reported he has been hearing several openings both from the East and West, as well at to Canada and the Mediterranean area. He has also been working 10 meter openings. Paul stated he had not been very active in the last month, and that he had been vacationing in the mountains for the past four days. Jane topped the list as being the most active of the members in the last month. She has been working Special Event stations, and a little DX. She worked Special Event stations for the 30th Anniversary of the Eruption of Mt. Saint Helens, the Indianapolis 500 race, the Pony Express Re-ride, and the Battleship Missouri in Pearl Harbor during the Ship Museum Weekend. She also made her first PSK31 contact last week in preparation for Field Day, and then topped that off with a contact with a ham in Tasmania! Andy has been learning more about his Yaesu FT-817 and has many of the local repeaters in its memory now. Bill (KB0RPD) has been spending many hours working with the American Red Cross and also just returned from a trip to Yellowstone National Park. His next project will be to install an MFJ window antenna feedthrough at his home. Jim stated that he has been getting ready for Field Day. He has picked up four 18 Ah batteries donated by the National Weather Service office at Pueblo for use at Field Day. He will connecting them in parallel this week. Bill (WA0KAQ) had also worked some 6 meter stations during openings the first week of June. His only contact before that opening was to Oregon, where he worked four stations. During this opening, he added 15 more states and a Canadian mobile. He also worked Samoa for the first time, using CW. He reported that his FT-897D which was to be used at Field Day was having problems, and that there was not enough time to have it repaired before the event. He purchased a new FT-897D. The original rig will be repaired and sold. Treasurer's Report (NG0T): Dan was unable to attend the meeting. No known bills have been presented since the last meeting, but $300.20 from the bake sale was deposited. Unofficially, the club has approximately $685.60 in its treasury. Ways & Means Report (KA0USA): Thanks to the efforts of NE0DA, ND0P, KB0RPD, NG0T, WA0KAQ, KA0USA, KB0JIT, KA0RER, W0NHF and XYL Sharron, KC0QJK, KG6WSI, NI5R and KD0LDH, the May 23 Bake Sale Walmart was a huge success. We had almost 7 dozen cookies left from the bake sale, and they were frozen and will be used as part of the refreshments at next weekend's Field Day event. Some additional cookies have also been purchased. The club will also have ice water and iced tea at the event. Training Coordinates Report (KB0JIT): Classes are temporarily on hold until after Field Day due to the loss of the room at the Pueblo West Fire Department. Alternative sites are being explored, including a Recreation Department location. Congratulations go out to two ham class students who passed their Technician exams at the June 12 VE session in Pueblo. They are Jeff Estabrook (KB0MBK) and Neal Tew (KD0MBL), both of Pueblo West. WA0KAQ asked if information packets for new students would be helpful and was told they would be appreciated. The packets will be produced in the near future. Old Business: 1) Change in Constitution WA0KAQ requested a revision to change the number of votes needed for changes to the Constitution. The club visited this issue before, but no action was taken. WA0KAQ stated it is getting more difficult to contact a quorum of members It was noted that the club probably only had a quorum of its members at a meeting twice in the history of the club, and this has caused a lot of extra work on the Secretary's part to call and e-mail members each time a change is necessary. The Constitution allows for polling members either by phone or e-mail when issues may be decided. More changes will need to be made to the club's Constitution this summer and fall, primarily dealing with detailing with establishing terms of office, duties, etc, for the Board of Directors; and 2) changing the club's corporate status to a non-profit corporate status. It was proposed that the required vote of "2/3 of the licensed members" be changed to a vote of "2/3 of the licensed members present at the meeting where changes are discussed." The monthly agenda always references proposed Constitutional changes, allowing members to come to the meeting and voice their opinions. A motion was made by Paul, KB0JIT, to change the wording as described above, and this was seconded by Jane, KA0USA. The vote was 10-0 in favor of the change. Under the current wording, however, at least 5 more affirmative votes are needed, and the Secretary will make e-mail contacts, and telephone contacts as necessary to poll the members who were absent. 2) Board of Directors At the May meeting, the secretary was requested to write new language for the Constitution pertaining to the newly-elected Board of Directors. However, since the club has established no guidelines as to the Board's duties, length of the Directors' terms, when elections will take place, etc., the Constitution can not be amended at this time. WA0KAQ suggested that the treasurer, NG0T, be enlisted to help write the necessary language. Since the treasurer was absent, further discussion was tabled until the next regular meeting. 3) NWS Batteries NE0DA has the latest donation of four 18 Ah batteries from the National Weather Service and a 34 Ah battery donated earlier. These will be used with his laptop at Field Day. KB0RPD reported that some batteries received from a different source were no good and would be recycled. As we get batteries to give out, those hams who are active on the air will get them first. The hams who are active and present at the meetings and don't have batteries yet can put their names in a hat, and names will be drawn for the available batteries. Those who receive batteries will need to buy a small (1-amp) charger if they don't have one. It should be the type that changes to a trickle charge once the battery is charged. Chargers without this feature can damage the batteries if left on too long. W0NHF has a good one (1.5 amps maximum) he bought at Walmart for about $20, and will be glad to tell you about it. 4. Tax Filing/Corporation update Since the treasurer was absent, this item was tabled until the next meeting. 5. ARRL Affiliation The ARRL issued the club a Charter of Affiliation on June 2, 2010. In order to keep this affiliation, the club must retain a 51% ARRL membership. One of the benefits allows us to do is to keep $15 of any new ARRL membership fee (which is $39 annually), and $2 of any membership renewal fee, if it is filed through the club. If you are planning to join the ARRL and get QST Magazine, please file through the club. ARRL membership application forms from the secretary. The club can also take credit cards for part of the ARRL membership. Applicants pay the club $15, and ARRL will accept the rest ($24) by credit card if you so desire. If not, the club will accept your check made out to ARRL, and send it to them. WA0KAQ requested permission to purchase a frame for the certificate, as well as frames for the Proclamation received from the Pueblo West Metropolitan District Board and for the club's ham license. KB0JIT made a motion that the documents be framed, and KA0RER seconded the motion. The club was agreed this should be done. However, new member David Yeater stated he had some frames and volunteered to frame the Proclamation and ARRL Affiliation Certificate. A frame will be purchased for the club license. New Business: 1) Rag Chew There will be no Rag Chew on July 3 because of the 4th of July holiday weekend. 2) Proclamation NE0DA presented the club with a Proclamation from the Pueblo West Metropolitan District Board proclaiming the fourth week of June as Amateur Radio Week. The Proclamation was presented at the Board's June 8 meeting. 3) Megafest NE0DA proposed that the club have a Field Trip next month and carpool to Monument, CO, to the Megafest swapmeet. There was general agreement that this could be a good experience. The swapfest runs from 8 a.m. to 1 p.m., and more information can be found in the calendar at the club's website. Our regular July meeting WILL be held as scheduled at 2 p.m. 4) Upcoming VE Session Pueblo Ham Club will hold its August VE session from Noon until 2 p.m. on Saturday, August 21, at the Pueblo West Library. Our club's regular monthly meeting will be held at 2 p.m. as normally scheduled. 5) Field Day WA0KAQ reported that since the last meeting, invitations to Field Day have been extended to the staff of the National Weather Service, Pueblo; Buffy McFadyen, State Rep. from Dist. 47; Pueblo County Commissioners, and the Pueblo County District 70 Board of Education The club has received handouts from about a dozen companies who have sent literature to us for handouts at Field Day. ND0P has finished the Field Day signs. An article about Field Day has been sent to the Pueblo View, as well as a short article about the Amateur Radio Week Proclamation and a photo of NE0DA receiving it from the Metro Board. It is unknown whether the new editor will use any of this, but we have tried to get publicity. A walk-through of the set up was held during the meeting. Webinars On April 22 and May 19, WA0KAQ participated in ARRL Public Relations Webinars about how to promote Field Day. They were conducted by the ARRL's Atlantic Division. One of the things stressed was that outside of an actual disaster, Field Day is by far the one day each year that the public gets to see Amateur Radio in action. The presenters also stressed, "You don't get a second chance to make a good first impression." People perceive us as they see us, so it is important that everyone be well-groomed and well dressed for the event. So comb your hair and brush your teeth, and you might want to bring an extra set of clothes along that you can change into after the antennas, shades, and other things are put up on Saturday. If someone asks you what Amateur Radio is and what we are doing, each person needs an answer. The presenters suggested that everyone rehearse a 30-second summary of what Amateur Radio is. I don't believe that is necessary, however everyone should think about what he would say if asked. Basically we want to get the point across that: 1) we are not CBers 2) we are hobbyists licensed by the FCC after we pass its tests 3) that we do not rely on any other form of communication such as telephones or the Internet, and 4) that we are practicing emergency deployment procedures to ensure we are capable of providing back-up communications for any public service agency that requests it should an emergency situation occur. 5) Amateur Radio is our hobby, and we do not receive compensation for our volunteer work. The club's first annual Field Day exercise will be held Saturday and Sunday, June 26 & 27, at Cheers Plaza, 334 S. McCulloch Blvd. More information about Field Day can be found on the club's website: http://www.qsl.net/na0pw/FieldDay.htm Program: WA0KAQ gave a short program about using the N3FJP Field Day logging software. Coming Events: Sat. & Sun., June 26 & 27 - Field Day, Cheers Plaza. Each Tuesday evening -- VHF net on 146.445 MHz FM simplex at 7:00, and an HF net on 28.305 MHz USB at 7:30 p.m. Sat., July 17 - 8 a.m.-1 p.m. - Megafest swapfest at Monument. Some members will be carpooling. Sat., July 17, 2:00 p.m. - Monthly PWARC Meeting at 2:00 p.m. at Pueblo West Library.
Submitted by William E. Ewing, WA0KAQ |


A simple web page to simulate a client side to execute a measurement plan to evaluate a Discrete System Performance


There are no research publications available for this year.
{% else %} {% for publication in all_2023_publications %} {% include publication_article_citation.html %} {% endfor %} {% endif %}There are no research publications available for this year.
{% else %} {% for publication in all_2022_publications %} {% include publication_article_citation.html %} {% endfor %} {% endif %}There are no research publications available for this year.
{% else %} {% for publication in all_2021_publications %} {% include publication_article_citation.html %} {% endfor %} {% endif %}There are no research publications available for this year.
{% else %} {% for publication in all_2020_publications %} {% include publication_article_citation.html %} {% endfor %} {% endif %}There are no research publications available for this year.
{% else %} {% for publication in all_2019_publications %} {% include publication_article_citation.html %} {% endfor %} {% endif %}There are no research publications available for this year.
{% else %} {% for publication in all_2018_publications %} {% include publication_article_citation.html %} {% endfor %} {% endif %}There are research publications available for this year.
{% else %} {% for publication in all_2017_publications %} {% include publication_article_citation.html %} {% endfor %} {% endif %}There are no research publications available for this year.
{% else %} {% for publication in all_2016_publications %} {% include publication_article_citation.html %} {% endfor %} {% endif %}


Results:{{( management.users | filter: advancedSearchFilter | limitTo: management.searchLimit ).length }}
Sorted by: {{management.sort}}
loading...


I have an RTFM sticker on my laptop, but it's not because I'm in favor of spouting off "RTFM" to any poor noob who had the misfortune of asking a simple question. I have the sticker on my laptop as a reminder to myself that I don't want to live in an RTFM world.
I've been in many circumstances where the "FM" is either incomplete, inaccessible, out of date, or completely absent. Furthermore, I want to live in and foster an environment where it's okay to ask (and answer) questions. Even (especially) simple questions with pre-existing easy-to-find answers. I want to be a part of an open and welcoming learning community. Manuals were not made for beginners, they were made for experts as a thorough and concise description of a tool.
The RTFM mindset does nothing to increase the amount of freely available knowledge in the world, and I'm inclined to argue that it even does nothing to benefit the world. By answering (or even pointing someone to the answer) we leave the world better than we found it.
That isn't to say I don't understand the temptation though. However, I firmly believe that it is never acceptable to sit on our lofty pedestal of natural, innate, instinctive, and completely intuitive mastery of technical skills while looking down on someone so unfortunate as to not be in our position.
This doesn't relieve people from the responsibility to do their own work, and put forth effort in finding the information they need; This rant isn't at all related at the people asking the questions, it's a critique of those answering the questions.
I believe we should treat
these
all people with dignity, respect, and patience (deserved because they're human beings, not because of
anything they did/didn't do). If we can't be bothered to give a constructive answer, at the very least
we can point them to the answer a la
LMGTFY
.
Please think about your words before you respond to irritation.


fun Int.revert(): ByteArray
Returns an array of bytes with the underlying data used to represent an integer in the reverse form. This is useful for endianess switches, meaning that if you give this function a big-endian integer it will return it's little-endian bytes.
Return
The array of bytes that represent this value in the reverse format.


PTARDIFF
Section: Perl Programmers Reference Guide (1)Updated: 2012-06-22
Index Return to Main Contents
NAME
ptardiff - program that diffs an extracted archive against an unextracted oneDESCRIPTION
ptardiff is a small program that diffs an extracted archive against an unextracted one, using the perl module Archive::Tar. This effectively lets you view changes made to an archives contents. Provide the progam with an ARCHIVE_FILE and it will look up all the files with in the archive, scan the current working directory for a file with the name and diff it against the contents of the archive.
SYNOPSIS
ptardiff ARCHIVE_FILE ptardiff -h $ tar -xzf Acme-Buffy-1.3.tar.gz $ vi Acme-Buffy-1.3/README [...] $ ptardiff Acme-Buffy-1.3.tar.gz > README.patch
OPTIONS
h Prints this help message
SEE ALSO
tar(1), Archive::Tar.
Index
This document was created by man2html, using the manual pages.
Time: 05:29:09 GMT, December 24, 2015