text:
Symbols in SRC-SCCS
The SCCS back end to SRC doesn't support named symbolic references to numbered revisions, because SCCS masters don't include a symbol table. This is one of the things RCS added.
Goddess help me, I've figured out how to shoehorn in this feature. And probably should not do it.
A nearly forgotten feature of both SCCS and RCS masters is the "descriptive text" field, one per master. When this was used it was normally set at master creation time to convey the purpose of the file for which the master is keeping history. But it can be modified after master-creation time.
The trick: swipe this field. if empty, and use it as an attribute-value dictionary encoded as a JSON object. If it's nonempty, and doesn't begin with a '{', exit with a warning rather than stepping on legacy data.
Now, in the SCCS back end, one attribute (initially the only one) can be a symbol table. Voila!
I shouldn't do this. The odds of anyone wanting to use the SCCS back for production in 2016 are minimal. But I am tempted by a mad completist urge…
This entry was posted in Software and tagged version-control by esr. Bookmark the permalink.
69 thoughts on "Symbols in SRC-SCCS"
LS on 2016-02-11 at 02:37:43 said:
You're not gonna need it……you're not gonna need it…..repeat after me….you're not gonna need it!
Take a deep breath. Now go play with Zola.
Holy heck that is dirty. I like it.
John Dougan on 2016-02-11 at 03:29:42 said:
Does the text field have a large fixed length or unlimited? If so, make the is-this-json check work on a longer chunk of text (maybe arrange for a magic key value pair to come first in the dictionary). I've had to do tricks like your proposed hack before and got hosed fairly badly with a single character check.
>I've had to do tricks like your proposed hack before and got hosed fairly badly with a single character check.
True. Obvious things to do:
1. Run a trial parse on the field to check if it's syntactically correct JSON.
2. Add a required "src-version" attribute.
I just looked at the CSSC source and it appears that the description field is a dynamically allocated string list. No length limit.
Must…resist…temptation…
Joey on 2016-02-11 at 03:47:09 said:
My suggestion is: Add it at the moment there is an actual concrete use case for something like tagging (I assume that's what you have in mind). It'll still be an equally ugly-but-clever hack, but at least then it'll be defensible, from a maintenance point of view.
>My suggestion is: Add it at the moment there is an actual concrete use case for something like tagging
Maybe there already is. SCCS actually has branching, but it's ugly to the point of unusability because branches are named by dotted numeric quads. The main argument for hacking in a symbol table is so every branch can have a symbolic name (this is how the RCS backend already works).
The argument against this is that branching is superfluous for SRC's use cases to begin with, and supporting it in the RCS back end was over-engineering. I don't think this is quite true, but it's close enough to make the expected utility of retrofitting branches into SCCS reallly low.
This is me resisting temptation…
Garrett on 2016-02-11 at 09:52:15 said:
@Joey: "Add it at the moment there is an actual concrete use case for something like tagging"
This has now become a contest to see who can come up with a plausible use-case for tagging in SCCS first. I'll try one:
Tagging known-good versions of /etc configuration files per major Ubuntu release. That is, known-good-trusty
Important for dealing with crappy package/config management. This would help address some of the issues I occasionally run into.
>This has now become a contest to see who can come up with a plausible use-case for tagging in SCCS first.
Yeah but, why not just use the default RCS back end that already supports tags?
The real challenge here is to come up with a plausible case where you need tags and must use SCCS. Good luck with that.
The Gods of the Unix Way are frowning.
Go take a cold shower.
Brinton on 2016-02-11 at 11:31:40 said:
Give in to the dark side! The OCD is calling!
>Give in to the dark side! The OCD is calling!
Dude, if Force lightning from my hands were really one of the perks, I'd be so there…
Y'know, if you had a real filesystem with versioning built in, like say, VMS ODS, hacks like this wouldn't be necessary, trololol.
Do it and be done with it. You want to, and you're spending time and effort talking about it and publicly resisting temptation that could be better applied elsewhere. It never gets used? Who cares? You had fun doing it.
…or you could just 'tag' it by scribbling a note on a post-it…with one of those durn fangled 'pen' contraptions.
Like a boss.
Are there any other things you could use the data dictionary for besides the symbol table?
As for use cases? That woukd be any system old enough where RCS won't ever be available. So maybe the retro-computing people could use it fo managing configs?
>Are there any other things you could use the data dictionary for besides the symbol table?
I thought of one about half an hour ago. I could use it to get rid of .srcstamp files, which are my work around for the sad fact that Python utime is unreliable. To speed up src status, whenever you commit a change to a file the length and MD5 hash are written to a corresponding srcstamp, which "src status" can look at without doing an entire checkout to see if the file should be shown as modified.
(This has the desirable consequence that bumping the file mod date doesn't make it show as modified, only an actual content change.)
I could put that MD5 and length in the JSON, obviating the requirement for a separate file and ensuring the state info moves with tn master.
/me whispers "haaaaackk vaaaaaalluuuuuue" softly…
And when the odds are against him and there's dangerous work to do, you bet your life ESR'll see it through.
Go, ESR! Go, ESR! Go, ESR, go!
@John Dougan I have to wonder about the intersection between that set vs systems where Python is available.
"exit with a warning rather than stepping on legacy data." – isn't any such legacy data likely to be human-readable, and thus not really "stepped on" by, say, bundling it up into an attribute of the JSON dictionary?
>"exit with a warning rather than stepping on legacy data." – isn't any such legacy data likely to be human-readable, and thus not really "stepped on" by, say, bundling it up into an attribute of the JSON dictionary?
Yes, but the presence of such data implies a real interoperability issue with tools that aren't SRC.
In situations like that, it's rude to just assume that you can scribble on the metadata or lift it into your own private format without consequences. Better practice is to throw a warning so the user gets the option to clear the field himself, signaling that it's OK to write on it.
Even if you don't use the symbol table I think the other uses of the data dictionary are compelling enough. I hate it when I have to split data across files, that should be together.
The problem is less python availbility, as the version of python. The 1.x series could be compiled onto a lot of older iron and OSs, as was the need and custom at the time.
Cathy on 2016-02-11 at 18:59:25 said:
esr: "SCCS actually has branching, but it's ugly to the point of unusability because branches are named by dotted numeric quads."
Um, dotted numeric quads? You mean, like IP addresses?
Obvious humor omitted here…
I haven't touched SCCS since 1994 at the latest.
Eric Coe on 2016-02-11 at 20:30:05 said:
@cathy "like IP addresses"
Only sorta. As I remember it:
1.0 – initial trunk version
1.1 – next checkin on trunk
1.1.1.0 – First branch from trunk v1.1
1.1.1.1 – Next checkin on that branch
1.1.2.0 – Second branch from v1.1
1.2 – next checkin on trunk.
Branching only goes one layer deep.
Been years for me too.
All I can say is that this is a really neat hack of a source control system.
And the best use of force lightning is for spot-welding stuff (Thing Mr. Welch is no longer allowed to do #1041).
Steven on 2016-02-11 at 23:55:17 said:
How do you know it isn't such a perk? Maybe the people who have gone wholly to the Dark Side just are good at keeping it secret. If you don't make the experiment, you'll never actually know.
>Maybe there already is. SCCS actually has branching, but it's ugly to the point of unusability because branches are named by dotted numeric quads. The main argument for hacking in a symbol table is so every branch can have a symbolic name (this is how the RCS backend already works).
Well then I guess what it comes down to is a cost/benefit analysis (using the term a but loosely here) to decide whether or not you are willing to maintain the feature :)
Oh, go ahead and do it. And while you're at it, fulfill your destiny on the Dark Side (or at least Zawinski's Law) and make it read mail, too.
>Oh, go ahead and do it. And while you're at it, fulfill your destiny on the Dark Side (or at least Zawinski's Law) and make it read mail, too.
Latest news: I've written the code to use the description field as a key-value store, because that seems like a good idea in order to get rid of .srcstamp files, which are an ugly wart on the design.
Have not yet actually got rid of .srcstamp files, as I have real work to do and can't spend too much time on this thing.
Wouldn't requirement to rewrite whole file be a problem, or do you use some trick that makes it possible to avoid it?
>Wouldn't requirement to rewrite whole file be a problem, or do you use some trick that makes it possible to avoid it?
The trick is that you compute a length/md5-hash combo whenever you modify the file. (Presently that's stored in an associated .srcstmp; soon it may move into the JSON dictionary.)
Then, when you want to check if it's modified, you run the same computation on the workfile. You don't have to check out its base version, because you have the base version's hash. Actually, in many cases you don't even have to compute the hash, because the length will differ.
What about padding? Then you'd only have to rewrite the whole file to grow it, which you wouldn't have to do on every operation.
>What about padding? Then you'd only have to rewrite the whole file to grow it, which you wouldn't have to do on every operation.
What about padding what? I'm sorry, I don't understand this at all.
Peter Donis on 2016-02-13 at 14:50:44 said:
@esr: Python utime is unreliable
Are you referring to the lack of nanosecond resolution? FWIW, that's fixed in Python 3.3.
>Are you referring to the lack of nanosecond resolution? FWIW, that's fixed in Python 3.3.
Sigh. I tried moving SRC to 3x and failed utterly – incomprehensible string-vs.Unicode errors. (I had previously succeeded with some 2.x stuff not much smaller; SRC seems to be a particularly hard case.)
If anyone with more experience at 2.x-to-3.x porting wants to take this on, I'd take that patch.
For (any?) sccs/cssc users, it would be interesting to have a Python 1.x port. Anyone? Bueller?
> What about padding what? I'm sorry, I don't understand this at all.
Pad the text field you are repurposing (with blank spaces after the JSON object) to some larger number of bytes in length, so that when you rewrite it (to add a new property to the JSON object) you can, unless the new JSON object is longer than the padded space allows, write it by seeking to the location of the JSON object in the file and overwriting it, without having to shift down everything after it.
Since the concern @ Jakub Narebski seemed to be raising was that making any modifications to the JSON object would require rewriting the rest of the file after it.
>Since the concern @ Jakub Narebski seemed to be raising was that making any modifications to the JSON object would require rewriting the rest of the file after it.
Oh, I thought he was talking about dumping the entire base version in order to compare for a status check.
Anyway, description-field writes aren't done with direct writes to the master-file writes, but rather by an rcs(1) invocation. I'd rather leave that sort of optimization as its problem.
@esr: I tried moving SRC to 3x and failed utterly – incomprehensible string-vs.Unicode errors.
On a quick look, I suspect it's because in Python 3, the file object returned by os.popen reads and writes Unicode strings instead of bytes. Which doesn't really make a lot of sense when you think about it. Unfortunately, there isn't a "binary mode" option to os.popen the way there is with the open builtin; the only way to get that kind of control over the input/output stream is to use the subprocess.Popen class and construct your own binary mode file objects to be the stdin/stdout for the child process.
I'd be willing to try it but I won't have the time in the near future.
the only way to get that kind of control over the input/output stream is to use the subprocess.Popen class and construct your own binary mode file objects to be the stdin/stdout for the child process.
Actually, a little experimentation shows that it isn't quite that bad; using the stdout=PIPE option to subprocess.Popen appears to return bytes (at least on the Python 3 versions I have easy access to). This behavior isn't documented, however.
Well, it turns out I have some time :-), so I'm trying to set up a gitlab account so I can fork src and work on a Python 3 branch. Unfortunately, gitlab.com's account setup seems to be either broken or braindead. Steps tried so far:
(1) Entered my name, desired username, desired password, and email address in their new user signup form.
(2) Their website told me I would get a confirmation email "shortly". That was about an hour ago. (I have twice done the "resend confirmation email" thing, no joy.)
(3) I noticed that I could sign in using my existing github account, so tried that; got a 442 error from gitlab.com complaining that that email was already taken.
(4) I noticed that I could sign in using my Google account…but that account is also tied to the same email address…you can see where this is going. Tried it anyway; got same 442 error.
(5) Looked at the support forum for the gitlab.com website; unfortunately, it has no search function so I can't try to see if anyone else is having this issue (none of the issues showing up as most recent were relevant), and I can't create a new issue without…signing in.
(6) Looked in vain for any kind of tech support email or contact form for people who are having problems signing up on gitlab.com.
So, does anyone know how I can tell gitlab.com that I can't sign up and ask them to fix it?
Alas, "gitlab signup trouble" is not yielding good hits.
>Well, it turns out I have some time :-)
Feel free to just close the repo and send me git am patches.
Well, I finally got a confirmation email from gitlab and was able to set up an account and fork the src project and add a "python3" branch to test the idea I described upthread. Making it work under python3 turned out to be fairly straightforward; in fact, it now runs under both python2 and python3 and passes all regression tests. The branch is here:
https://gitlab.com/pdonis/src/tree/python3
It's ironic that, now that I've done this, the original reason for moving to python3 has evaporated, since the modified check now uses the brute force method and doesn't care about python's utime behavior. :-) However, I think there are a couple of good reasons to port anyway. One is that os.popen is deprecated in both Python 2 and Python 3, so switching to the current best practice, subprocess.Popen, seems like a good idea. The other is that, as I said, the same code runs on both Python 2 and Python 3, so the script's shebang can be changed to /usr/bin/env/python (which I've done in the branch), and the user doesn't have to worry what his distro symlinks "python" to. This seems like a nice future-proofing of the code.
I want to let this incubate at least overnight, just to make sure nothing else occurs to me that I should look at. But if you're still interested in a patch, esr, I can put in the merge request through gitlab when I'm convinced it's ready.
>But if you're still interested in a patch, esr, I can put in the merge request through gitlab when I'm convinced it's ready.
Please do, because I am.
@esr: Feel free to just close the repo and send me git am patches.
Or I can do that instead of putting in a merge request through gitlab. (I had cloned the repo and done most of the work anyway while I was waiting to see if gitlab would get its act together.)
@esr: Please do, because I am.
Ok, will do. Probably some time tomorrow evening.
(I love it when posts cross…)
Peter, I looked at your changes. FYI, the reason popen_or_die has the unused write mode is because it's a utility class I originally wrote for reposurgeon than I paste in to a lot of my projects.
I don't know how you did this so easily. Is your algorithm conscious enough that you could write it down?
@esr: the reason popen_or_die has the unused write mode is because it's a utility class I originally wrote for reposurgeon than I paste in to a lot of my projects.
Ah, ok. I included code to handle the "w" case, so the patched version should be a drop-in replacement in case you want to switch to subprocess.Popen on other projects.
Sure. A key thing I'm relying on is that all the data being dealt with is ASCII (the reasons will be clear from what follows). I'll first describe the basic operation of the code after I changed it, and then the key steps I took to get there.
In order to run as-is under both Python 2 and Python 3, the simplest method is to use the defaults for string literals and console I/O. In Python 2, those are byte strings; in Python 3, those are Unicode. For all ASCII data, that's acceptable, even if it would give some purists fits. :-)
OTOH, when doing I/O with a subprocess, or reading from the filesystem, I wanted to force byte strings in both Python 2 and Python 3, because those operations are used for things like the modified check, where it seems most robust to not do any Unicode conversion at all, not even with ASCII data–that way you're absolutely sure that you're doing a straight byte-by-byte comparison between old data and new data–or, in the case of, e.g., the fast_export method, you're sure that you're counting the size of the content as number of bytes. Also, forcing filesystem and subprocess I/O to be binary eliminates any potential issues with using the system default encoding, which might possibly be something incompatible with ASCII.
In Python 3, making those two things work together for ASCII data is simple: whenever byte string data that was read from a subprocess or the filesystem needs to be mixed with string literals or console I/O, decode it to Unicode (using the ASCII encoding). For example, in the fast_export method (and other methods with direct console output), the byte string data that was read is decoded before being dumped to stdout. And in the parse methods of the backends, each line read from the subprocess is decoded before being tested for various initial strings.
It turns out, though, that for ASCII data, the above strategy also works in Python 2! The reason is that all of the Python 2 operations we need to use let you mix byte string and Unicode data without complaining (for example, string formatting with the % operator, the startswith method of the str and unicode types, the differs from difflib). Of course for data in an arbitrary or unknown encoding, this can be disaster, which was one of the main motivations for changing how all that works in Python 3. But for ASCII data, it works fine, and lets us avoid a lot of hassle–though, again, it would give purists fits. :-)
The key steps I took to implement this were:
(1) Switch to subprocess.Popen in the popen_or_die function; this gives byte string I/O in both Python 2 and Python 3. Switch to binary filesystem I/O. Make fixups as needed so all regression tests pass under Python 2.
(2) Run the 2to3 tool to fix up syntax that is incompatible with Python 3. Most Python 3 compatible syntax (including all of the syntax we're using) is also Python 2.7 compatible (possibly with some __future__ imports like print_function), so the tool might be better named 2to2.7. :-)
(3) Convert all non-default string literals (i.e., all b"" as opposed to "") to default (i.e., ""). Decode byte string data to Unicode where needed. Make fixups as needed so all regression tests pass under Python 3.
(4) Add from __future__ import print_function so script will run under both Python 2 and Python 3. (Other 2to3 syntax changes were already compatible with 2.7.)
>(3) Convert all non-default string literals (i.e., all b"" as opposed to "") to default (i.e., ""). Decode byte string data to Unicode where needed. Make fixups as needed so all regression tests pass under Python 3.
This is the step where I crash and burn. When I get to "make fixups as needed", I find myself in an incident pit where every change seems to throw more errors rather than fewer.
Are you brave enough to try forward-porting reposurgeon? That is actually more important than SRC, because reposurgeon has performance bottlenecks on very large repos that might be addressed in 3 but will never be fixed in 2.
Btw, that now-unused annotation code that you are leaving in as aji :-) can also be simplified under the new approach; there's no need to encode the Unicode you receive from the JSON loader as ASCII bytes. I've updated the python3 branch accordingly.
(I agree with the aji strategy, btw; I hate having to recreate code that I should have kept the first time, even if it wasn't immediately useful.)
@esr: When I get to "make fixups as needed", I find myself in an incident pit where every change seems to throw more errors rather than fewer.
I've had this happen too. In fact I almost had it happen here; I explored trying to enforce byte string data instead of Unicode everywhere, on the theory that the safest thing would be to have the same internal data model (byte strings) regardless of Python version. That proved to be a bad idea. :-) Fortunately, I had an alternate plan up my sleeve, which, as I said, is viable because all of the data involved is ASCII, so I was able to quickly abandon the "byte strings everywhere" plan when it became clear that it was a hairball.
Are you brave enough to try forward-porting reposurgeon?
I'll take a look. With what I know of repository structure, a similar strategy to what I did here should be workable, because repository metadata, AFAIK, is ASCII. (Actual blobs are not, but I would expect that the blobs can be treated as opaque binary data that never has to be decoded–it just has to be byte-compared for things like modification checks.) The main question I would have is, is my understanding correct? Are there any places where reposurgeon has to parse and massage non-ASCII data in order to do its work?
>With what I know of repository structure, a similar strategy to what I did here should be workable, because repository metadata, AFAIK, is ASCII. (Actual blobs are not, but I would expect that the blobs can be treated as opaque binary data that never has to be decoded–it just has to be byte-compared for things like modification checks.) The main question I would have is, is my understanding correct?
Your understanding is correct. Reposurgeon does, and should, treat all data as uninterpreted byte streams. For a minor and obvious exception, see the transcode command. (Which, BTW, I added to deal with Latin-1 characters in comments in the Emacs history.
I too tried to apply the make-it-all-byte-streams approach and failed. Oh well, at least I feel a bit less like an idiot now. (That is, knowing someone much more clueful about forward-porting than I am couldn't make it work either.)
I am really pretty unhappy with Python 3's decision to break the world this way.
@esr: reposurgeon has performance bottlenecks on very large repos that might be addressed in 3 but will never be fixed in 2.
Can you briefly describe what these are?
>Can you briefly describe what these are?
There are reposurgeon operation which could in principle be parallelized to threads running on multiple processors, but can't be in practice because of the Python GIL.
Where this has actually bitten me is doing search-replace commit-metadata modifications on extremely large repositories. It came up in the Emacs conversion, and again working on GCC.
It is possible that the GIL problem might be solved in Python 3 someday, but effectively certain that it won't be in Python 2.
(I have a bit set that I need to kick Guido's butt about this. If Python doesn't fix the GIL problem, I can foresee having to abandon it for a language that can handle parallelism, fairly soon.)
> It is possible that the GIL problem might be solved in Python 3 someday, but effectively certain that it won't be in Python 2.
What was changed in the internal structure of Python's implementation between 2 and 3 which may make it possible to remove the GIL? (Or at least make it not the contention bottleneck between parallel threads?)
>What was changed in the internal structure of Python's implementation between 2 and 3 which may make it possible to remove the GIL?
Nothing, yet. I'm going by the sociology – if they fix it, they'll do it in the leading edge version. probably wuth a C API break, and leave the trailing-edge version backwards-compatible.
@esr: There are reposurgeon operation which could in principle be parallelized to threads running on multiple processors, but can't be in practice because of the Python GIL.
Is using multiple worker processes not an option? On Linux, at least, there isn't a lot of difference in overhead between threads and processes. The multiprocessing module in Python was designed for this purpose and has a similar API to the threading module.
I have a bit set that I need to kick Guido's butt about this.
I suspect that the reason not much has been done on this, in CPython at least, is that the Python dev team feels that the multiprocessing module is a sufficient response to the need.
>Is using multiple worker processes not an option?
Not in this case. There's a dilemma because the natural process working set is the entire metadata graph of the repo, which in real cases can be more than 32GB wide. If you replicate this per worker you're going to OOM pretty fast. So you either need threaded access to one copy in a single process (which means the GIL has to go) or you need to carve it into chunks before assigning them to the worker processes, then stitch them together afterwards. The latter is theoretically possible but so fiddly and complex that I would despair of ever being really confident it was correct.
>the Python dev team feels that the multiprocessing module is a sufficient response to the need.
If that's what they think, they're kidding themselves. That approach only works when working sets are small and/or easily partitioned. It fails on a case like reposurgeon – which, in a world of increasingly big data, we should expect to become the typical case.
@esr: I am really pretty unhappy with Python 3's decision to break the world this way.
I think part of the issue is that Python has such a diverse user base, and therefore a diverse set of user opinions about how the language ought to handle things. Users who can take an "everything is ASCII" view of the world (or even an "everything is UTF-8" view of the world) tend to feel the way you do–Python went through these huge gyrations to "fix" something that wasn't broken. But other users, who are forced to deal with Unicode data coming at them in various wild and wooly encodings, were apparently getting bitten by Python 2's default conversions often enough that they were able to convince the Python dev team that it was a major issue that Python 3 needed to fix.
For Unix geeks, there is also a darker side to this. The Python 3 Unicode handling, at least to me, seems to be largely driven by Windows users, not Unix users. For example, in Windows it does make a kind of sense to have console and filesystem I/O default to Unicode text, since the Windows OS takes the same view; whereas in Unix it makes no sense at all. Armin Ronacher appears to have a similar theory in this article:
http://lucumr.pocoo.org/2014/5/12/everything-about-unicode/
So if you get to have that conversation with Guido, one thing you might want to ask him is why all this pandering to Windows when it's Unix that's holding up the sky. :-)
@esr: There's a dilemma because the natural process working set is the entire metadata graph of the repo, which in real cases can be more than 32GB wide. If you replicate this per worker you're going to OOM pretty fast.
Ouch! Yes, that would pretty much kill multiprocessing. Unless you want to try to spec out a super duper big brother to the Great Beast. 1TB memory, anyone? :-)
Other possible options would be alternative interpreters that don't have the GIL, like PyPy or Stackless.
I'll take a look
I've forked a copy of reposurgeon on gitlab and cloned it locally so I can browse the code. If I have any questions about the internal workings, esr, should I ask them here or email you? If the latter, is esr@thrsys.com good, or is there a better email?
>If I have any questions about the internal workings, esr, should I ask them here or email you?
Email me. No point in clogging the thread. esr@thyrsus.com will work.
Showing my ignorance here, but is it possible to throw the metadata graph into shared memory and have the worker processes use that?
>Showing my ignorance here, but is it possible to throw the metadata graph into shared memory and have the worker processes use that?
If we could figure out how to exile a bunch of Python structures to shared memory but keep pointers to them, maybe. Hard problem.
That is doable…I had to do that on a smaller scale with read only data in Smalltalk. I found it easier to spray the data into the shared section flat, and build abstractions with offset pointers to wrap the shared section with a DB-like API. There were some performance issues with data format conversion from the shared format to the format supported by the runtime (endianness mostly) but I still won because of the extra processes.


text:
Saint-Georges is een gemeente in het Franse departement Tarn-et-Garonne (regio Occitanie) en telt 133 inwoners (1999). De plaats maakt deel uit van het arrondissement Montauban.

Geografie
De oppervlakte van Saint-Georges bedraagt 9,3 km², de bevolkingsdichtheid is 14,3 inwoners per km².

Demografie
Onderstaande figuur toont het verloop van het inwonertal (bron: INSEE-tellingen).

Externe links
 Informatie over Saint-Georges

Gemeente in Tarn-et-Garonne

redpajama_set_name: RedPajamaWikipedia


text:
SMU revokes, then restores, honor for daughter of slain officer
Autumn Johnson | Contributing Writer, Media Research Center
Friday, November 11, 2016 2:27 PM
Southern Methodist University revoked a promise to the daughter of a slain police officer that she could perform the first-serve at a volleyball game to honor her father, but now claims the cancellation was a mistake and that the invitation still stands.
Victoria Smith, the daughter of Sgt. Michael Smith, was supposed to give the honorary serve at the SMU volleyball game on November 12. Sgt. Smith worked with the Dallas Police Department, and was among the five killed in the line of duty on July 7.
Victoria's mother, Heidi bradley Smith, took to Facebook to express her anger at the situation, sharing an email she had received informing her that Victoria would no longer be able to give the first serve in light of recent events that could deem the action as being "insensitive."
"I regret to inform you that we will not be able to go through with the honorary first serve. In the switch between staff members and the handling of volleyball promotions, some information was not forwarded on correctly from (name omitted) to myself and I deeply apologize for that," the email states. "The volleyball program was not correctly informed that this would be taking place at the game, and feels that in light of recent events and diversity within the SMU community, that the demonstration could be deemed insensitive."
The email explained that Victoria would instead be offered the opportunity to stay after the game for an autograph session with the team.
SMU, however, claims that the invitation still stands, and blames the erroneous email on a miscommunication within the staff.
"The SMU Volleyball program extends its sincere apologies to the Smith family and is reaching out this morning to speak directly to Mrs. Smith to apologize and reinforce that the invitation stands," the university told Campus Reform in a statement that is also available on the university's Twitter account.
"This incident does not reflect SMU values. Due to a change in staffing, there was a breakdown in communication that led to this unfortunate situation. This communication to Mrs. Smith would never have occurred if proper approval and communications procedures had been followed," the school explained. "The invitation was intended to help a family heal, and we very much look forward to Victoria's first serve in the volleyball match Saturday."
The statement concludes with a reminder that SMU has paid tribute to Sgt. Smith in the past, along with other first-responders from the area who have been killed in the line of duty.
"SMU values the service and sacrifices of all first-responders and honored Victoria's father, Sgt. Michael Smith, as well as Dallas Police officers Lorne Ahrens, Michael Krol, and Patrick Zamarripa, DART Officer Brent Thompson, SMU Officer Mark McCullers and University Park Fire Department Chief Bob Poynter at the annual First-Responders football game earlier this fall," it concluded.
Follow the author of this article on Twitter: @AutumnDawnPrice
Contributing Writer, Media Research Center
Autumn Johnson is a contributing writer for Media Research Center and an Associate Attorney The Stanley Law Group. Formerly, she was a social media editor for the Blaze, and a Virginia Campus Correspondent for Campus Reform. Autumn graduated from Liberty University School of Law.

redpajama_set_name: RedPajamaCommonCrawl


Boonie Tunes Presents The Finyl Draft. This installment continues the popular Boonie Tunes collection featuring all original royalty free instrumental loops from composer/multi-instrumentalist DJ Finyl intended for sample-based beat makers to chop, loop or whatever else you can imagine. These are high quality samples that range from soul to psych rock. This volume comes with over 35 loops in wav format including bpm. Compatible with Maschine, MPC, Ableton, FL Studio, Logic, Protools, Reason and more.


All package services must be completed within the time-frame listed beginning on the date of purchase. Packages ensure protection against price increases during that time-frame. Unused services are non-refundable and non-transferable. Exception: The Buy-10 package may be shared between two people. Services may be upgraded at the time of use for additional fees. Credits cannot be given for using lesser services.
Please call Kelly at 941-322-7284 to book packages.
Energy work packages are for individuals on a healing journey. These packages can be adjusted to suit the needs of the individual but must be used within the time frame specified for ultimate effectiveness.


text:
Home / Events / 05/16/2017 MoLife Research Seminar: Ms. Neha Kumari
05/16/2017 MoLife Research Seminar: Ms. Neha Kumari
Tuesday, May 16, 2017 - 13:00
Ms. Neha Kumari, PhD Student cacao projekt COMETA - Workgroup M. Ullrich, Jacobs University Bremen, Bremen, Germany
Towards the understanding of Cacao Proteome
Before getting transformed into chocolate and other cocoa products, the content of cocoa beans undergoes a series of complex metabolic changes during processing steps involving fermentation, drying and roasting. Cocoa storage proteins undergo the most intense modifications during fermentation, where microbiological fermentation products-triggered enzymatic reactions lead to their extensive breakdown yielding peptides and amino acids, which are important flavor precursors.
Our research study focused on the comprehensive and comparative protein analysis of the cocoa beans from diverse origins and different hybrids. Protein profile of the cocoa beans starting from the fresh non-fermented beans to the different stages of fermentation and finally towards the fully fermented/dried beans was studied via SDS-PAGE and Two-dimensional polyacrylamide gel electrophoresis. All major protein spots obtained were subjected to proteolytic digestion and MALDI-TOF MS analysis in order to assign them to respective cocoa proteins. Post-translational modification of the cacao proteins was successfully established. The diversity of oligopeptides generated by the proteolytic degradation at different stages of fermentation was identified spectrometrically via UHPLC-ESI-MS/MS analysis. The detected diversity and dynamics of protein and peptide profile will help to define the biochemical markers of distinct steps of the fermentation process, which in turn will help in mapping the precursor based variability and linking it to the taste and aroma of the final product.
Prof. Dr. Matthias Ullrich, Professor of Microbiology (Focus Area: Health - Life Sciences & Chemistry) Email: m.ullrich [at] jacobs-university.de - Link to Homepage: https://ses.jacobs-university.de/ses/mullrich


Santo Domingo is a city in the country of Dominican Republic, that lies in Longitude -69.99 and Latitude 18.5. Santo Domingo lies in the time zone Atlantic Standard Time.
Santo Domingo has an UTC Offset/GMT Offset of UTC-4:00.
Our Santo Domingo time zone converter helps you to convert Santo Domingo time, to local time in other time zones.
There is a also a generic Time Zone Converter, which converts from any Time Zone to any other Time zone including Santo Domingo time.
Santo Domingo does not follow daylight saving time.
Santo Domingo has a population of 2201941 people.


Event marketing is a process of promoting a product, service or organization and many other such things to display.
While planning events we can easily make mistakes or can forget some important things for event marketing.
Before you start any marketing you should know why you're doing it and what you exactly need to do. Cause without knowing you can never reach your destination on time.
Try planning your event on time as it is the main factor in planning. If you have more time to plan, you can do it well. Always try to plan more and more. Set proper expectations for the event, including training your staff and reviewing messaging.
Make sure to have a plan and a backup plan and tell that backup plan to your staff too.
You need to organize your staff for an event to run successfully. Nothing looks worse than having staff standing around and doing nothing. Make sure everyone knows what the plan is and assign them their duties. Don't forget to have few people on standby.
Remember the event staff will help you in running your event successfully. So try treating them with respect.
The main point is every staff member is different from each other-differing strengths and weaknesses. And the easiest way of handling this is simply asking them what they're good at. You can then assign them duties which suit them. This will help your event to be successful.
One of the biggest mistakes you can make during the event is one sided conversation where only speaker can talk.
As marketers we should always find the ways to engage with our audience. The best way is turning on chat functions on social media, talking face to face and letting your audience to ask questions. It will help you getting feedback on real time and also a way of getting their attention.
Social Media Overkill. It's beyond Facebook, Twitter and Instagram. There are hundreds of platforms you could be marketing your event on.
But try finding the most effective one to reach your audience and put your resources and time on it. The biggest mistake marketers do is that they don't choose two or three platforms rather they try putting things on many. But the thing is that, they then become unable to manage single one. So try using two to three platforms to put your resources and time properly. If you're not sure which ones those are, send a survey.
Give them something useful and reliable, and they will come back again and again.
Try planning early, and make sure you stay on top of all the deadlines.
Biggest mistake people do is, not building a schedule based on your event deadline. Through this they always forget some important things to be done for the event.
So try identifying your event date and building a schedule based on the deadlines that need to be met.
The marketing team should be completing all the things needed for the event a week before to make some time for reviewing them.
You should avoid all the mistakes mentioned above to make your event successful.


Styles - P Announces New Album "FLOAT"
Woman Finds A Roach In Her Egg Roll Then Gets Shot At By Restaurant Owner When She Asked Him For A Refund!
8.7 Million Pounds Of Beef Gets Recalled !!
Cam'ron Brings The Cape Into Hip-Hop Are We Ready ??
Can Cam pull this off... stay tuned.


How Do You Create a Living Office?
When it comes to today's office space, there isn't a one-size-fits-all model.
Workplace wellness programs have now been around for a couple of decades in one form or another. Whether it's simple breathing exercises you can do at your desk or wellness seminars and retreats for the staff, companies are taking note of the extraordinary benefits of the wellness culture. But is your company's wellness culture sustainable?


text:
Home Video & Publications
FIRST SCHOLARSHIP IN MEMORY OF LATE CTO DIRECTOR OF RESEARCH TO BE AWARDED THIS YEAR
~Arley Sobers Memorial Scholarship offered to Caribbean national working in tourism research ~ BRIDGETOWN, Barbados (March 7, 2009) – The first scholarship in memory of the late Director of Information Management and Research at the Caribbean Tourism Organization (CTO) will be presented to a Caribbean national this year.
The CTO, through its scholarship programme, the CTO Scholarship Foundation, launches the annual Arley Sobers Memorial Scholarship by offering up to US$5,000 to Caribbean nationals working in tourism research and/or statistics.
Persons already employed at Caribbean national tourism organizations and who are seeking to enhance their skills in these areas through a short term training programme or course, are eligible to apply.The annual Arley Sobers Memorial Scholarship has been established – with a US$10,000 contribution from the Florida Caribbean Cruise Association (FCCA) and support from CTO Member Countries – to honour the late Arley Sobers, the CTO's Interim Secretary General and Director of Information Management and Research, who died suddenly last August, while on an overseas mission for the organization.Mr. Sobers dedicated over two decades of his working life to the service of the Caribbean Tourism Organization. He was very determined to ensure that Caribbean tourism statistical information and research was accurate, reliable and properly validated. From very early in his career he recognized tourism's importance to the economies of the Caribbean, and while Mr. Sobers worked primarily in the area of research and statistics, his overall influence and contribution to Caribbean tourism was wide reaching. Caribbean nationals wishing to apply for the Arley Sobers Memorial Scholarship have until 30 April 2009 to apply. Information on how to apply for this, as well as other scholarships being offered by the CTO Foundation scholarship, can be found at www.onecaribbean.org.The CTO Foundation, set up in 1997, is registered in New York State as a Not-for-Profit Corporation, formed exclusively for charitable and educational purposes. Its main aim is to provide scholarships and study grants to students and industry personnel who are Caribbean nationals, from CTO-member countries, who wish to pursue studies in the areas of tourism/hospitality and language training. The Foundation supports individuals who demonstrate high levels of academic achievement and leadership potential and who express a strong interest in making a contribution to Caribbean tourism.
Major CTO Foundation sponsors include American Express, American Airlines, Interval International, Universal Media, the CTO chapters worldwide and numerous CTO allied members.
Be the first to comment on "FIRST SCHOLARSHIP IN MEMORY OF LATE CTO DIRECTOR OF RESEARCH TO BE AWARDED THIS YEAR"
NATIONAL FOCUS FOR FRIDAY AUGUST 25th, 2017
National Focus for Friday August 25th, 2017 with Prisca Julien and Creole Highlights with Shaakira Pierre.. In the headlines Dominica Coconut Products back in…
Rocah: Giuliani 'Is Hiding Behind This Veil Of Being The President's Lawyer' | MTP Daily | MSNBC
GIS Dominica, National Focus for August 9, 2016
PAHO Donates Four Tonnes in Medical Supplies
Inspector Claude Weekes Speaks on Corruption in Police Force


Lg Magic Remote Qwerty Manual is good choice for you that looking for nice reading experience. We hope you glad to visit our website. Please read our description and our privacy and policy page.
Finally I get this ebook, thanks for all these Lg Magic Remote Qwerty Manual can get now!


text:
Microsoft shows green energy momentum with investment in Keechi Wind Farm
Nov 4, 2013 |	Athima Chansanchai - Microsoft News Center Staff
Share on Facebook (opens new window)
Share on Twitter (opens new window)
Share on LinkedIn (opens new window)
RES Americas developed and constructed the 343 megawatt Lower Snake River Wind Farm. The project, which began operating in 2012, is owned by Puget Sound Energy and is Washington State's largest wind farm.
From the time you wake up in the morning until you rest your weary eyes at night, you do things that consume power.
BZZZZ. Turn off the alarm. Turn on the lights. Brew some coffee. Turn on the TV. Recharge your phone. Turn on the computer. Turn on the AC or heat. Surf the Internet. Heat some leftovers in the microwave. Watch more TV. Do laundry. Run the dishwasher. Or watch more TV. Turn off the lights — except for the one on the porch. ZZZZ.
All those things add up.
Luckily, if your appliances, coffeemakers and lights depend on the Texas power grid, there's going to be 110 megawatts (MW) more clean, renewable energy flowing into that grid by the end of 2015, generated by 55 brand-new wind turbines that will make up the Keechi Wind Farm project. That's enough to juice up 55,000 homes at peak production.
Microsoft has committed to a 20-year power purchase agreement with RES Americas to buy 100 percent of the electricity generated from the soon-to-be-built Keechi Wind Farm Project. It's Microsoft's latest investment in renewable energy and is just one of several innovative projects and approaches the company has pursued in the past few years.
"We have a long standing ambition to move in the direction of sourcing more clean energy as a company, so over the last few years we've increasingly purchased something called RECs – renewable energy credits (more than 2.3 billion kWh globally) – and so this is an opportunity to go to the next stage and invest directly in green energy," says Rob Bernard, Microsoft's chief environmental strategist. He sees Keechi as a "moment in our journey" that includes an increased focus and acceleration in the direction the sustainable energy strategy the company has pursued over the last several years.
With projects focusing on increasing energy efficiency, renewable energy and carbon-offset projects funded in part by an internal carbon fee, Microsoft has become an example to others to be pro-active when it comes to clean energy use and investment.
"When influential companies such as Microsoft sign up to buy wind power, it sends a strong signal on the importance of taking meaningful action on sustainability," says Susan Reilly, president and CEO of RES Americas, the energy developer behind the Keechi project, and chair-elect of the board of the American Wind Energy Association (AWEA). "By signing a contract to buy power from the Keechi Wind project, Microsoft is making the financing, construction, and operation of this 110 megawatt project possible. To be clear: it would not have happened otherwise. The Texas electrical grid is like a pool, and Microsoft is adding clean, green wind power to that pool."
RES Americas developed and constructed the 99 megawatt Central Plains Wind Farm, which is located near Leoti, Kansas.
It takes about one megawatt (MW) of energy to power 500 Texas homes on the same electric grid as Microsoft's San Antonio datacenter. In an area 70 miles northwest of Ft. Worth, construction begins in December to build the Keechi Wind project. This power purchase agreement represents a sizable investment in the wind energy sector in Texas – which has a strong wind resource and has invested in building out its transmission infrastructure to improve integration of these resources into the broader grid. Texas has more installed wind capacity than any other U.S. state, with a total of 12.2 gigawatts of capacity. Wind energy is the source of 9.2 percent of all electricity generated in Texas.
"All of the electricity we consume is from the power grid, through local utilities, which includes a mix generation resources including hydro, natural gas and wind," says Brian Janous, director of energy strategy at Microsoft's Global Foundation Services. "This project gives us a stake in putting more renewable power in the grid. We're not having this power delivered directly to us. We're going to continue to consume power as we always have for our buildings and datacenters — but we're affecting the mix of generation, adding 110 MW of green power that wouldn't have been there otherwise and displacing carbon fuels. We're driving change in the generation mix on the grid in Texas."
Microsoft is driving change in many other ways, too.
This past year Microsoft began building a pilot datacenter in Cheyenne, Wyoming that will run completely independent of the grid from energy generated from biogas, a byproduct of a nearby water treatment plant. Another datacenter in Dublin, Ireland, has implemented a thermodynamic cooling process that happens without loss or gain of heat, which reduces energy costs per megawatt by up to 30 percent. Microsoft is also retrofitting existing datacenters to be more efficient with harder-working, lower-energy servers, compressor energy reduction and custom light-emitting diode (LED) lighting.
An internal carbon fee — which Microsoft charges to business groups based on their output of carbon, primarily through electricity and air travel – helps fund these projects and the Keechi Wind project. The fee is the cornerstone of Microsoft's commitment to carbon neutrality. The funds generated from the carbon fee are used for investing in energy efficiency projects, carbon offsets and for the direct purchase of renewable energy.
Microsoft offset more than 300,000 metric tons of CO2 emissions through that growing portfolio of innovative carbon-offset projects in 2013, and purchased 2.3 billion kilowatt hours (kWh) of renewable energy in 2013— more than twice the amount bought the previous year. This year, the Environmental Protection Agency recognized Microsoft as the second largest purchaser of green power in the U.S. And when Microsoft pledged to become carbon neutral in fiscal year 2013, the National Resources Defense Council (NRDC) validated that the company made good on its promise.
Bernard says Microsoft has spent a little more than two years rethinking its own infrastructure – the "smart buildings" concept captured in the "88 Acres" story. "Let's use ourselves as an experiment to see what's possible. We spent time and focused on our campus. Now we're taking what we've learned from our own experiences to Seattle and CityNext. Now we're going to the next level — can we help our customers save energy as well?"
One way customers can reduce their energy use is by transferring from on-premise installations to cloud computing, Bernard says. At the very least, that transfer causes a 30 percent energy reduction, up to a best case scenario of 90 percent, depending on an organization's size, efficiency and what product lines they're using.
"Public support for renewable energy is strong and growing. Consumers are more aware than ever of the harmful effects of carbon pollution and the role renewable energy can play in reducing these impacts. They want the electricity that powers their lives to be green," Reilly says. "RES Americas and other companies have long been selling power from wind projects to electric utilities. Selling directly to companies that use a lot of energy, such as Microsoft, is an important trend in the industry, and we expect to see more deals like this."
The 149 megawatt Halkirk Wind Farm, which RES Canada constructed in 2012, is the largest wind project in the Canadian province of Alberta.
The physical manifestation of this deal will start appearing in December. Like a lot of things in Texas, these wind turbines are big. Looming nearly 312 feet in the air – that's the same as a 29-story high-rise building – one rotor on these wind turbines measures 328 feet in length – a few stories higher than the shaft it'll rotate around. Each turbine will generate about 2 MW apiece.
And because each part has to be trucked in and assembled there, it's going to take the better part of 2014 to get those 55 wind turbines going. But even before all 55 are all operational, they'll start generating power.
"If you look at the company strategy overall, it's across three areas: demonstrate responsible environmental leadership, enable energy efficiency both in and through the use of information technology, and accelerate scientific development," Bernard says. "So when we look at something like Keechi, in the context of that framework, it's part of a portfolio of activities that are happening in our datacenter division aimed at improving efficiency, lessening our power supply, and greening it when possible."
For more information on the Keechi Wind Farm project and Microsoft's ongoing clean energy efforts, check out "Microsoft Signing Long-Term Deal to Buy Wind Energy in Texas," "Microsoft announces new investment to power a greener cloud" and this infographic.
Athima Chansanchai
Microsoft News Center Staff
Tags: Cloud Computing, Environment, Innovation


text:
Panera's Moves Look Impressive, but the Stock Isn't a Buy Just Yet
Panera is looking to turn the business around with some impressive strategies, but Chipotle and Starbucks are threats that can't be ignored.
Prabhat Sandheliya
(prabhatsandy)
Apr 21, 2014 at 10:24AM
Panera Bread (NASDAQ:PNRA.DL) shares have been under pressure this year after the company issued a weak forecast in February. Panera cited bad weather as the main reason behind the disappointment. In addition, the company is experiencing operational difficulties due to customers' changing preferences and rising competition from Chipotle Mexican Grill (NYSE:CMG) and Starbucks (NASDAQ:SBUX).
Now, Panera is looking to make a comeback with its Panera 2.0 plan, but will it succeed? Let's find out.
Not that bad
Many of Panera's cafes in the Midwest and the Mid-Atlantic Northeast corridor underperformed in the fourth quarter as a result of harsh weather. This led to a decline of $0.03 to $0.04 in the company's earnings per share. In addition, Panera expects to earn just $1.52 in EPS in the first quarter, well behind the Wall Street estimate of $1.70 per share.
Nevertheless, the company managed to grow fourth-quarter revenue by 16% from last year. Moreover, according to the Black Box index, a measure of the U.S. restaurant composite, Panera's growth was 1.6% better than the industry's performance.
Ringing in the changes
Going forward, management is determined to improve the bottom line. In a bid to enhance the customer experience, Panera is revamping its ordering process. It plans to execute an end-to-end system that will provide an enhanced order, payment, execution, and consumption experience for all its customers. This forms the basis of Panera 2.0.
The company is also looking to strengthen its menu by introducing more items and giving customers additional choices. Panera will be adding new flatbread sandwiches to its menu in the spring. These sandwiches will feature quality proteins and bold flavor profiles that will enable the company to better experiment with its new seasonings and spices. Panera will start with varieties such as high-protein chicken, Mediterranean chicken, and Southwestern chicken in a bid to tap younger customers.
Panera's squash soup and antibiotic-free turkey chili are also selling well. These two soups underscore the ongoing push that the company is making to differentiate its offerings via high-quality products. To complement the rollout of new products, Panera is also focusing on its marketing efforts. Its spending on media efforts grew from 1.4% of sales in 2012 to 1.7% of sales last year.
In 2014, the company plans to spend around 1.9% of sales on advertising. These advertisements are expected to have a strong impact in more expensive markets such as New York, Boston, Atlanta, Dallas, and Los Angeles, where Panera has had a very limited advertising presence.
The company expanded its current store count by adding 18 new bakery cafes in the fourth quarter, while its franchisees opened 24 new cafes. By year-end 2013, Panera had a total of 1,777 cafes in operation. It also opened three new catering hubs in the third quarter, taking the total number to seven by the end of fiscal 2013. The company plans to open 20 new hubs in 2014, which will provide support to more than 100 cafes and improve its distribution strength.
Here's Why Arrowhead Pharmaceuticals Skyrocketed 12.7% Today
How Does Your Income Stack Up Against the Average American?
Here's Why Epizyme's Shares Are Surging 19.6% Higher Today
Competitive threats
Moves such as these should help Panera improve its performance going forward, but competition from the likes of Chipotle and Starbucks is a concern. Chipotle has been posing a strong threat to Panera since it is known to "quickly and efficiently move diners into and out of its restaurant locations" in the words of Fool contributor Philip Saglimbeni.
As a result, it was not surprising that Chipotle's fiscal 2013 same-store sales were up 5.6%, while Panera struggled at just 2.3%. Saglimbeni points out that Panera recorded impressive same-store sales growth of 5.7% in 2012.
Hence, the company lost the initiative and Chipotle gained due to its customer-centric approach. In addition, Chipotle is expected to continue its rapid pace of growth. It plans to open 180 to 195 new restaurants this year, similar to last year's addition of 185 locations. Clearly Panera will need to move swiftly and efficiently to accelerate growth in the wake of Chipotle's moves.
Another threat comes from Starbucks, which acquired bakery chain La Boulange in 2012 for $100 million. Since most Starbucks locations are in prime areas, with many of them in close proximity to Panera stores, the coffee giant is a threat that Panera investors shouldn't ignore. Also, Starbucks has been experimenting with its pastry menu, with plans to launch hot and cold sandwiches along with new lunch options.
Panera has struggled of late, and the stock's performance has been bad over the last year. But looking forward, the situation might improve as management rings in the changes to attract customers and improve profitability. However, investors should adopt a wait-and-watch approach and see if Panera's strategies are working despite the stiff competition it faces before making a call on the stock.
PNRA.DL
NASDAQ:PNRA.DL
NYSE:CMG
NASDAQ:SBUX
Panera's Moves Look Impressive, but the Stock Isn't a Buy Just Yet @themotleyfool #stocks $PNRA.DL $CMG $SBUX Next Article


text:
Justia Regulation Tracker Department Of Homeland Security U.s. Customs And Border Protection Accreditation and Approval of Inspectorate America Corporation (Savannah, GA), as a Commercial Gauger and Laboratory, 45647-45648 [2018-19615]
Accreditation and Approval of Inspectorate America Corporation (Savannah, GA), as a Commercial Gauger and Laboratory, 45647-45648 [2018-19615]
Download as PDF 45647 Federal Register / Vol. 83, No. 175 / Monday, September 10, 2018 / Notices CBPL No. ASTM 27–13 .............. D4294 27–46 27–48 27–50 27–54 27–58 D5002 D4052 D93 D1796 D5191 .............. .............. .............. .............. .............. Title Standard Test Method for Sulfur in Petroleum and Petroleum Products by Energy-Dispersive X-ray Fluorescence Spectrometry. Standard Test Method for Density and Relative Density of Crude Oils by Digital Density Analyzer. Standard Test Method for Density and Relative Density of Liquids by Digital Density Meter. Standard Test Methods for Flash-Point by Pensky-Martens Closed Cup Tester. Standard Test Method for Water and Sediment in Fuel Oils by the Centrifuge Method. Standard Test Method For Vapor Pressure of Petroleum Products (Mini Method). Anyone wishing to employ this entity to conduct laboratory analyses and gauger services should request and receive written assurances from the entity that it is accredited or approved by the U.S. Customs and Border Protection to conduct the specific test or gauger service requested. Alternatively, inquiries regarding the specific test or gauger service this entity is accredited or approved to perform may be directed to the U.S. Customs and Border Protection by calling (202) 344–1060. The inquiry may also be sent to CBPGaugersLabs@cbp.dhs.gov. Please reference the website listed below for a complete listing of CBP approved gaugers and accredited laboratories. http://www.cbp.gov/about/labsscientific/commercial-gaugers-andlaboratories. Dated: August 29, 2018. Dave Fluty, Executive Director, Laboratories and Scientific Services. [FR Doc. 2018–19613 Filed 9–7–18; 8:45 am] BILLING CODE 9111–14–P CBPL No. daltland on DSKBBV9HB2PROD with NOTICES 27–03 27–04 27–06 27–08 27–11 Avenue NW, Suite 1500N, Washington, DC 20229, tel. 202–344–1060. U.S. Customs and Border Protection SUPPLEMENTARY INFORMATION: Accreditation and Approval of Inspectorate America Corporation (Savannah, GA), as a Commercial Gauger and Laboratory U.S. Customs and Border Protection, Department of Homeland Security. ACTION: Notice of accreditation and approval of Inspectorate America Corporation (Savannah, GA), as a commercial gauger and laboratory. AGENCY: Notice is hereby given, pursuant to CBP regulations, that Inspectorate America Corporation (Savannah, GA), has been approved to gauge petroleum and certain petroleum products and accredited to test petroleum and certain petroleum products for customs purposes for the next three years as of October 11, 2017. DATES: Inspectorate America Corporation (Savannah, GA) was accredited and approved, as a commercial gauger and laboratory as of October 11, 2017. The next triennial inspection date will be scheduled for October 2020. FOR FURTHER INFORMATION CONTACT: Dr. Justin Shey, Laboratories and Scientific Services Directorate, U.S. Customs and Border Protection, 1300 Pennsylvania SUMMARY: ASTM .............. .............. .............. .............. .............. D D D D D 4006 95 473 86 445 27–13 .............. D 4294 27–48 .............. 27–54 .............. 27–58 .............. D 4052 D 1796 D 5191 Notice is hereby given pursuant to 19 CFR 151.12 and 19 CFR 151.13, that Inspectorate America Corporation, 151 E Lathrop Ave., Savannah, GA 31415 has been approved to gauge petroleum and certain petroleum products and accredited to test petroleum and certain petroleum products for customs purposes, in accordance with the provisions of 19 CFR 151.12 and 19 CFR 151.13. Inspectorate America Corporation is approved for the following gauging procedures for petroleum and certain petroleum products from the American Petroleum Institute (API): API chapters Title 3 ..................... 7 ..................... 8 ..................... 11 ................... 12 ................... 17 ................... Tank Gauging. Temperature Determination. Sampling. Physical Properties Data. Calculations. Marine Measurement. Inspectorate America Corporation is accredited for the following laboratory analysis procedures and methods for petroleum and certain petroleum products set forth by the U.S. Customs and Border Protection Laboratory Methods (CBPL) and American Society for Testing and Materials (ASTM): Title Standard Test Method for Water in Crude Oil by Distillation. Standard Test Method for Water in Petroleum Products and Bituminous Materials by Distillation. Standard Test Method for Sediment in Crude Oils and Fuel Oils by the Extraction Method. Standard Test Method for Distillation of Petroleum Products. Standard Test Method for Kinematic Viscosity of Transparent and Opaque Liquids (and Calculation of Dynamic Viscosity). Standard Test Method for Sulfur in Petroleum and Petroleum Products by Energy Dispersive X-ray Fluorescence Spectrometry. Standard Test Method for Density and Relative Density of Liquids by Digital Density Meter. Standard Test Method for Water and Sediment in Fuel Oils by the Centrifuge Method. Standard Test Method For Vapor Pressure of Petroleum Products (Mini Method). Anyone wishing to employ this entity to conduct laboratory analyses and gauger services should request and receive written assurances from the entity that it is accredited or approved VerDate Sep<11>2014 DEPARTMENT OF HOMELAND SECURITY 17:54 Sep 07, 2018 Jkt 244001 by the U.S. Customs and Border Protection to conduct the specific test or gauger service requested. Alternatively, inquiries regarding the specific test or gauger service this entity is accredited PO 00000 Frm 00054 Fmt 4703 Sfmt 4703 or approved to perform may be directed to the U.S. Customs and Border Protection by calling (202) 344–1060. The inquiry may also be sent to CBP GaugersLabs@cbp.dhs.gov. Please E:\FR\FM\10SEN1.SGM 10SEN1 45648 Federal Register / Vol. 83, No. 175 / Monday, September 10, 2018 / Notices reference the website listed below for a complete listing of CBP approved gaugers and accredited laboratories. http://www.cbp.gov/about/labsscientific/commercial-gaugers-andlaboratories. Dated: August 29, 2018. Dave Fluty, Executive Director, Laboratories and Scientific Services Directorate. [FR Doc. 2018–19615 Filed 9–7–18; 8:45 am] BILLING CODE 9111–14–P DEPARTMENT OF HOMELAND SECURITY U.S. Customs and Border Protection Accreditation and Approval of Bennett Testing Service, Inc. (Rahway, NJ), as a Commercial Gauger and Laboratory U.S. Customs and Border Protection, Department of Homeland Security. AGENCY: Notice of accreditation and approval of Bennett Testing Service, Inc. ACTION: CBPL No. D 4052 API chapters 1 ................... 3 ................... 7 ................... 8 ................... 12 ................. 17 ................. Title Vocabulary. Tank Gauging. Temperature Determination. Sampling. Calculations. Marine Measurement. Bennett Testing Service, Inc. is accredited for the following laboratory analysis procedures and methods for petroleum and certain petroleum products set forth by the U.S. Customs and Border Protection Laboratory Methods (CBPL) and American Society for Testing and Materials (ASTM): Standard Test Method for Density and Relative Density of Liquids by Digital Density Meter. Dated: August 29, 2018. Dave Fluty, Executive Director, Laboratories and Scientific Services Directorate. [FR Doc. 2018–19611 Filed 9–7–18; 8:45 am] BILLING CODE 9111–14–P 17:54 Sep 07, 2018 gauge petroleum and certain petroleum products and accredited to test petroleum and certain petroleum products for customs purposes, in accordance with the provisions of 19 CFR 151.12 and 19 CFR 151.13. Bennett Testing Service, Inc. is approved for the following gauging procedures for petroleum and certain petroleum products from the American Petroleum Institute (API): Title Anyone wishing to employ this entity to conduct laboratory analyses and gauger services should request and receive written assurances from the entity that it is accredited or approved by the U.S. Customs and Border Protection to conduct the specific test or gauger service requested. Alternatively, inquiries regarding the specific test or gauger service this entity is accredited or approved to perform may be directed to the U.S. Customs and Border Protection by calling (202) 344–1060. The inquiry may also be sent to CBPGaugersLabs@cbp.dhs.gov. Please reference the website listed below for a complete listing of CBP approved gaugers and accredited laboratories. http://www.cbp.gov/about/labsscientific/commercial-gaugers-andlaboratories daltland on DSKBBV9HB2PROD with NOTICES Notice is hereby given, pursuant to CBP regulations, that Bennett Testing Service, Inc. (Rahway, NJ), has been approved to gauge petroleum and certain petroleum products and accredited to test petroleum and certain petroleum products for customs purposes for the next three years as of May 22, 2018. DATES: Bennett Testing Service, Inc. (Rahway, NJ) was accredited and approved, as a commercial gauger and laboratory as of May 22, 2018. The next triennial inspection date will be scheduled for May 2021. FOR FURTHER INFORMATION CONTACT: Dr. Justin Shey, Laboratories and Scientific Services Directorate, U.S. Customs and Border Protection, 1300 Pennsylvania Avenue NW, Suite 1500N, Washington, DC 20229, tel. 202–344–1060. SUPPLEMENTARY INFORMATION: Notice is hereby given pursuant to 19 CFR 151.12 and 19 CFR 151.13, that Bennett Testing Service, Inc., 1045 E Hazelwood Ave., Rahway, NJ 07065 has been approved to SUMMARY: ASTM 27–48 .............. VerDate Sep<11>2014 (Rahway, NJ), as a commercial gauger and laboratory. Jkt 244001 DEPARTMENT OF HOMELAND SECURITY U.S. Customs and Border Protection [Docket No. USCBP–2018–0034] Commercial Customs Operations Advisory Committee (COAC) U.S. Customs and Border Protection (CBP), Department of Homeland Security (DHS). ACTION: Committee management; Notice of Federal Advisory Committee meeting. AGENCY: The Commercial Customs Operations Advisory Committee (COAC) will hold its quarterly meeting on Wednesday, October 3, 2018 in Washington, DC. The meeting will be open to the public. DATES: The COAC will meet on Wednesday, October 3, 2018 from 1:00 p.m. to 5:00 p.m. EDT. Please note that the meeting may close early if the committee has completed its business. ADDRESSES: The meeting will be held at the Dirksen Senate Office Building, 50 Constitution Avenue NE, Room SD– G50, Washington, DC 20002. For information on facilities or services for individuals with disabilities or to request special assistance at the meeting, contact Ms. Florence ConstantSUMMARY: PO 00000 Frm 00055 Fmt 4703 Sfmt 4703 Gibson, Office of Trade Relations, U.S. Customs & Border Protection, at (202) 344–1440 as soon as possible. Pre-Registration: Meeting participants may attend either in person or via webinar after pre-registering using one of the methods indicated below: For members of the public who plan to attend the meeting in person, please register by 5:00 p.m. EDT October 2, 2018 either online at https:// teregistration.cbp.gov/index.asp?w=140; by email to tradeevents@dhs.gov; or by fax to (202) 325–4290. You must register prior to the meeting in order to attend the meeting in person. For members of the public who plan to participate via webinar, please register online at https:// teregistration.cbp.gov/index.asp?w=139 by 5:00 p.m. EDT on October 2, 2018. Please feel free to share this information with other interested members of your organization or association. Members of the public who are preregistered to attend via webinar and later need to cancel, please do so by October 2, 2018 utilizing the following links: https://teregistration.cbp.gov/ cancel.asp?w=139 to cancel an in person registration or https:// teregistration.cbp.gov/cancel.asp?w=140 to cancel a webinar registration. E:\FR\FM\10SEN1.SGM 10SEN1
[Federal Register Volume 83, Number 175 (Monday, September 10, 2018)]
From the Federal Register Online via the Government Publishing Office [www.gpo.gov]
Accreditation and Approval of Inspectorate America Corporation
(Savannah, GA), as a Commercial Gauger and Laboratory
AGENCY: U.S. Customs and Border Protection, Department of Homeland
ACTION: Notice of accreditation and approval of Inspectorate America
Corporation (Savannah, GA), as a commercial gauger and laboratory.
SUMMARY: Notice is hereby given, pursuant to CBP regulations, that
Inspectorate America Corporation (Savannah, GA), has been approved to
gauge petroleum and certain petroleum products and accredited to test
petroleum and certain petroleum products for customs purposes for the
next three years as of October 11, 2017.
DATES: Inspectorate America Corporation (Savannah, GA) was accredited
and approved, as a commercial gauger and laboratory as of October 11,
2017. The next triennial inspection date will be scheduled for October
FOR FURTHER INFORMATION CONTACT: Dr. Justin Shey, Laboratories and
Scientific Services Directorate, U.S. Customs and Border Protection,
1300 Pennsylvania Avenue NW, Suite 1500N, Washington, DC 20229, tel.
SUPPLEMENTARY INFORMATION: Notice is hereby given pursuant to 19 CFR
151.12 and 19 CFR 151.13, that Inspectorate America Corporation, 151 E
Lathrop Ave., Savannah, GA 31415 has been approved to gauge petroleum
and certain petroleum products and accredited to test petroleum and
certain petroleum products for customs purposes, in accordance with the
provisions of 19 CFR 151.12 and 19 CFR 151.13. Inspectorate America
Corporation is approved for the following gauging procedures for
petroleum and certain petroleum products from the American Petroleum
Institute (API):
API chapters                            Title
3....................................  Tank Gauging.
7....................................  Temperature Determination.
8....................................  Sampling.
11...................................  Physical Properties Data.
12...................................  Calculations.
17...................................  Marine Measurement.
Inspectorate America Corporation is accredited for the following
laboratory analysis procedures and methods for petroleum and certain
petroleum products set forth by the U.S. Customs and Border Protection
Laboratory Methods (CBPL) and American Society for Testing and
Materials (ASTM):
CBPL No.              ASTM                    Title
27-03.................  D 4006         Standard Test Method for Water in
Crude Oil by Distillation.
27-04.................  D 95           Standard Test Method for Water in
Petroleum Products and
Bituminous Materials by
Distillation.
27-06.................  D 473          Standard Test Method for Sediment
in Crude Oils and Fuel Oils by
the Extraction Method.
27-08.................  D 86           Standard Test Method for
Distillation of Petroleum
27-11.................  D 445          Standard Test Method for
Kinematic Viscosity of
Transparent and Opaque Liquids
(and Calculation of Dynamic
Viscosity).
27-13.................  D 4294         Standard Test Method for Sulfur
in Petroleum and Petroleum
Products by Energy Dispersive X-
ray Fluorescence Spectrometry.
27-48.................  D 4052         Standard Test Method for Density
and Relative Density of Liquids
by Digital Density Meter.
27-54.................  D 1796         Standard Test Method for Water
and Sediment in Fuel Oils by the
Centrifuge Method.
27-58.................  D 5191         Standard Test Method For Vapor
Pressure of Petroleum Products
(Mini Method).
Anyone wishing to employ this entity to conduct laboratory analyses
and gauger services should request and receive written assurances from
the entity that it is accredited or approved by the U.S. Customs and
Border Protection to conduct the specific test or gauger service
requested. Alternatively, inquiries regarding the specific test or
gauger service this entity is accredited or approved to perform may be
directed to the U.S. Customs and Border Protection by calling (202)
344-1060. The inquiry may also be sent to [email protected].
reference the website listed below for a complete listing of CBP
approved gaugers and accredited laboratories. http://www.cbp.gov/about/labs-scientific/commercial-gaugers-and-laboratories.
Dated: August 29, 2018.
Dave Fluty,
Executive Director, Laboratories and Scientific Services Directorate.
[FR Doc. 2018-19615 Filed 9-7-18; 8:45 am]


7/3/1998 PRODUCTION MASTER - 4 P.M.
Chicago: "World, The," 07/03/1998, WGBH Media Library & Archives, accessed April 20, 2019, http://openvault.wgbh.org/catalog/A_D5480BD7D6F742F4B67B04885DC28AE4.
MLA: "World, The." 07/03/1998. WGBH Media Library & Archives. Web. April 20, 2019. <http://openvault.wgbh.org/catalog/A_D5480BD7D6F742F4B67B04885DC28AE4>.