OT, was Re: What's Native
[1/19] from: ed::brittlestar::com at: 22-Jun-2004 21:11
Gabriele wrote:
> Hi Ed,
>
> EOC> I wonder why Eclipse/SWT became so popular if native-like apps are
not a
> EOC> factor? Doesn't Java provide its own built-in GUI libraries (Swing,
etc.)?
> Because the Java ones just suck? :)
>
Ooof! Low blow!
I have a good friend whose been an accomplished Java programmer for quite a
few years at a high-tech company.
A while ago I joked with him that Philip Greenspun referred to Java as the
sport-utility vehicle (SUV)
of programming lanugages.
(http://blogs.law.harvard.edu/philg/2003/09/20). He didn't like my comment,
and I remember it backfiring on me:
Friend: "It's not such a terrible analogy. What kind of vehicle would you
expect to win a cross-desert baja race? An SUV, right? What kind of vehicle
would REBOL be, an experimental car?"
Me: "Not sure... something simple and lightweight. Some users have compared
it to a bicycle."
Friend: (laughing) "No, I've seen REBOL, and a bicycle isn't a good
example-- it's more like a unicycle. It's designer would see the second
wheel as bloat and decide that a superior design would require just one. Ha!
A unicycle-- good for quick stunts and clowning around!!"
Me: (gritting teeth)
Mind you, this friend is a Java programmer & Mac enthusiast. A serious
engineer-type. He doesn't care for SWT-- doesn't see any need for it,
prefers emacs.
// Ed
[2/19] from: g:santilli:tiscalinet:it at: 23-Jun-2004 11:14
Hi Ed,
On Wednesday, June 23, 2004, 3:11:13 AM, you wrote:
EOC> Friend: (laughing) "No, I've seen REBOL, and a bicycle isn't a good
EOC> example-- it's more like a unicycle. It's designer would see the second
EOC> wheel as bloat and decide that a superior design would require just one. Ha!
EOC> A unicycle-- good for quick stunts and clowning around!!"
That's what someone that does not know REBOL and Carl Sassenrath
would say. But, Carl isn't like that. Usability always comes first
in REBOL. You see, why would you need so many datatypes while
other languages just have a few? Why do we have READ and WRITE
while OPEN-COPY-INSERT-CLOSE would be enough?
That quote simply isn't right. Java is just bloat, REBOL is just
simple. These are two different concepts, though probably they're
hard to fit in some minds. ;)
Never forget, REBOL has a nice flat surface, but you'll never know
how deep it is unless you submerge.
Regards,
Gabriele.
--
Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer
Amiga Group Italia sez. L'Aquila --- SOON: http://www.rebol.it/
[3/19] from: mauro:fontana:speedautomazione:it at: 23-Jun-2004 13:00
> That quote simply isn't right. Java is just bloat, REBOL is just
> simple. These are two different concepts, though probably they're
> hard to fit in some minds. ;)
They are undoubtly two products aimed at different markets and different
solutions.
GUIs are always a complex thing, and modern ones also tends to be bloated.
See Linux for example. Lately it is becoming more and more similar to
Windows for resource needs. Expecially if you try to use the new gui
framework.
You can use Pine for your email, but probably Opera is a better integrated
tool for internet in general. See the program sizes.
Time where managing a entire OS + GUI in 512K of code is gone. That
miracle was also Carl's product, but now we see that GUIs have more and
more importance and their weight in every application is very big.
Still REBOL is not that "efficient" when speaking of memory usage.
[4/19] from: ed:brittlestar at: 23-Jun-2004 8:05
Gabriele wrote:
> That's what someone that does not know REBOL and Carl Sassenrath
> would say. But, Carl isn't like that. Usability always comes first
> in REBOL. You see, why would you need so many datatypes while
> other languages just have a few? Why do we have READ and WRITE
> while OPEN-COPY-INSERT-CLOSE would be enough?
I think the usability of REBOL is quite high. However, some programmers
can't get comfortable the free-form, no-punctuation syntax, or that you
sometimes need know to open a port instead of using READ, etc.
> That quote simply isn't right. Java is just bloat, REBOL is just
> simple. These are two different concepts, though probably they're
> hard to fit in some minds. ;)
Simplicity is subjective. It's about balance. Einstein is quoted as saying
Everything should be made as simple as possible, but not simpler.
The end
of that quote implies a warning.
I'm also reminded of Matz' talk about the philosophy of Ruby (see Simplicity
is NOT a Goal
http://www.rubyist.net/~matz/slides/oscon2003/mgp00047.html from
http://www.rubyist.net/~matz/slides/oscon2003/):
Simplicity is NOT a goal:
- Things too simple are complex
- Things too complex are difficult
- Human thoughts are not simple
- Programs are essentially complex
- Combination of simple concepts can be complex very easily
> Never forget, REBOL has a nice flat surface, but you'll never know
> how deep it is unless you submerge.
I agree. I think it's just a case of people having different worldviews, and
the difficulties of understanding one another.
// Ed
[5/19] from: petr:krenzelok:trz:cz at: 23-Jun-2004 14:12
Mauro Fontana wrote:
>>That quote simply isn't right. Java is just bloat, REBOL is just
>>simple. These are two different concepts, though probably they're
<<quoted lines omitted: 13>>
>more importance and their weight in every application is very big.
>Still REBOL is not that "efficient" when speaking of memory usage.
No, it is not, that is for sure. Nor is Mozilla in comparison to IE. We
suffer because of that, because porting rebol onto mobile devices will
not be trivial. But maybe also in a year or two it will not be an issue
anymore, as even today's PDAs have 64 - 128MB RAM. OTOH:
- we are currently choosing some additional products to our SAP system,
middleware one. We were adviced for the system to work properly (purely
Java based), it needs at least 2GB RAM. Now that is really hilarious. So
- before you tell us Rebol UI consumes too much of a memory, please just
show me native Java UI. I saw one with 50K USD product - man it sucked
and Cyphre's tree-view would beat it speed-wise, whatever-wise pov you
choose.
- I was OO programmer too. We used CA-Visual Objects here. Objects are
fine, but those widgets are pretty well hardwired. If they don't provide
you with certain method, you can do nearly nothing to change that. You
can override some functionality, but that is all. Once we wanted to add
e.g. background image onto main screen, we had to hack two page strict
win32 code into our app. Simply because window class of CA-VO did not
provide us with that. And here comes beauty of compositing system of
View - it is just rectangle area to draw into + event system - you can
hack whatever UI element you want, if you are skilled enough. Not having
good docs is main obstacle right now, but I hope it will change.
Last six months I brought my another friend to Rebol. He really
complained about text-list, list etc. styles having somehow unfinished
functionality etc. I showed him Cyphre's work - he told me he could not
imagine it is even possible. I explained him basics of face based
composition (non VID) and in a week he showe me his own grid style. Now
he works for some company using some strict OO tool too and he often
mentions - if I even had oportunity to use View - I could change what I
want about UI element. All I can say is - simplicity.
Cheers,
-pekr-
[6/19] from: mauro:fontana:speedautomazione:it at: 23-Jun-2004 16:42
On Wed, 23 Jun 2004 14:12:31 +0200, Petr Krenzelok <[petr--krenzelok--trz--cz]>
wrote:
>> Still REBOL is not that "efficient" when speaking of memory usage.
>>
<<quoted lines omitted: 4>>
> not be trivial. But maybe also in a year or two it will not be an issue
> anymore, as even today's PDAs have 64 - 128MB RAM. OTOH:
Yes, and that is just enough to run Java applications as well...
> - we are currently choosing some additional products to our SAP system,
> middleware one. We were adviced for the system to work properly (purely
<<quoted lines omitted: 3>>
> and Cyphre's tree-view would beat it speed-wise, whatever-wise pov you
> choose.
Well, it depends on the performance/throughput the application needs to
process.
I may also think that CPU with 4MB of syncronous cache are hilarous, but
then when speaking of high performance computation....
Do you think rebol can provide the same functionalities with less
resources?
Can you think you can make a tool like Opera/Mozilla with rebol?
Yet, you can blame them for being huge and somewhat slow, but they win
hands down when speaking about features and easiness of use.
> - I was OO programmer too. We used CA-Visual Objects here. Objects are
> fine, but those widgets are pretty well hardwired. If they don't provide
<<quoted lines omitted: 6>>
> hack whatever UI element you want, if you are skilled enough. Not having
> good docs is main obstacle right now, but I hope it will change.
Well, are you suggesting that graphics framework should be made of simple
point, line, triange, rectange and such?
Of course with those basic objects you can do whatever you want.
But try to have an auto scaling/flowing/adaptive GUI and you'll see that
the work neede is more complex than tracing simple gfx objects.
> Last six months I brought my another friend to Rebol. He really
> complained about text-list, list etc. styles having somehow unfinished
<<quoted lines omitted: 4>>
> mentions - if I even had oportunity to use View - I could change what I
> want about UI element. All I can say is - simplicity.
Maybe I'll get flamed here, but... I'm just realistic.
Rebol is a good scripting tool. But it is just a simple tool.
Whatever you say about rebol can be said about every other scripting
language. And some of them are much more "advanced" than rebol (some of
them have modularity capacities and can be fully integrated into the
native OS).
Some of them have also better support from 3rd party applications (like
apache).
However I can't see anyone of them entering the main stream as
alternatives for languages with (bloated) GUIs (or simply compiled ones),
but they are used as they were thought: as scripting languages.
I know it is sad, but again, the GUI functonality has its own importance.
Sorry for my english.
Mauro
[7/19] from: g:santilli:tiscalinet:it at: 23-Jun-2004 18:22
Hi Mauro,
On Wednesday, June 23, 2004, 4:42:51 PM, you wrote:
MF> Rebol is a good scripting tool. But it is just a simple tool.
MF> Whatever you say about rebol can be said about every other scripting
MF> language.
I don't think so. If you're talking about Lisp and derivatives,
then you could be able to match most of REBOL. But the rest, it's
like comparing apples to oranges. It's like saying that a Fiat 500
is basically the same thing as an intergalactic cruiser ---
they're both vehicles.
MF> but they are used as they were thought: as scripting languages.
I use REBOL to write applications. They are used by people. Doing
them in Java or C++ would require about 10x the time, the code
would probably be 10x bigger, with 10x bugs and so on.
Regards,
Gabriele.
--
Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer
Amiga Group Italia sez. L'Aquila --- SOON: http://www.rebol.it/
[8/19] from: g:santilli:tiscalinet:it at: 23-Jun-2004 18:30
Hi Ed,
On Wednesday, June 23, 2004, 2:05:52 PM, you wrote:
EOC> Simplicity is subjective. It's about balance. Einstein is quoted as saying
EOC> "Everything should be made as simple as possible, but not simpler." The end
EOC> of that quote implies a warning.
Again, exactly the point. Java is not as simple as possible
because REBOL is simpler. And I don't think REBOL is simpler than
as simple as possible
--- maybe it could even be made simpler.
EOC> - Things too simple are complex
We're not trying to be "too simple". Also, simplicity is
difficult, I agree, but you always have a price to pay in order to
have advantages.
EOC> - Human thoughts are not simple
That's human's fault. ;-) The good thing is that with enough
effort you can get simpler.
EOC> - Programs are essentially complex
Bad programs are, or programs that solve a complex problem. Not
all programs. Most things could be done much better --- they
aren't either because the authors are not good enough or because
since the user don't care the authors don't care either.
EOC> - Combination of simple concepts can be complex very easily
Right. That's why OO doesn't work --- even if the classes, once
isolated, are simple enough, just putting them together would
result in a monster. You need an architectural view, a global
design. Just putting things together doesn't work.
Regards,
Gabriele.
--
Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer
Amiga Group Italia sez. L'Aquila --- SOON: http://www.rebol.it/
[9/19] from: rotenca:telvia:it at: 23-Jun-2004 23:44
Hi Mauro,
> Rebol is a good scripting tool. But it is just a simple tool.
No. It is not simple, it seems simple. Carl has hidden the complexity and the
great innovations of the language behind known programming frames, probably to
do not threat new users.
It is like Amiga Exec, it appears simple, but it has some ideas inside, which
today, after 20 years, Linux and many other OS can only dream.
---
Ciao
Romano
[10/19] from: petr:krenzelok:trz:cz at: 24-Jun-2004 0:26
>Well, it depends on the performance/throughput the application needs to
>process.
>I may also think that CPU with 4MB of syncronous cache are hilarous, but
>then when speaking of high performance computation....
>
>Do you think rebol can provide the same functionalities with less
>resources?
>
Maybe, maybe not. How huge are other environments? Tens of MBs? Or
several CDs? Well, we can say that we speak "development" resources, so
noone cares if your VC++ takes gigabyte of your harddrive or not, but I
think Rebol really can provide same functionality with less resources,
where it is capable to do so (provided functionality wise)
>Can you think you can make a tool like Opera/Mozilla with rebol?
>
No
>Yet, you can blame them for being huge and somewhat slow, but they win
>hands down when speaking about features and easiness of use.
>
Features? Well - maybe different characteristics. I can produce Opera in
C, C++, maybe even Java (although I doubt it a bit) ... about easiness
of use - what do you mean? Deployment of strong OO environment can be
pretty tough for programmer. Or do you mean application easiness? Well,
I talked to one friend who told me ppl should not be called programmers
unless they code in C++. I can hack similar DB app using Rebol in less
time probably, looking nearly the same, the same speed etc. Now who
wins? And the answer for me is - the only judge is end user. If he finds
nothing limiting with Rebol app, then it simply serves its purpose, and
I can bet in many cases it can use less resources.
>>- I was OO programmer too. We used CA-Visual Objects here. Objects are
>>fine, but those widgets are pretty well hardwired. If they don't provide
<<quoted lines omitted: 10>>
>Well, are you suggesting that graphics framework should be made of simple
>point, line, triange, rectange and such?
Why not? What is Windows button anyway? :-) few lines, colors and events
hacked together?
>Of course with those basic objects you can do whatever you want.
>But try to have an auto scaling/flowing/adaptive GUI and you'll see that
>the work neede is more complex than tracing simple gfx objects.
>
I don't believe that or you simply don't know View internals deep
enough. Have you seen Cyphre's tree-view, menu/context menu? That is
exactly how I imagine I should instruct system what to do - dialects.
When I work with menu, I talk to menu and don't care about tree-view
syntax etc. Have you seen Romano's auto resize system? NEVER seen
anything like that before. And when I say 'auto, I simply mean 'auto,
not some kind of pseudo recalculations of coordinates (from programmer's
pov, as internally they are simply that - recalcultations).
It is bad to talk waporvare, but I would be really glad if VID 1.3 would
come to some final stage and later on VID 1.4 would emerge, as ppl have
to see potential.
>>
>>
>
>Maybe I'll get flamed here, but... I'm just realistic.
>Rebol is a good scripting tool. But it is just a simple tool.
>Whatever you say about rebol can be said about every other scripting
>language.
>
OK, name some native UIs for other languages and forget plugging tk ...
> And some of them are much more "advanced" than rebol (some of
>them have modularity capacities and can be fully integrated into the
>native OS).
>
true
>Some of them have also better support from 3rd party applications (like
>apache).
>
true, but support of 3rd party is not measurement to what is
architecture about ...
>However I can't see anyone of them entering the main stream as
>alternatives for languages with (bloated) GUIs (or simply compiled ones),
>but they are used as they were thought: as scripting languages.
>
But rebol can be different ... that is just my experience you don't need
to necessarily share. Just show me product like IOS, so consistent, UI
wise, architecture wise, so simple to manage, with other scripting
languages ... well, maybe Python ...
-pekr-
[11/19] from: g:santilli:tiscalinet:it at: 24-Jun-2004 10:48
Hi Petr,
On Thursday, June 24, 2004, 12:26:23 AM, you wrote:
>>Can you think you can make a tool like Opera/Mozilla with rebol?
>>
>>
PK> No
Well actually, maybe I'm the only one here, but just with AGG
inside View and a couple more font rendering features, we could
beat Mozilla anytime. With 1% of the programming resources. With
likely 1-5% of the program size. Come on, even browsers like
IBrowse and such offer 90% of the functionality in 2% of the
program size.
Now the point here is --- should we? Well, could be a nice
show-off, but then they'd ask for complete compatibility with
their overcomplicated crap. It's not worth it at all IMHO. We
should be doing much better things.
Regards,
Gabriele.
--
Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer
Amiga Group Italia sez. L'Aquila --- SOON: http://www.rebol.it/
[12/19] from: petr:krenzelok:trz:cz at: 24-Jun-2004 12:49
Gabriele Santilli wrote:
>Hi Petr,
>On Thursday, June 24, 2004, 12:26:23 AM, you wrote:
<<quoted lines omitted: 6>>
>Well actually, maybe I'm the only one here, but just with AGG
>inside View
OK, let's say AGG will be implemented ...
> and a couple more font rendering features, we could
>
yes, small font system or at least "color text" face capability we
scream for for years ....
>beat Mozilla anytime. With 1% of the programming resources. With
>likely 1-5% of the program size. Come on, even browsers like
>IBrowse and such offer 90% of the functionality in 2% of the
>program size.
>
I am not so sure. Things start to slow down when parsing protocols. All
those html, xhml, whatever-ml :-) We don't have SINGLE 100% compliant
parser of higher protocols in rebol, so .... ;-) What about
certificates? Even Command can't import them - every browser/mailer can ...
>Now the point here is --- should we? Well, could be a nice
>show-off, but then they'd ask for complete compatibility with
>their overcomplicated crap. It's not worth it at all IMHO. We
>should be doing much better things.
>
The pity is, we can't have conatiners in View face. That way, we could
integrate
things like html engine, video playback into rebol window,
but we can't point sindle face pointer to some externall app
frame-buffer. I hope that changes too. So - sometimes we are week even
in deployment area ....
Simply put - Rebol kernels slept for way too long time and with new
strategy coming from RT you can bet on pekr asking for strenghtening
those universal engines, I simply don't want to see RT working in
mezzanine level - that can be done by community members like you,
Romano, Doc, Cyphre, Ladislav, Gregg and others who produce high level
quality code. RT should really open Rebol kernels by implementing things
like full VM or at least area-specific VMs (like draw dialect is),
finish proposed language components, think of full async modes
(including console) or even threading etc.
-pekr-
[13/19] from: g:santilli:tiscalinet:it at: 24-Jun-2004 15:19
Hi Petr,
On Thursday, June 24, 2004, 12:49:01 PM, you wrote:
PK> I am not so sure. Things start to slow down when parsing protocols. All
PK> those html, xhml, whatever-ml :-)
REBOL wouldn't be slower than anything else. Parsing is not the
bottleneck at all...
PK> We don't have SINGLE 100% compliant
PK> parser of higher protocols in rebol, so .... ;-)
Did anyone need it? :-)
I needed a simple xhtml parser for Temple and I did it. It's a few
lines of code. It works well enough for my needs. If you need
more, you're free to enhance it or write your own...
PK> What about
PK> certificates? Even Command can't import them - every browser/mailer can ...
I think this was just left out because it wasn't needed at the
moment. After all, SSL was mainly needed for HTTPS.
Having a more complete SSL implementation would be nice, but has
nothing to do with the language itself.
PK> Simply put - Rebol kernels slept for way too long time and with new
PK> strategy coming from RT you can bet on pekr asking for strenghtening
PK> those universal engines, I simply don't want to see RT working in
PK> mezzanine level - that can be done by community members like you,
PK> Romano, Doc, Cyphre, Ladislav, Gregg and others who produce high level
PK> quality code. RT should really open Rebol kernels by implementing things
PK> like full VM or at least area-specific VMs (like draw dialect is),
PK> finish proposed language components, think of full async modes
PK> (including console) or even threading etc.
I think the main "problem" for REBOL is that it wasn't really
meant to be a general programming language, Carl didn't probably
want to write web browsers or business applications with it.
But these are mainly implementation issues. The language itself is
general enough, much more general than most languages. So the
discussion is no more if REBOL would be good for doing these
things, but what the priority if for RT to implement the necessary
native features, if they fit the vision and so on.
The question is not if we can write something like Mozilla, the
question is, should we?
Regards,
Gabriele.
--
Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer
Amiga Group Italia sez. L'Aquila --- SOON: http://www.rebol.it/
[14/19] from: mmastroianni:fluentenergy at: 24-Jun-2004 10:16
> I think the main "problem" for REBOL is that it wasn't really
> meant to be a general programming language, Carl didn't probably
> want to write web browsers or business applications with it.
>
>SNIP<...
> Regards,
> Gabriele.
I hope by "business applications" you mean those
large monolithic database/spreadsheet/web based
thingies that have to hang together for years
until they break under their own weight.
But many "business apps" in my mind are the
small "glue" type programs that greatly
facilitate the efficiency of an organization's
function, by bridging the gap between the
behemoth
business apps. We have a lot of need
for such tools here...
Mike
Michael Mastroianni
President, Fluent Energy
[mmastroianni--fluentenergy--com]
[15/19] from: g:santilli:tiscalinet:it at: 24-Jun-2004 17:39
Hi Michael,
On Thursday, June 24, 2004, 4:16:07 PM, you wrote:
MJM> I hope by "business applications" you mean those
MJM> large monolithic database/spreadsheet/web based
MJM> thingies that have to hang together for years
MJM> until they break under their own weight.
Yep.
MJM> But many "business apps" in my mind are the
MJM> small "glue" type programs that greatly
MJM> facilitate the efficiency of an organization's
MJM> function, by bridging the gap between the
MJM> "behemoth" business apps. We have a lot of need
MJM> for such tools here...
I have written "business apps" in REBOL, so I think it's actually
very good at that. You need to be able to change the application
quickly because the needs of companies may change, or just because
the initial analysis is never 100% correct. Being able to create
prototypes quickly is a BIG win... But I'm talking custom
applications developed on demand; I understand this is not what
most people is used to do.
Regards,
Gabriele.
--
Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer
Amiga Group Italia sez. L'Aquila --- SOON: http://www.rebol.it/
[16/19] from: rotenca:telvia:it at: 24-Jun-2004 18:01
Hi people,
> > I think the main "problem" for REBOL is that it wasn't really
> > meant to be a general programming language, Carl didn't probably
<<quoted lines omitted: 3>>
> thingies that have to hang together for years
> until they break under their own weight.
Look at View Desktop, look at IOS and look at Altme.
Do they seem only glue programs?
What kind of glue are you using in you real life? :-)
---
Ciao
Romano
[17/19] from: mmastroianni:fluentenergy at: 24-Jun-2004 13:55
<SNIP>
> Look at View Desktop, look at IOS and look at Altme.
<<quoted lines omitted: 3>>
> Ciao
> Romano
Well I'm not sniffing any particular
brand of glue at the moment... :-)
I think I said "But **many** "business apps"
in my mind are the small "glue" type programs...
.... (emphasis on *many* added)
We use Alt-ME to good use here at
Fluent; and I would not call Alt-ME
a "glue" kind of app -- I was simply
referring to those useful utility
programs that help acquire and transform
data for use in larger eneerprise
applications, and which can be very
effectively designed and maintained
by scripting languages (and "messaging"
languages as well...)
Just to clarify ...
Mike
Michael Mastroianni
President, Fluent Energy
[mmastroianni--fluentenergy--com]
[18/19] from: mmastroianni:fluentenergy at: 24-Jun-2004 14:00
Hi Gabriele -
> I have written "business apps" in REBOL, so I think it's actually
> very good at that. You need to be able to change the application
<<quoted lines omitted: 6>>
> Gabriele.
> --
....custom apps developed on demand -- yes,
maybe not what most are used to, but perhaps
needed much more than generally appreciated
(I know that's the case here).
Business conditions increasingly change
*very* fast -- a good (80%) solutions now
is often worth a perfect solution later....
Regards,
Mike
Michael Mastroianni
President, Fluent Energy
[mmastroianni--fluentenergy--com]
[19/19] from: AJMartin:orcon at: 26-Jun-2004 10:56
Mike wrote:
> a "glue" kind of app -- I was simply referring to those useful utility
programs that help acquire and transform data for use in larger enterprise
applications, and which can be very effectively designed and maintained by
scripting languages (and "messaging" languages as well...)
Rebol is my secret weapon at work allowing me to transform data to/from MS
Excel in XML format, using my ML dialect, and from old BASIC databases using
my Fixed dialect.
--
Andrew J Martin
ICQ: 26227169
http://www.rebol.it/Valley/
http://valley.orcon.net.nz/
http://Valley.150m.com/
Notes
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted