medium to large forths. That changed when I encountered them in small >microcontroller forths e.g. FlashForth, SwiftX.
If forthers are avoiding SKIP/SCAN because it's 'not ANS' then I
would say it's time to reconsider - not standardization as hell will
freeze first - rather treat them as ubiquitously and with as little
need of explanation or definition as is currently afforded PLACE.
Regarding compatibility, the only consideration is 'white space'.
SKIP/SCAN has the same restriction as WORD when BL is used as the
scan character. Which should come as no surprise as WORD is typically >implemented with SKIP/SCAN.
In article <t9to17$1u6s$1...@gioia.aioe.org>, dxforth <dxf...@gmail.com> wrote:
Until recently I treated SKIP/SCAN as exotic functions only found in
medium to large forths. That changed when I encountered them in small >microcontroller forths e.g. FlashForth, SwiftX.
If forthers are avoiding SKIP/SCAN because it's 'not ANS' then IIn modern Forth WORD is not typically implemented but a loadable extension.
would say it's time to reconsider - not standardization as hell will
freeze first - rather treat them as ubiquitously and with as little
need of explanation or definition as is currently afforded PLACE.
Regarding compatibility, the only consideration is 'white space'.
SKIP/SCAN has the same restriction as WORD when BL is used as the
scan character. Which should come as no surprise as WORD is typically >implemented with SKIP/SCAN.
For SKIP SCAN I can't remember what it is supposed to do.
Gforth 0.7.3 has it, but I can't find in the documentation.
Swiftforth has it, but I can't find in the documentation.
Bottom line, as soon as it standardized, I will look into it,
if it worthwhile to add to ciforth.
none albert schrieb am Montag, 4. Juli 2022 um 09:43:40 UTC+2:
In article <t9to17$1u6s$1...@gioia.aioe.org>, dxforth<dxf...@gmail.com> wrote:
Until recently I treated SKIP/SCAN as exotic functions only found inIn modern Forth WORD is not typically implemented but a loadable extension. >>
medium to large forths. That changed when I encountered them in small
microcontroller forths e.g. FlashForth, SwiftX.
If forthers are avoiding SKIP/SCAN because it's 'not ANS' then I
would say it's time to reconsider - not standardization as hell will
freeze first - rather treat them as ubiquitously and with as little
need of explanation or definition as is currently afforded PLACE.
Regarding compatibility, the only consideration is 'white space'.
SKIP/SCAN has the same restriction as WORD when BL is used as the
scan character. Which should come as no surprise as WORD is typically
implemented with SKIP/SCAN.
For SKIP SCAN I can't remember what it is supposed to do.
Gforth 0.7.3 has it, but I can't find in the documentation.
Swiftforth has it, but I can't find in the documentation.
Bottom line, as soon as it standardized, I will look into it,
if it worthwhile to add to ciforth.
I consider Forth source text as pre-tokenized because every word/number >appears space-delimited.
For non-tokenized text those classic SKIP/SCAN words are practically useless.
It came as a surprise to me that these useful words have not been
included into the ANS standard. They should be added.
Until recently I treated SKIP/SCAN as exotic functions only found in
medium to large forths.
In article <3051af2f-1cec-4aca...@googlegroups.com>,
minf...@arcor.de <minf...@arcor.de> wrote:
none albert schrieb am Montag, 4. Juli 2022 um 09:43:40 UTC+2:
In article <t9to17$1u6s$1...@gioia.aioe.org>, dxforth<dxf...@gmail.com> wrote:
Until recently I treated SKIP/SCAN as exotic functions only found inIn modern Forth WORD is not typically implemented but a loadable extension.
medium to large forths. That changed when I encountered them in small
microcontroller forths e.g. FlashForth, SwiftX.
If forthers are avoiding SKIP/SCAN because it's 'not ANS' then I
would say it's time to reconsider - not standardization as hell will
freeze first - rather treat them as ubiquitously and with as little
need of explanation or definition as is currently afforded PLACE.
Regarding compatibility, the only consideration is 'white space'.
SKIP/SCAN has the same restriction as WORD when BL is used as the
scan character. Which should come as no surprise as WORD is typically
implemented with SKIP/SCAN.
For SKIP SCAN I can't remember what it is supposed to do.
Gforth 0.7.3 has it, but I can't find in the documentation.
Swiftforth has it, but I can't find in the documentation.
Bottom line, as soon as it standardized, I will look into it,
if it worthwhile to add to ciforth.
I consider Forth source text as pre-tokenized because every word/number >appears space-delimited.
For non-tokenized text those classic SKIP/SCAN words are practically useless.
No any more. The modern insights is that
"we gaan naar Rome"
is a token.
You can't have much success if considering Forth as pre-tokenized,
nowadays. That was cure in the seventies.
On Monday, July 4, 2022 at 5:50:02 AM UTC+2, dxforth wrote:
Until recently I treated SKIP/SCAN as exotic functions only found in
medium to large forths.
I use SKIP and SCAN quite often when processing strings.
I would not know how to skip leading characters, or scan for words
delimited by a specified character, without SKIP and SCAN.
It came as a surprise to me that these useful words have not been
included into the ANS standard. They should be added.
Henry
If forthers are avoiding SKIP/SCAN because it's 'not ANS' then II rarely use SCAN/SKIP, because I read most strings from file - and
would say it's time to reconsider - not standardization as hell will
freeze first - rather treat them as ubiquitously and with as little
need of explanation or definition as is currently afforded PLACE.
Regarding compatibility, the only consideration is 'white space'.WORD is loadable in 4tH - but I don't think I've used it in decades.
SKIP/SCAN has the same restriction as WORD when BL is used as the
scan character. Which should come as no surprise as WORD is typically implemented with SKIP/SCAN.
Until recently I treated SKIP/SCAN as exotic functions only found in
medium to large forths. That changed when I encountered them in small microcontroller forths e.g. FlashForth, SwiftX.
If forthers are avoiding SKIP/SCAN because it's 'not ANS' then I
would say it's time to reconsider - not standardization as hell will
freeze first - rather treat them as ubiquitously and with as little
need of explanation or definition as is currently afforded PLACE.
Regarding compatibility, the only consideration is 'white space'.
SKIP/SCAN has the same restriction as WORD when BL is used as the
scan character. Which should come as no surprise as WORD is typically implemented with SKIP/SCAN.
On Sunday, July 3, 2022 at 11:50:02 PM UTC-4, dxforth wrote:
Until recently I treated SKIP/SCAN as exotic functions only found in
medium to large forths. That changed when I encountered them in small microcontroller forths e.g. FlashForth, SwiftX.
If forthers are avoiding SKIP/SCAN because it's 'not ANS' then IAt least one post says they don't know what SKIP and SCAN are supposed to do. I don't see where anyone mentions this. Can someone explain it for my benefit?
would say it's time to reconsider - not standardization as hell will
freeze first - rather treat them as ubiquitously and with as little
need of explanation or definition as is currently afforded PLACE.
Regarding compatibility, the only consideration is 'white space'.
SKIP/SCAN has the same restriction as WORD when BL is used as the
scan character. Which should come as no surprise as WORD is typically implemented with SKIP/SCAN.
gnuarm.del...@gmail.com schrieb am Montag, 4. Juli 2022 um 17:51:17 UTC+2:
On Sunday, July 3, 2022 at 11:50:02 PM UTC-4, dxforth wrote:to do. I don't see where anyone mentions this. Can someone explain it
Until recently I treated SKIP/SCAN as exotic functions only found inAt least one post says they don't know what SKIP and SCAN are supposed
medium to large forths. That changed when I encountered them in small
microcontroller forths e.g. FlashForth, SwiftX.
If forthers are avoiding SKIP/SCAN because it's 'not ANS' then I
would say it's time to reconsider - not standardization as hell will
freeze first - rather treat them as ubiquitously and with as little
need of explanation or definition as is currently afforded PLACE.
Regarding compatibility, the only consideration is 'white space'.
SKIP/SCAN has the same restriction as WORD when BL is used as the
scan character. Which should come as no surprise as WORD is typically
implemented with SKIP/SCAN.
for my benefit?
See here page 101ff (89/90 in the document) >http://www.forth.org/OffeteStore/1003_InsideF83.pdf
gnuarm.del...@gmail.com schrieb am Montag, 4. Juli 2022 um 17:51:17 UTC+2:
On Sunday, July 3, 2022 at 11:50:02 PM UTC-4, dxforth wrote:
Until recently I treated SKIP/SCAN as exotic functions only found in medium to large forths. That changed when I encountered them in small microcontroller forths e.g. FlashForth, SwiftX.
If forthers are avoiding SKIP/SCAN because it's 'not ANS' then IAt least one post says they don't know what SKIP and SCAN are supposed to do. I don't see where anyone mentions this. Can someone explain it for my benefit?
would say it's time to reconsider - not standardization as hell will freeze first - rather treat them as ubiquitously and with as little
need of explanation or definition as is currently afforded PLACE. Regarding compatibility, the only consideration is 'white space'. SKIP/SCAN has the same restriction as WORD when BL is used as the
scan character. Which should come as no surprise as WORD is typically implemented with SKIP/SCAN.
See here page 101ff (89/90 in the document) http://www.forth.org/OffeteStore/1003_InsideF83.pdf
On Monday, July 4, 2022 at 5:50:02 AM UTC+2, dxforth wrote:
Until recently I treated SKIP/SCAN as exotic functions only found in
medium to large forths.
I use SKIP and SCAN quite often when processing strings.
I would not know how to skip leading characters, or scan for words
delimited by a specified character, without SKIP and SCAN.
It came as a surprise to me that these useful words have not been
included into the ANS standard. They should be added.
gnuarm.del...@gmail.com schrieb am Montag, 4. Juli 2022 um 17:51:17 UTC+2:
On Sunday, July 3, 2022 at 11:50:02 PM UTC-4, dxforth wrote:
Until recently I treated SKIP/SCAN as exotic functions only found inAt least one post says they don't know what SKIP and SCAN are supposed to do.
medium to large forths. That changed when I encountered them in small
microcontroller forths e.g. FlashForth, SwiftX.
If forthers are avoiding SKIP/SCAN because it's 'not ANS' then I
would say it's time to reconsider - not standardization as hell will
freeze first - rather treat them as ubiquitously and with as little
need of explanation or definition as is currently afforded PLACE.
Regarding compatibility, the only consideration is 'white space'.
SKIP/SCAN has the same restriction as WORD when BL is used as the
scan character. Which should come as no surprise as WORD is typically
implemented with SKIP/SCAN.
See here page 101ff (89/90 in the document)
http://www.forth.org/OffeteStore/1003_InsideF83.pdf
There's a typo in the asm code for SKIP on that page:
<quote>
LABEL DONE A common returning point when the input stream is exhausted.
CX PUSH Push the contents of CX on stack and return. CX register has the remaining length
of the stream.
NEXT
CODE SKIP ( addr len char -- addr1 len1 )
Given the address and length of a string, and a character to look for, scan through
the string while we continue to find the character. Leave the address of the mismatch and the length of the remaining string.
AX POP Move char to AX register.
CX POP Move len to CX register.
DONE JCXZ If length of string is zero, jump to DONE and return.
DI POP Move addr to DI register.
DX DX MOV
DX ES MOV Set ES=DS for string manipulations.
REPZ BYTE SCAS Repeatedly scan the string until we find a character different from that in AX.
0<> IF CX now has the count of characters in the remaining string. If CX is not zero,
</quote>
I'm pretty sure it should be:
DX DS MOV
before
DX ES MOV Set ES=DS for string manipulations.
On Monday, July 4, 2022 at 5:50:02 AM UTC+2, dxforth wrote:
If forthers are avoiding SKIP/SCAN because it's 'not ANS' then II rarely use SCAN/SKIP, because I read most strings from file - and
would say it's time to reconsider - not standardization as hell will
freeze first - rather treat them as ubiquitously and with as little
need of explanation or definition as is currently afforded PLACE.
there (in 4tH) I can use PARSE, PARSE-NAME - or numerous other
(loadable) variations - including PARSE-CSV.
Where SCAN/SKIP is concerned I have some other variations on that
theme where the SCAN, SKIP or SPLIT function is a DEFERed word
that can e.g. do numeric characters or non-alphabetic characters -
you name it.
On Tuesday, July 5, 2022 at 5:23:51 AM UTC+2, dxforth wrote:
For those who use SKIP and SCAN, does it specially handle TABs?SKIP and SCAN are only supposed to skip or scan for the specified character. Space ($20) and tab ($09) are clearly not the same characters, and the two words should be able to distinguish them. You may want to distinguish them!
e.g. VFX versions treat TABs in the string as if they were BL.
Has it caused any issues in practice?
In SwiftForth, SKIP and SCAN work as expected. They will distinguish space and tab.
Both words are code definitions and written as short as possible with no extra actions.
This is how it should be.
I looked at VFX and yes, this is weird. The definitions for SKIP and SCAN are more
complicated than necessary and contain extra tests for $09 and $20.
In my eyes this is not a good solution. Treating space and tab as identical characters
may be convenient at times, but this requirement should be handled differently.
In Forth, basic words should perform simple actions. This makes their actions predictable
and avoids unexpected side effects.
The only good thing that I can say about it is that the VFX manual clearly describes the
unusual behavior of SKIP and SCAN:
"Note that when a space char is given, tabs are also ignored."
For those who use SKIP and SCAN, does it specially handle TABs?
e.g. VFX versions treat TABs in the string as if they were BL.
Has it caused any issues in practice?
On Tuesday, July 5, 2022 at 5:23:51 AM UTC+2, dxforth wrote:
For those who use SKIP and SCAN, does it specially handle TABs?
e.g. VFX versions treat TABs in the string as if they were BL.
Has it caused any issues in practice?
SKIP and SCAN are only supposed to skip or scan for the specified character. Space ($20) and tab ($09) are clearly not the same characters, and the two words should be able to distinguish them. You may want to distinguish them!
In SwiftForth, SKIP and SCAN work as expected. They will distinguish space and tab.
Both words are code definitions and written as short as possible with no extra actions.
This is how it should be.
I looked at VFX and yes, this is weird. The definitions for SKIP and SCAN are more
complicated than necessary and contain extra tests for $09 and $20.
In my eyes this is not a good solution. Treating space and tab as identical characters
may be convenient at times, but this requirement should be handled differently.
In Forth, basic words should perform simple actions. This makes their actions predictable
and avoids unexpected side effects.
The only good thing that I can say about it is that the VFX manual clearly describes the
unusual behavior of SKIP and SCAN:
"Note that when a space char is given, tabs are also ignored."
I looked at VFX and yes, this is weird. The definitions for SKIP and SCAN are more
complicated than necessary and contain extra tests for $09 and $20.
In my eyes this is not a good solution. Treating space and tab as identical characters
may be convenient at times, but this requirement should be handled differently.
In Forth, basic words should perform simple actions. This makes their actions predictable
and avoids unexpected side effects.
The only good thing that I can say about it is that the VFX manual clearly describes the
unusual behavior of SKIP and SCAN:
"Note that when a space char is given, tabs are also ignored."
The behaviour come from when we swtched from block files to text files.
We wished to retain the ability to keep source in chunks, and to keep the >text small, so we treated ^L (12) as a page separator and TAB (9) as white >space. At that time many text editors behaved the same way.
I believe it is in the spirit of the ANS
and following
standards use of the term "whitespace".
...
In SwiftForth, SKIP and SCAN work as expected. They will distinguish space and tab.
Both words are code definitions and written as short as possible with no extra actions.
This is how it should be.
I looked at VFX and yes, this is weird. The definitions for SKIP and SCAN are more
complicated than necessary and contain extra tests for $09 and $20.
In my eyes this is not a good solution. Treating space and tab as identical characters
may be convenient at times, but this requirement should be handled differently.
Stephen Pelc <stephen@vfxforth.com> writes:
The behaviour come from when we swtched from block files to text files.
We wished to retain the ability to keep source in chunks, and to keep the >>text small, so we treated ^L (12) as a page separator and TAB (9) as white >>space. At that time many text editors behaved the same way.
11.3.5
|When parsing from a text file using a space delimiter, control
|characters shall be treated the same as the space character.
[funky behaviour of SKIP and SCAN in VFX]
I believe it is in the spirit of the ANS
It certainly does: Systems are allowed to implement non-standard words
like SKIP and SCAN with whatever semantics they like. And apparently
that's what's happening. Let's see:
s\" \x01\z\v\f\t abc" bl scan . c@ .
Gforth prints 4 32
iForth 5.1-mini prints 5 9
lxf prints 4 32
SwiftForth 3.11 prints 4 32
vfx64 5.11 prints 5 9
and following
standards use of the term "whitespace".
I'm not sure the standard uses that term. I certainly does not in the >sentence I cited above.
- anton
Stephen Pelc <ste...@vfxforth.com> writes:[..]
[funky behaviour of SKIP and SCAN in VFX]
I believe it is in the spirit of the ANSIt certainly does: Systems are allowed to implement non-standard words
like SKIP and SCAN with whatever semantics they like. And apparently
that's what's happening. Let's see:
s\" \x01\z\v\f\t abc" bl scan . c@ .
Gforth prints 4 32
iForth 5.1-mini prints 5 9
lxf prints 4 32
SwiftForth 3.11 prints 4 32
vfx64 5.11 prints 5 9
Stephen Pelc <stephen@vfxforth.com> writes:
The behaviour come from when we swtched from block files to text files.
We wished to retain the ability to keep source in chunks, and to keep the >>text small, so we treated ^L (12) as a page separator and TAB (9) as white >>space. At that time many text editors behaved the same way.
11.3.5
|When parsing from a text file using a space delimiter, control
|characters shall be treated the same as the space character.
[funky behaviour of SKIP and SCAN in VFX]
I believe it is in the spirit of the ANS
It certainly does: Systems are allowed to implement non-standard words
like SKIP and SCAN with whatever semantics they like.
On 6/07/2022 01:32, Anton Ertl wrote:
Stephen Pelc <ste...@vfxforth.com> writes:
The behaviour come from when we swtched from block files to text files. >>We wished to retain the ability to keep source in chunks, and to keep the >>text small, so we treated ^L (12) as a page separator and TAB (9) as white >>space. At that time many text editors behaved the same way.
11.3.5
|When parsing from a text file using a space delimiter, control
|characters shall be treated the same as the space character.
[funky behaviour of SKIP and SCAN in VFX]
I believe it is in the spirit of the ANS
It certainly does: Systems are allowed to implement non-standard wordsThe standard for SKIP SCAN had been set by L&P F83. Anyone implementing
like SKIP and SCAN with whatever semantics they like.
it would have been aware of what it was, and the consequences of departing.
On Wednesday, 6 July 2022 at 00:31:56 UTC+1, dxforth wrote:
On 6/07/2022 01:32, Anton Ertl wrote:
Stephen Pelc <ste...@vfxforth.com> writes:
The behaviour come from when we swtched from block files to text files. >>We wished to retain the ability to keep source in chunks, and to keep the >>text small, so we treated ^L (12) as a page separator and TAB (9) as white
space. At that time many text editors behaved the same way.
11.3.5
|When parsing from a text file using a space delimiter, control |characters shall be treated the same as the space character.
[funky behaviour of SKIP and SCAN in VFX]
I believe it is in the spirit of the ANS
I implemented a forth-like scanner and parserIt certainly does: Systems are allowed to implement non-standard words like SKIP and SCAN with whatever semantics they like.The standard for SKIP SCAN had been set by L&P F83. Anyone implementing
it would have been aware of what it was, and the consequences of departing.
in python once and found that the ability to just pass an
array of chars was useful. Meant I could look [' ','\t','\n','\r']
more easily.
If the need had arisen in forth then we would have these
filed under common usage.
( ---------------------------------------------------------- )
: searchchar ( a u c -- f )
over 0> if
scan nip 0> if true else false then
else drop drop drop false then ;
( ---------------------------------------------------------- )
: skip[] ( a1 u1 a2 u2 -- a3 u3 )
r begin eol? 0= whilerch 2r@ rot searchchar while
nch repeat
then 2r> 2drop ;
( ---------------------------------------------------------- )
: scan[] ( a1 u1 a2 u2 -- a3 u3 )
r begin eol? 0= whilerch 2r@ rot searchchar 0= while
nch repeat
then 2r> 2drop ;
( ---------------------------------------------------------- )
Notes
(1) searchchar is used because standard search requires a string
and I needed a char
so in gforth you would pass a string eg s\" \t \n\r" and search
for bl, tab, cr and nl all at once.
or any other combination you seek to skip[] and scan[] over
NN
On Wednesday, 6 July 2022 at 00:31:56 UTC+1, dxforth wrote:
On 6/07/2022 01:32, Anton Ertl wrote:
Stephen Pelc <ste...@vfxforth.com> writes:
The behaviour come from when we swtched from block files to text files. >>We wished to retain the ability to keep source in chunks, and to keep the >>text small, so we treated ^L (12) as a page separator and TAB (9) as white
space. At that time many text editors behaved the same way.
11.3.5
|When parsing from a text file using a space delimiter, control |characters shall be treated the same as the space character.
[funky behaviour of SKIP and SCAN in VFX]
I believe it is in the spirit of the ANS
I implemented a forth-like scanner and parserIt certainly does: Systems are allowed to implement non-standard words like SKIP and SCAN with whatever semantics they like.The standard for SKIP SCAN had been set by L&P F83. Anyone implementing
it would have been aware of what it was, and the consequences of departing.
in python once and found that the ability to just pass an
array of chars was useful. Meant I could look [' ','\t','\n','\r']
more easily.
If the need had arisen in forth then we would have these
filed under common usage.
( ---------------------------------------------------------- )
: searchchar ( a u c -- f )
over 0> if
scan nip 0> if true else false then
else drop drop drop false then ;
( ---------------------------------------------------------- )
: skip[] ( a1 u1 a2 u2 -- a3 u3 )
r begin eol? 0= whilerch 2r@ rot searchchar while
nch repeat
then 2r> 2drop ;
( ---------------------------------------------------------- )
: scan[] ( a1 u1 a2 u2 -- a3 u3 )
r begin eol? 0= whilerch 2r@ rot searchchar 0= while
nch repeat
then 2r> 2drop ;
( ---------------------------------------------------------- )
Notes
(1) searchchar is used because standard search requires a string
and I needed a char
so in gforth you would pass a string eg s\" \t \n\r" and search
for bl, tab, cr and nl all at once.
or any other combination you seek to skip[] and scan[] over
...
I implemented a forth-like scanner and parser
in python once and found that the ability to just pass an
array of chars was useful. Meant I could look [' ','\t','\n','\r']
more easily.
If the need had arisen in forth then we would have these
filed under common usage.
( ---------------------------------------------------------- )
: searchchar ( a u c -- f )
over 0> if
scan nip 0> if true else false then
else drop drop drop false then ;
( ---------------------------------------------------------- )
: skip[] ( a1 u1 a2 u2 -- a3 u3 )
2>r begin eol? 0= while
rch 2r@ rot searchchar while
nch repeat
then 2r> 2drop ;
( ---------------------------------------------------------- )
: scan[] ( a1 u1 a2 u2 -- a3 u3 )
2>r begin eol? 0= while
rch 2r@ rot searchchar 0= while
nch repeat
then 2r> 2drop ;
( ---------------------------------------------------------- )
Notes
(1) searchchar is used because standard search requires a string
and I needed a char
so in gforth you would pass a string eg s\" \t \n\r" and search
for bl, tab, cr and nl all at once.
or any other combination you seek to skip[] and scan[] over
NN schrieb am Mittwoch, 6. Juli 2022 um 20:26:47 UTC+2:
so in gforth you would pass a string eg s\" \t \n\r" and search
for bl, tab, cr and nl all at once.
or any other combination you seek to skip[] and scan[] over
In C the string library functions strpbrk and strcspn do that job.
This means BL SCAN is a special case.I hate special cases. Because they tend to lead to ugly code and
On Tuesday, July 5, 2022 at 6:42:35 PM UTC+2, Marcel Hendrix wrote:
This means BL SCAN is a special case.I hate special cases. Because they tend to lead to ugly code and
unintuitive behavior.
Hans Bezemer
In article <78faec9f-6732-4144-84d3-edf9d197311dn@googlegroups.com>,
Hans Bezemer <the.beez.speaks@gmail.com> wrote:
On Tuesday, July 5, 2022 at 6:42:35 PM UTC+2, Marcel Hendrix wrote:
This means BL SCAN is a special case.I hate special cases. Because they tend to lead to ugly code and >>unintuitive behavior.
+1
Sufficient reason to not implement SCAN .
WORD forces two different behaviours : PARSE-NAME / TOKEN / NAME
and PARSE.
So WORD is banned from the core implementation, and becomes
a loadable extension.
BL SCAN is inheriting a 70's design error from WORD .
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 300 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 55:16:15 |
| Calls: | 6,712 |
| Files: | 12,243 |
| Messages: | 5,355,394 |