Round 4 / packing (99.8%) / shipping (99.7%)
- metalliqaz
- Location: USA
- Main keyboard: Leopold FC200R
- Main mouse: Logitech G400
- Favorite switch: MX Brown
- DT Pro Member: -
Well...useless on a standard ANSI keyboard anyway. lol
Actually... I do have a question for you 7bit. ROUND3/MODIFIER150 claims to contain 18 pieces but the picture herehas 10 keys. Is the wiki out of date?
Actually... I do have a question for you 7bit. ROUND3/MODIFIER150 claims to contain 18 pieces but the picture herehas 10 keys. Is the wiki out of date?
- 7bit
- Location: Berlin, DE
- Main keyboard: Tipro / IBM 3270 emulator
- Main mouse: Logitech granite for SGI
- Favorite switch: MX Lock
- DT Pro Member: 0001
- blighty
- Location: New York, USA
- Main keyboard: LZ ergo (mx silent red)
- Main mouse: Logitech G Pro
- Favorite switch: Cherry MX Silent Red
- DT Pro Member: 0037
Post-post-Closing/Leftovers/??? payments from metalliqaz(2012-11-01), sth(2012-11-01), bnp70kr, and i488 (20120-11-02) have been received and marked as shipped for PP (although we all know that we are looking at 3 or so month for the caps to be produced, shipped for sorting, then shipped to their final destination, i.e. you). That is to avoid PP account lock ups, that they like to do. Invoices may or may not reflect the change, but they will. Please keep in mind I only account for payments made to me, not to megnin or IBAN.
Note: Addresses on the Paypal invoices are not the addresses 7bit uses to ship your keycaps/switches to. He uses whatever address that is listed on your invoice.
Note: Addresses on the Paypal invoices are not the addresses 7bit uses to ship your keycaps/switches to. He uses whatever address that is listed on your invoice.
- blighty
- Location: New York, USA
- Main keyboard: LZ ergo (mx silent red)
- Main mouse: Logitech G Pro
- Favorite switch: Cherry MX Silent Red
- DT Pro Member: 0037
Well, there's still the orange R3 music kit and space bar? Also, your payment was received.pettijohn wrote:This thread needs more orange. That's what I get for placing my order however-many-months ago and then tuning out. Missed the Orange opportunity.
-
- Location: United States
- Main keyboard: HHKB Pro 2
- Main mouse: Razer Deathadder
- Favorite switch: Brown
- DT Pro Member: -
My order has been cancelled due to some issues. So, I was wondering if anyone has these kits they're willing to sell.
ROUND3/ALPHA |A-Z and Punctuation keys |32.00| 1| 54| 32.00
ROUND3/SPACEOLD/BLACK|7 units Cherry no Windows | 2.00| 1| 1| 2.00
ROUND3/SPACEOLD/GREY |7 units Cherry no Windows | 2.00| 1| 1| 2.00
ROUND3/TENKLESS |Tenkless kit ( 84- 87 keys)|78.00| 1|111| 78.00
ROUND3/ALPHA |A-Z and Punctuation keys |32.00| 1| 54| 32.00
ROUND3/SPACEOLD/BLACK|7 units Cherry no Windows | 2.00| 1| 1| 2.00
ROUND3/SPACEOLD/GREY |7 units Cherry no Windows | 2.00| 1| 1| 2.00
ROUND3/TENKLESS |Tenkless kit ( 84- 87 keys)|78.00| 1|111| 78.00
- blighty
- Location: New York, USA
- Main keyboard: LZ ergo (mx silent red)
- Main mouse: Logitech G Pro
- Favorite switch: Cherry MX Silent Red
- DT Pro Member: 0037
Post-post-Closing/Leftovers/??? payments from pettijohn and kravlin have been received and marked as shipped for PP (although we all know that we are looking at 2 or so months for the caps to be produced, shipped for sorting, then shipped to their final destination, i.e. you). That is to avoid PP account lock ups, that they like to do. Invoices may or may not reflect the change, but they will. Please keep in mind I only account for payments made to me, not to megnin or IBAN.
Note: Addresses on the Paypal invoices are not the addresses 7bit uses to ship your keycaps/switches to. He uses whatever address that is listed on your invoice.
Note: Addresses on the Paypal invoices are not the addresses 7bit uses to ship your keycaps/switches to. He uses whatever address that is listed on your invoice.
Last edited by blighty on 07 Nov 2012, 12:47, edited 1 time in total.
-
- Location: Isle of Man
- Main keyboard: Kinesis Advantage
- Main mouse: 3M Vertical
- Favorite switch: MX Brown
- DT Pro Member: 0009
Sadly, it will take far longer than you want. It's a lot of work for Signature Plastics to fulfill the order, and they've got much larger clients than us. When the caps finally get to 7bit, he's got to sort through umpteen thousand keycaps - which will need careful sorting.
I'm volunteering to receive mine last - that'll help you a bit at least.
I'm volunteering to receive mine last - that'll help you a bit at least.
- 7bit
- Location: Berlin, DE
- Main keyboard: Tipro / IBM 3270 emulator
- Main mouse: Logitech granite for SGI
- Favorite switch: MX Lock
- DT Pro Member: 0001
He is around 80 invoice numbers haead of you.hoggy wrote:Sadly, it will take far longer than you want. It's a lot of work for Signature Plastics to fulfill the order, and they've got much larger clients than us. When the caps finally get to 7bit, he's got to sort through umpteen thousand keycaps - which will need careful sorting.
I'm volunteering to receive mine last - that'll help you a bit at least.
![Smile :-)](./images/smilies/icon_e_smile.gif)
As far as I know, they still do the DCS key caps.
- vivalarevolución
- formerly prdlm2009
- Location: USA
- Main keyboard: IBM Beam spring
- Main mouse: Kangaroo
- Favorite switch: beam spring
- DT Pro Member: 0097
I am lusting for my spherical keycaps. Ah, the waiting!
- webwit
- Wild Duck
- Location: The Netherlands
- Main keyboard: Model F62
- Favorite switch: IBM beam spring
- DT Pro Member: 0000
- Contact:
The waiting!
Spoiler:
- 7bit
- Location: Berlin, DE
- Main keyboard: Tipro / IBM 3270 emulator
- Main mouse: Logitech granite for SGI
- Favorite switch: MX Lock
- DT Pro Member: 0001
Please read this for better understanding of the waiting procedure:
![Confused :?](./images/smilies/icon_e_confused.gif)
Code: Select all
WAIT(P) POSIX Programmer's Manual WAIT(P)
NAME
wait - await process completion
SYNOPSIS
wait [pid...]
DESCRIPTION
When an asynchronous list (see Asynchronous Lists ) is started by the
shell, the process ID of the last command in each element of the asyn‐
chronous list shall become known in the current shell execution envi‐
ronment; see Shell Execution Environment .
If the wait utility is invoked with no operands, it shall wait until
all process IDs known to the invoking shell have terminated and exit
with a zero exit status.
If one or more pid operands are specified that represent known process
IDs, the wait utility shall wait until all of them have terminated. If
one or more pid operands are specified that represent unknown process
IDs, wait shall treat them as if they were known process IDs that
exited with exit status 127. The exit status returned by the wait util‐
ity shall be the exit status of the process requested by the last pid
operand.
The known process IDs are applicable only for invocations of wait in
the current shell execution environment.
OPTIONS
None.
OPERANDS
The following operand shall be supported:
pid One of the following:
1. The unsigned decimal integer process ID of a command, for
which the utility is to wait for the termination.
2. A job control job ID (see the Base Definitions volume of
IEEE Std 1003.1-2001, Section 3.203, Job Control Job ID)
that identifies a background process group to be waited for.
The job control job ID notation is applicable only for invo‐
cations of wait in the current shell execution environment;
see Shell Execution Environment . The exit status of wait
shall be determined by the last command in the pipeline.
Note:
The job control job ID type of pid is only available on
systems supporting the User Portability Utilities option.
STDIN
Not used.
INPUT FILES
None.
ENVIRONMENT VARIABLES
The following environment variables shall affect the execution of wait:
LANG Provide a default value for the internationalization variables
that are unset or null. (See the Base Definitions volume of
IEEE Std 1003.1-2001, Section 8.2, Internationalization Vari‐
ables for the precedence of internationalization variables used
to determine the values of locale categories.)
LC_ALL If set to a non-empty string value, override the values of all
the other internationalization variables.
LC_CTYPE
Determine the locale for the interpretation of sequences of
bytes of text data as characters (for example, single-byte as
opposed to multi-byte characters in arguments).
LC_MESSAGES
Determine the locale that should be used to affect the format
and contents of diagnostic messages written to standard error.
NLSPATH
Determine the location of message catalogs for the processing of
LC_MESSAGES .
ASYNCHRONOUS EVENTS
Default.
STDOUT
Not used.
STDERR
The standard error shall be used only for diagnostic messages.
OUTPUT FILES
None.
EXTENDED DESCRIPTION
None.
EXIT STATUS
If one or more operands were specified, all of them have terminated or
were not known by the invoking shell, and the status of the last oper‐
and specified is known, then the exit status of wait shall be the exit
status information of the command indicated by the last operand speci‐
fied. If the process terminated abnormally due to the receipt of a sig‐
nal, the exit status shall be greater than 128 and shall be distinct
from the exit status generated by other signals, but the exact value is
unspecified. (See the kill -l option.) Otherwise, the wait utility
shall exit with one of the following values:
0 The wait utility was invoked with no operands and all process
IDs known by the invoking shell have terminated.
1-126 The wait utility detected an error.
127 The command identified by the last pid operand specified is
unknown.
CONSEQUENCES OF ERRORS
Default.
The following sections are informative.
APPLICATION USAGE
On most implementations, wait is a shell built-in. If it is called in a
subshell or separate utility execution environment, such as one of the
following:
(wait)
nohup wait ...
find . -exec wait ... \;
it returns immediately because there are no known process IDs to wait
for in those environments.
Historical implementations of interactive shells have discarded the
exit status of terminated background processes before each shell
prompt. Therefore, the status of background processes was usually lost
unless it terminated while wait was waiting for it. This could be a
serious problem when a job that was expected to run for a long time
actually terminated quickly with a syntax or initialization error
because the exit status returned was usually zero if the requested
process ID was not found. This volume of IEEE Std 1003.1-2001 requires
the implementation to keep the status of terminated jobs available
until the status is requested, so that scripts like:
j1&
p1=$!
j2&
wait $p1
echo Job 1 exited with status $?
wait $!
echo Job 2 exited with status $?
work without losing status on any of the jobs. The shell is allowed to
discard the status of any process if it determines that the application
cannot get the process ID for that process from the shell. It is also
required to remember only {CHILD_MAX} number of processes in this way.
Since the only way to get the process ID from the shell is by using the
'!' shell parameter, the shell is allowed to discard the status of an
asynchronous list if "$!" was not referenced before another asynchro‐
nous list was started. (This means that the shell only has to keep the
status of the last asynchronous list started if the application did not
reference "$!" . If the implementation of the shell is smart enough to
determine that a reference to "$!" was not saved anywhere that the
application can retrieve it later, it can use this information to trim
the list of saved information. Note also that a successful call to
wait with no operands discards the exit status of all asynchronous
lists.)
If the exit status of wait is greater than 128, there is no way for the
application to know if the waited-for process exited with that value or
was killed by a signal. Since most utilities exit with small values,
there is seldom any ambiguity. Even in the ambiguous cases, most appli‐
cations just need to know that the asynchronous job failed; it does not
matter whether it detected an error and failed or was killed and did
not complete its job normally.
EXAMPLES
Although the exact value used when a process is terminated by a signal
is unspecified, if it is known that a signal terminated a process, a
script can still reliably determine which signal by using kill as shown
by the following script:
sleep 1000&
pid=$!
kill -kill $pid
wait $pid
echo $pid was terminated by a SIG$(kill -l $?) signal.
If the following sequence of commands is run in less than 31 seconds:
sleep 257 | sleep 31 &
jobs -l %%
either of the following commands returns the exit status of the second
sleep in the pipeline:
wait <pid of sleep 31>wait %%
RATIONALE
The description of wait does not refer to the waitpid() function from
the System Interfaces volume of IEEE Std 1003.1-2001 because that would
needlessly overspecify this interface. However, the wording means that
wait is required to wait for an explicit process when it is given an
argument so that the status information of other processes is not con‐
sumed. Historical implementations use the wait() function defined in
the System Interfaces volume of IEEE Std 1003.1-2001 until wait()
returns the requested process ID or finds that the requested process
does not exist. Because this means that a shell script could not reli‐
ably get the status of all background children if a second background
job was ever started before the first job finished, it is recommended
that the wait utility use a method such as the functionality provided
by the waitpid() function.
The ability to wait for multiple pid operands was adopted from the
KornShell.
This new functionality was added because it is needed to determine the
exit status of any asynchronous list accurately. The only compatibility
problem that this change creates is for a script like
while sleep 60 do
job& echo Job started $(date) as $! done
which causes the shell to monitor all of the jobs started until the
script terminates or runs out of memory. This would not be a problem if
the loop did not reference "$!" or if the script would occasionally
wait for jobs it started.
FUTURE DIRECTIONS
None.
SEE ALSO
Shell Command Language , kill() , sh , the System Interfaces volume of
IEEE Std 1003.1-2001, wait(), waitpid()
COPYRIGHT
Portions of this text are reprinted and reproduced in electronic form
from IEEE Std 1003.1, 2003 Edition, Standard for Information Technology
-- Portable Operating System Interface (POSIX), The Open Group Base
Specifications Issue 6, Copyright (C) 2001-2003 by the Institute of
Electrical and Electronics Engineers, Inc and The Open Group. In the
event of any discrepancy between this version and the original IEEE and
The Open Group Standard, the original IEEE and The Open Group Standard
is the referee document. The original Standard can be obtained online
at http://www.opengroup.org/unix/online.html .
IEEE/The Open Group 2003 WAIT(P)
![Confused :?](./images/smilies/icon_e_confused.gif)
- kps
- Location: Waterloo, Ontario, Canada
- Main keyboard: Kinesis contoured
- Main mouse: Kensington Slimblade trackball
- DT Pro Member: -
7bit wrote:Please read this for better understanding of the waiting procedure:
Code: Select all
$ sudo renice -10 $(pidof R4)
-
- Main keyboard: noppoo choc mini brown MX
- Main mouse: N/A
- Favorite switch: red? Have not tried them all.
- DT Pro Member: -
@kps
@7bit
POSIX! POSIX! POOOOOOOOOOOSIX! *shrieks on the background* *then wheezing*
@et al.
♪ Waiting, waiting
Waiting, waiting
Waiting, waiting
Waiting, all the way!
Sing with me!
[REPEAT] ♪
Code: Select all
$ /usr/bin/renice: Permission denied
POSIX! POSIX! POOOOOOOOOOOSIX! *shrieks on the background* *then wheezing*
@et al.
♪ Waiting, waiting
Waiting, waiting
Waiting, waiting
Waiting, all the way!
Sing with me!
[REPEAT] ♪
Last edited by bebuxe on 14 Nov 2012, 23:41, edited 1 time in total.
- webwit
- Wild Duck
- Location: The Netherlands
- Main keyboard: Model F62
- Favorite switch: IBM beam spring
- DT Pro Member: 0000
- Contact:
You're scaring the keyboard girls!