facts we will have to face ...
[1/36] from: petr:krenzelok:trz:cz at: 23-Oct-2001 18:51
Hi,
reactions to OSNews.com interview really seem as a little bit of
advertisement of rebol fan ;-) But I think we will have to face following
voices in future:
----------
Since apparently everyone here but me is a REBOL worshiper, I've got some
questions...
(I would look for the answers on my own, but I have to leave in a about 2
minutes, so I figured this would give all of you something to do :-)
Can REBOL do audio? Does it support MP3 native? How about more obsure audio
formats? If not, is it fast enough to decode it if you wrote the decoder in
REBOL itself?
What about movies? Can it play sorenson quicktimes? Does it have support for
AVI? Once again, you should be able to add in movie support or codec support
by writing it in REBOL itself assuming it truely is a complete platform like
they say it is.
I thought I had some more questions, but I can't think of them now. Gotta
run.
Sean
----------
I mean - if Rebol should be regarded being platform, it would have to enable
us to implement "whatever" in the language itself, not being dependant upon
language kernels directly - I mean - sound, video, math, etc., the area
where rebol speed will be badly noticed.
I think that maybe RT should prepare some FAQ answers regarding this issue,
because if Rebol will become popular, newcomers will ask about possibility
to compile and speed things up ....
-pekr-
[2/36] from: pwoodward:cncdsl at: 23-Oct-2001 13:37
I think some of these are actually valid concerns...
> Can REBOL do audio? Does it support MP3 native? How about more obsure
audio
> formats? If not, is it fast enough to decode it if you wrote the decoder
in
> REBOL itself?
REBOL can "do audio" - it is able to play .wav files. Native MP3 support
isn't in there as far as I know. While that would be nice, I'm not sure
it's necessary at this juncture. OTOH maybe being able to launch apps for
playback, much like launching a web browser would be a good interim
solution. But, I seriously doubt that a MP3 decoder would be terribly fast
written in REBOL. Perhaps one of the cross-platform audio libraries would
be handy for this... A standardized REBOL library wrapper around a widely
available mp3 (or other) audio library might meet the need.
> What about movies? Can it play sorenson quicktimes? Does it have support
for
> AVI? Once again, you should be able to add in movie support or codec
support
> by writing it in REBOL itself assuming it truely is a complete platform
like
> they say it is.
Very similar question to the first one. Again, a solution might be to allow
for the "launch" of a player outside of REBOL. Trying to embed video
playback tools into REBOL would likely swell the size of the application
well beyond it's relatively tiny footprint. AVI and Quicktime support are
handled by 2 downloads which are over 5MB each on the Windows platform -
since QT .movs aren't handled well by MediaPlayer, and MediaPlayer formats
don't play well on QT...
Perhaps a basic MPG format would be ideal. MPG playback codecs are freely
available for a wide variety of platforms, and seem to manage fairly well on
even mediocre hardware (my old '020 A1200 managed em fine).
> I mean - if Rebol should be regarded being platform, it would have to
enable
> us to implement "whatever" in the language itself, not being dependant
upon
> language kernels directly - I mean - sound, video, math, etc., the area
> where rebol speed will be badly noticed.
Very good point. A possible solution might be something similar to the
mechanism employed in a number of JVMs. They cache native code that has
been interpreted. Or perhaps a nice (for pay) way to do it would be REBOL
accelerator plugins - which feature optimization of certain segments of the
REBOL interpreter... Seamlessly replacing how certain code is interpreted
and executed to accelerate certain types of math operations, or whatever...
> I think that maybe RT should prepare some FAQ answers regarding this
issue,
> because if Rebol will become popular, newcomers will ask about possibility
> to compile and speed things up ....
While on the one hand, it's a safe bet that computational power will
increase, and so will users effective bandwidth (witness more peer-to-peer
solutions) I'm unwilling to be _greedy_ about resources. JVMs are typically
a hog when it comes to that. Once up and running, they can be pretty speedy
for most general user tasks. Hard-core math tends to suffer under Java -
but sometimes (esp. in scientific apps) the portability is worth it.
Accelerating the JVM has been a long, slow process of optimization.
Essentially the most advanced ones incorporate a profiler into the code
caching algorithm. Some unroll loops. All of them use more RAM.
Food for thought.
- Porter
[3/36] from: petr:krenzelok:trz:cz at: 23-Oct-2001 21:00
> > I mean - if Rebol should be regarded being platform, it would have to
enable
> > us to implement "whatever" in the language itself, not being dependant
upon
> > language kernels directly - I mean - sound, video, math, etc., the area
> > where rebol speed will be badly noticed.
>
> Very good point. A possible solution might be something similar to the
> mechanism employed in a number of JVMs. They cache native code that has
> been interpreted. Or perhaps a nice (for pay) way to do it would be REBOL
> accelerator plugins - which feature optimization of certain segments of
the
> REBOL interpreter... Seamlessly replacing how certain code is interpreted
> and executed to accelerate certain types of math operations, or
whatever...
Another ones from OSNews:
--------
I've read about rebol when it first came out and I always get the same
impression. So please straighten me out. What I always come out feeling is
that Rebol is powerful because its libraries are powerful.
For example, Rebol claims to make writing an email client easy. But that is
just because it has email address as a datatype and SMTP built-in. You can
do the same with the appropriate libraries in any language.
Another example is the parsing stuff: while it provides the possible to
parse input, I've never seen an example where the syntax was really
augmented vs. the basic Rebol syntax. They always end-up with some keywords,
some modifiers introduced by a slash and block ([]). Would it be really
possible to create an entirely different syntax as a dialect? Could I write
for example a PostScript dialect that would read pure PostScript, except for
an enclosing context?
What about performance and control? Could I write an image processing
library that would process CMYK images (instead of RGB)?In short, all I've
read about only reflects that the Rebol syntax is simple and the bundled
libraries are internet-oriented. To me Rebol code looks like a slightly more
evolved LISP: replace ( with [, ' with ! and , with / ;-)
Eugenia (IP: ---.proxy.aol.com) wrote on 2001-10-23 17:48:31 Re: Anonymous
The way I understand it, Rebol is an internet language. If you want to write
a Photoshop or Office alternative you are much better off with Python than
with Rebol (I am mentioning Python and not something like C or Java, because
it is similar to what rebol can do for the Net for Python to do as a
standard and simple *interpreted* language for the desktop).
--------
Rebol is great architecture in general. It allows easy and relatively fast
things for what is "inside". I know that Rebol serves its intended purposes
wery well, I just wonder if there is any solution to be able to use Rebol as
general programming language, so resulting apps would be fast enough.
We have native level performance - ports - the idea is very good imo - you
open the purpose port, throw data into it, wait on it, copy result, close
it. I understand ports are being some code reactors/engines, and unified
port mechanism is abstraction to give us unified aproach.
I can imagine RT will add another ports - 3D, etc. If rebol will get big in
size, time to finally introduce dynamic components, as not everyone needs
some specific functionality.
Sometimes APIs to REBOL internals would be handy, as it gives us more
possibilities, and it is always good to not be limited. I can imagine View
kernel effect pipeline becoming another kind of port - open it, set-it-up,
throw data into it, and get your result .....
Just my evening imagination :-)
[4/36] from: carl:cybercraft at: 24-Oct-2001 11:05
On 24-Oct-01, Petr Krenzelok wrote:
> Hi,
> reactions to OSNews.com interview really seem as a little bit of
> advertisement of rebol fan ;-) But I think we will have to face
> following voices in future:
> ----------
> Since apparently everyone here but me is a REBOL worshiper,
Chuckle. So far I've not managed to convince anyone to hop on board
the REBOL ship - neither programmers nor non-programmers. The
programmers are happy with the languages they already know, while
it's hard to convince typical users of REBOL's value. "What's the
point of a desktop on top of your desktop?" And distributed
computing worries them, they not liking the idea of their apps being
automatically updated and feel it's the thin edge of the wedge
towards a world where you rent your software.
That said, I'm sure companies with workers in many different locations
are easier to convince of REBOL's value.
> Can REBOL do audio? Does it support MP3 native? How about more
> obsure audio formats? If not, is it fast enough to decode it if you
> wrote the decoder in REBOL itself?
This from the OSNews interview...
From the system side, we will add several new
dialect" engines for
3D graphics, inferencing ("AI"), additional network protocols,
advanced sound synthesis, and more."
Hopefully an "advanced sound synthesis" dialect will give us good
audio control and include native MP3 support. I doubt decoders
written in REBOL would be fast enough though given the amount of
decompression required.
> What about movies? Can it play sorenson quicktimes? Does it have
> support for AVI? Once again, you should be able to add in movie
> support or codec support by writing it in REBOL itself assuming it
> truely is a complete platform like they say it is.
Okay, an idea. Let's assume REBOL has its own internal format for
music, movies and such, as it has with images. What's needed are
libraries that cam convert the various formats into REBOL format (and
back again for saving.) These libraries need to be cross-platform -
not OS-specific.
So, how about if RT creates a simple virtual-processor and
virtual-machine-code dialect that's designed specifically for
converting one file into another? JPG-to-image!, image!-to-JPG and
so on. (For once RT wouldn't need to worry about this being simple
to use, as those happy with machine-code are the only ones who'd
bother with it. All they'd need to worry about is that it's fast.)
Then, as long as RT publish the specs for their image!, movie! and so
on datatypes, others could write the libraries for converting the
various outside formats to and from the REBOL native formats.
Anything wrong with this idea?
--
Carl Read
[5/36] from: petr:krenzelok:trz:cz at: 24-Oct-2001 8:26
Carl Read wrote:
> > Can REBOL do audio? Does it support MP3 native? How about more
> > obsure audio formats? If not, is it fast enough to decode it if you
<<quoted lines omitted: 7>>
> written in REBOL would be fast enough though given the amount of
> decompression required.
Yes, and that's what author meant. We are dependant upon what RT adds to
their engines, and RT is very carefull and selective here, because of the
size of executable. Two days ago Holger here explained situation with JPEG
saving.
Well, Rebol is nice collection of functionality. You can do many usefull
apps using Rebol, and I hope it will even become better. We can of course
link to native libraries, but then we lose multiplatform advantage. The
only solution here would be Tao-like virtual processor. But that's not
likely to happen anytime soon.
Maybe Holger or Carl could comment here? What is their point of view to
let's say some post Rebol 3.0 future?
btw: Could anyone enlighten me and describe, how Python solves such issue
of interpreter speed? IIRC, Python can link C code, but then - you lose
multiplatform advantage too ... so?
> So, how about if RT creates a simple virtual-processor and
> virtual-machine-code dialect
I am not sure it is so easy :-) Maybe it would be better to partner with
Tao, as they cover many platforms, and allow their VP code includes ...
-pekr-
[6/36] from: maksa:sezampro:yu at: 24-Oct-2001 9:27
Petr Krenzelok wrote:
>> btw: Could anyone enlighten me and describe,
>> how Python solves such issue of interpreter speed?
From my experience - it doesn't. ;)
A little story: I have a co-worker who is a Perl bigot when it comes to
scripting, and we sometimes have language-pissing matches. But they're
constructive, in a "talk-is-cheap,
so-prove-whatever-you're-saying-by-writing-code"
sense. We both learn in the process, so we don't feel so bad after all about
doing
what is realy a stupid thing - arguing about languages. Now, one of the
matches
was a task to write a fast and extensible cross-referencing program for web
sites
that the web part of the company is producing. The task was to find how many
ADO VBScript constants are actually being used from the 12 Kb file included
on
almost every ASP page. He wrote his in Perl, I wrote mine in Python. His was
the
cleanest and most readable Perl code I've ever seen (but I should say that I
haven't
seen much Perl code, it's not easy on the eyes ;), and it was pretty damn
fast.
My Python code looked a lot better, but it was a *real* catastrophy when it
came to
performance. So I rewrote mine in Ruby while fully retaining the Python
programs
structure. Speed gain was incredible. Results:
Ruby: 0.82 s
Perl 3.50 s
Python: 17.2 s
Results are obtained after running each program several times to equalize
their
file caching opportunities, etc.
This, of course, doesn't prove much, except that Python is way slower when
processing files and doing string matching, and that Ruby had some clever
speed tricks when it came to that.
I'm sorry to say that my Rebol knowledge was (and probably still is, but I'm
working
on that) inadequate at the time to write the thing in Rebol. I think I'll go
and do it now.
Sorry if the whole post was an off-topic drag, but I just couldn't keep my
mouht shut
when I saw "Python" and "interpreter speed" in the same sentence. :)
Regards,
Maksa
[7/36] from: carl:cybercraft at: 24-Oct-2001 20:15
On 24-Oct-01, Petr Krenzelok wrote:
>> So, how about if RT creates a simple virtual-processor and
>> virtual-machine-code dialect
> I am not sure it is so easy :-)
I don't see why not. My suggestion is only for converting files, not
linking to hardware. Perhaps virtual processor wasn't the right
word. How about just a simple language for throwing bits and bytes
around that runs as close to machine-code speed as possible?
--
Carl Read
[8/36] from: matt::fitzgerald::bigpond::com at: 24-Oct-2001 17:43
Something like AMOS for the Amiga? :-) That was pretty damn fast...
Anyway, this would be a fairly good project to attempt, obviously one
couldn't concurrently write such code for all processors (maybe they can, I
couldn't!). I don't know much about writing hooks and stuff for Rebol but I
_could_ see how a generic machine-code like language could be written in a
Rebol-like syntax, mapping that syntax back to low-level machine code for
individual architectures would be what you're trying to achieve. I guess
you'd need some kind of in-memory assembler. If anyone wants to be more
specific on this e-mail me, my Rebol skills aren't that crash hot, but I
know 680x0 pretty well!
-Matt
[9/36] from: carl:cybercraft at: 24-Oct-2001 21:07
On 24-Oct-01, Matt Fitzgerald wrote:
> Something like AMOS for the Amiga? :-) That was pretty damn fast...
Yeah - by accessing the hardware...
But no - not like AMOS! All you need to be able to do is convert one
file (or bitstream) to another format. That's all it should be for.
> Anyway, this would be a fairly good project to attempt, obviously
> one couldn't concurrently write such code for all processors (maybe
> they can, I couldn't!). I don't know much about writing hooks and
> stuff for Rebol but I _could_ see how a generic machine-code like
> language could be written in a Rebol-like syntax,
Forget the REBOL-like syntax. Keep it as near to machine-code syntax
as possible, so it can be made as fast as possible for each processor
it's converted to.
> mapping that
> syntax back to low-level machine code for individual architectures
<<quoted lines omitted: 17>>
> --
> Carl Read
--
Carl Read
[10/36] from: robert:muench:robertmuench at: 24-Oct-2001 10:04
Hi, I might not understand the discussion.. .but why should Rebol be used for
things it's not made for? I don't see a need to play MP3s, or movies. If I need,
I just use a MP3 player or movie player not a script language...
Did you ever see a farmer working with a Formula1 racing car in the fields? I
didn't. There is this old saying: Use the right tool for the job.
I hope RT will balance wise what they put into the kernel and what not. I like
the one-file approach and not to have to worry about libraries! This is a USP
for Rebol IMO. Rebol should be kept small like it is and optimized not feature
overloaed. Robert
[11/36] from: matt:fitzgerald:bigpond at: 24-Oct-2001 19:01
I agree to some extent, but should we really restrict the functionality of
any language? A language has to be expressive and the more you can express
and the way you express it, the more elegant it is. It's like the English
language, the vocabulary is large but how much do we really use? Not much,
but the extra words (or functionality if you like) still exist for those
that DO wish to use them.
If you limit a language to specific tasks then it's not a language as such,
it's an application designed to do a specific task(s) with it's own command
set. I agree that what makes Rebol is its simplicity but surely there
should be some avenue of taking things further?
-Matt
[12/36] from: carl:cybercraft at: 24-Oct-2001 21:57
On 24-Oct-01, Robert M. Muench wrote:
> Hi, I might not understand the discussion.. .but why should Rebol be
> used for things it's not made for? I don't see a need to play MP3s,
> or movies.
I do, as I want to be able to write scripts that can play them with
just the press of a button. Also, I think you may be wrong when you
say it wasn't made to play them. I'm sure multi-media support's been
in REBOL's design specs from day one.
> If I need, I just use a MP3 player or movie player not a
> script language...
The same could be said for viewing images. But anyway, RT have
signalled they're going to support 3D and sound, so it is coming.
(When though's another matter.:)
> Did you ever see a farmer working with a Formula1 racing car in the
> fields? I didn't.
No, but I've seen plenty of tractor drivers wearing stereo headphones.
(:
> There is this old saying: Use the right tool for
> the job.
> I hope RT will balance wise what they put into the kernel and what
> not. I like the one-file approach and not to have to worry about
> libraries! This is a USP for Rebol IMO. Rebol should be kept small
> like it is and optimized not feature overloaed. Robert
I do too, but functionality's important as well, and if libraries
could get around problems like View's inability to save jpegs, (as
discussed in another recent thread), that'd be a good thing in my
opinion. REBOL/multimedia would then only need to directly support
one music format, one movie format and so on, with conversion to and
from other formats being done by the libraries when necessary.
--
Carl Read
[13/36] from: lmecir:mbox:vol:cz at: 24-Oct-2001 13:08
Hi Maksa,
...
> structure. Speed gain was incredible. Results:
>
> Ruby: 0.82 s
> Perl 3.50 s
> Python: 17.2 s
...
> Sorry if the whole post was an off-topic drag, but I just couldn't keep my
> mouht shut
> when I saw "Python" and "interpreter speed" in the same sentence. :)
>
> Regards,
> Maksa
Thanks for your info. It surely wasn't off-topic!
[14/36] from: g:santilli:tiscalinet:it at: 24-Oct-2001 14:06
Someone wrote:
> For example, Rebol claims to make writing an email client easy. But that is
> just because it has email address as a datatype and SMTP built-in. You can
> do the same with the appropriate libraries in any language.
Ahah! Just make me see that. :-)
Anyway, it's natural to have such reactions. We can't expect REBOL
to be loved by the mass.
Regards,
Gabriele.
--
Gabriele Santilli <[giesse--writeme--com]> - Amigan - REBOL programmer
Amiga Group Italia sez. L'Aquila -- http://www.amyresource.it/AGI/
[15/36] from: holger:rebol at: 24-Oct-2001 6:26
On Wed, Oct 24, 2001 at 08:26:51AM +0200, Petr Krenzelok wrote:
> Well, Rebol is nice collection of functionality. You can do many usefull
> apps using Rebol, and I hope it will even become better. We can of course
> link to native libraries, but then we lose multiplatform advantage.
Yes, but for Quicktime, RealAudio/Video and a lot of other standards
that is the only solution, because these formats require codecs that
implement the patented image/sound compression schemes.
That also means that it is unlikely that there will ever (within the
next 17 years anyway) be truly cross-platform support for these
standards, whether in REBOL or in any other environment.
The best possible solution is to work within the APIs and dev kits
that companies like Apple or RealMedia provide, and implement support
in REBOL by accessing their libraries. Of course this means that not
all platforms can be supported. We have looked into that, and
it seems possible, but at the moment other things have higher
priorities. Would be an interesting third-party project though:
all you need is View/Pro, the dev kit and a lot of time :-).
> The
> only solution here would be Tao-like virtual processor. But that's not
> likely to happen anytime soon.
It would not make any difference because of the legal situation.
For most of the codecs even a complete white-room reimplementation
from scratch in VM would still be illegal.
--
Holger Kruse
[holger--rebol--com]
[16/36] from: jasonic:nomadics at: 24-Oct-2001 9:31
> structure. Speed gain was incredible. Results:
>
> Ruby: 0.82 s
> Perl 3.50 s
> Python: 17.2 s
yes interesting..
I hope you post the details with code to the comp.lang.python to see what
can be learnt. And hopefully alternate techniques/optimizations which can
alter this big difference. Lost to learn all around I am sure
Looking forwards to your Rebol version too. Keep us posted please
- Jason
[17/36] from: pwoodward:cncdsl at: 24-Oct-2001 10:35
Holger -
> On Wed, Oct 24, 2001 at 08:26:51AM +0200, Petr Krenzelok wrote:
> > Well, Rebol is nice collection of functionality. You can do many usefull
> > apps using Rebol, and I hope it will even become better. We can of
course
> > link to native libraries, but then we lose multiplatform advantage.
>
> Yes, but for Quicktime, RealAudio/Video and a lot of other standards
> that is the only solution, because these formats require codecs that
> implement the patented image/sound compression schemes.
What about using a "launch" feature similar to the "browse" function? On
the other hand - I'm pretty certain that using "browse" on a media type that
your browser (IE/NS/Moz, etc) understands will cause the appropriate player
to launch... In fact, after testing it with a one-liner, I know it does.
browse %01.avi
It doesn't even launch the browser window (or if it did, the browser window
closed so quickly I didn't see it). Pretty cool. Wow - multimedia
support
w/o even having to really extend REBOL.
> The best possible solution is to work within the APIs and dev kits
> that companies like Apple or RealMedia provide, and implement support
<<quoted lines omitted: 3>>
> priorities. Would be an interesting third-party project though:
> all you need is View/Pro, the dev kit and a lot of time :-).
Even this would be a PITA. I'm not sure, but somehow I doubt that
REBOL/View in any form has a great amount of compatibility with the
underlying OS and APIs. On Windows, the playback area of the media player
is a pretty special display viewport - trying to embed that into a
REBOL/View interface could be impossible w/o some serious changes to the
engine (just guessing here). While one could use a codec library to
decompress and hand back display information to REBOL - you'd then have to
have a REBOL native routine to translate those bytes into something the
/View engine could handle...
That's a lot of data shutlling in and out of the REBOL engine to the library
and back. Much like dealing with components in an ASP website, or thunking
native code from within Java - there is a performance penalty to marshal the
argument data that gets handed into the native code - and then handed back
to the caller. So you better be sure that what you're handing out to be
processed can be processed much quicker - quick enough to offset any
penalties from marshalling all that data.
- Porter
[18/36] from: media:quazart at: 24-Oct-2001 11:14
----- Original Message -----
From: "Carl Read" <[carl--cybercraft--co--nz]>
To: <[rebol-list--rebol--com]>
Sent: Wednesday, October 24, 2001 5:57 AM
Subject: [REBOL] Re: facts we will have to face ...
> On 24-Oct-01, Robert M. Muench wrote:
> > Hi, I might not understand the discussion.. .but why should Rebol be
<<quoted lines omitted: 4>>
> say it wasn't made to play them. I'm sure multi-media support's been
> in REBOL's design specs from day one.
yeah and if you have /pro its a sinch to provide most of the things related
to conversion with external converter/players... to prove my point, that's
one of the things I do with rebol myself...
>But anyway, RT have
> signalled they're going to support 3D and sound, so it is coming.
> (When though's another matter.:)
sound IS supported... .wav files (only in /pro... which is a shame, maybe
its just a temporary support thing, maybe not)
> > Did you ever see a farmer working with a Formula1 racing car in the
> > fields? I didn't.
>
> No, but I've seen plenty of tractor drivers wearing stereo headphones.
> (:
And I've seen tractor racing ;-) it was fun to watch :-)
>REBOL/multimedia would then only need to directly support
> one music format, one movie format and so on, with conversion to and
> from other formats being done by the libraries when necessary.
I have a hunch its on RT's to do list already...
-MAx
[19/36] from: holger:rebol at: 24-Oct-2001 8:16
On Wed, Oct 24, 2001 at 10:35:54AM -0400, Porter Woodward wrote:
> Even this would be a PITA. I'm not sure, but somehow I doubt that
> REBOL/View in any form has a great amount of compatibility with the
> underlying OS and APIs. On Windows, the playback area of the media player
> is a pretty special display viewport - trying to embed that into a
> REBOL/View interface could be impossible w/o some serious changes to the
> engine (just guessing here).
AFAIR at least RealMedia uses COM objects as its rendering areas, i.e.
you could write a wrapper DLL that implements a COM rendering area
which is simply a frame buffer that sends REBOL a WinMsg once there is
new data. REBOL could wait for that message in its main loop (a feature
for the next version of View), call the library to fill in an image
with the buffered data, attach it to a face, and 'show the face. This
is really not much different from how other players do it in terms of
overhead.
--
Holger Kruse
[holger--rebol--com]
[20/36] from: media:quazart at: 24-Oct-2001 11:29
----- Original Message -----
From: "Matt Fitzgerald" <[matt--fitzgerald--bigpond--com]>
To: <[rebol-list--rebol--com]>
Sent: Wednesday, October 24, 2001 5:01 AM
Subject: [REBOL] Re: facts we will have to face ...
> I agree to some extent, but should we really restrict the functionality of
> any language? A language has to be expressive and the more you can
express
> and the way you express it, the more elegant it is. It's like the English
> language, the vocabulary is large but how much do we really use? Not
much,
> but the extra words (or functionality if you like) still exist for those
> that DO wish to use them.
yep and try to express any physical theory without using mathematical
terms... funny... a whole book of english explaning translates into one
mathematical expression ...
Some languages ARE meant for some things. REBOL allows you to change
dialects... so you canadapt your code (expression) to the situation... How
can it become more expressive !?
The language itself isn't restrictive. the limits were set because of an
exact goal... portability. If Rebol were 38 MB to install and relied on 345
other software extensions and then was only supported on 2 platforms... I
would not be using REBOL... period.
Yes, a little more in the terms of raw Multimedia would be nice but not in
the way of additional formats ... more like in additional mediums. I'd also
like a little more polish in draw (like anti-alising) and some other effects
(like alpha channel) but that's normal. Give me those and I'll want
something more.
I'd also like an API but then just use /pro with shared libs and that's
exactly what you've got.
-Maxim
[21/36] from: robert:muench:robertmuench at: 24-Oct-2001 17:36
> -----Original Message-----
> From: [rebol-bounce--rebol--com] [mailto:[rebol-bounce--rebol--com]]On Behalf
<<quoted lines omitted: 5>>
> any language? A language has to be expressive and the more you can express
> and the way you express it, the more elegant it is.
Hi, well it depends on. The C guys strategy was: Here you have a couple of
keywords to work with. With them you
can express all you want, go for it. And the mass did gone for it.
Is playing a movie or a sound file a language functionality? I don't think so
others might think it is. I like RT approach to implement several high-level
functions/words with Rebol itself. So what we have is a mix: One part is the
core-interpreter (Ups, that's the name of the product ;-)) and we have an
integrated standard-library. View is adding a GUI library and IOS is the
application framework. Where to put sound and movie functionality?
As soon as such a support needs native speed, it needs to be put into the core
from the concept view... I'm not sure if this is the way to go.
It's very hard to balance where to put features into and on what kind of
implementation level to do it. Robert
[22/36] from: greggirwin:mindspring at: 24-Oct-2001 10:27
Hi Robert, et al
<< I don't see a need to play MP3s >>
MP3 is a popular format. If you could write a small MP3 player that was
eaiser to skin than WinAmp, it could reach a large audience. Is it worth it
for that? I don't know (I'm not a big MP3 fan myself).
As far as other MM related niceties, I think I would rather have RT spend
time on an audio "compositing" system, like View has for images, or a
real-time WAV mixing system. Playing multiple sounds simultaneously, and
things like looping, are important in many cases, mostly gaming.
What about MIDI support?
--Gregg
[23/36] from: petr:krenzelok:trz:cz at: 24-Oct-2001 18:43
----- Original Message -----
From: <[holger--rebol--com]>
To: <[rebol-list--rebol--com]>
Sent: Wednesday, October 24, 2001 5:16 PM
Subject: [REBOL] Re: facts we will have to face ...
> On Wed, Oct 24, 2001 at 10:35:54AM -0400, Porter Woodward wrote:
> > Even this would be a PITA. I'm not sure, but somehow I doubt that
> > REBOL/View in any form has a great amount of compatibility with the
> > underlying OS and APIs. On Windows, the playback area of the media
player
> > is a pretty special display viewport - trying to embed that into a
> > REBOL/View interface could be impossible w/o some serious changes to the
<<quoted lines omitted: 4>>
> new data. REBOL could wait for that message in its main loop (a feature
> for the next version of View),
Well, could you elaborate here a little bit, please? Is that only Windows
View capability??? Is it applicable to 'odbc e.g. too? Or just only View
stuff?
btw: is ability to generate own events coming with next release?
> call the library to fill in an image
> with the buffered data, attach it to a face, and 'show the face. This
> is really not much different from how other players do it in terms of
> overhead.
Well, I am not sure if I am right, but I tried together with my friend, who
is fluent in C, to implement small piece of code, which modifies face data
directly in memory, and it works. So basically, once you send your image
referring word to .dll routine, you can manipulate its data directly in
native level, and once you get back to Rebol, you just need to re-show it.
It works, and is fast. As image effects are just data manipulation, maybe we
(rebol community) could even create some effect library, which could be
relatively easily compiled to support Rebol on most if not all platforms it
is available for?
-pekr-
[24/36] from: doublec:acc at: 25-Oct-2001 9:53
>btw: Could anyone enlighten me and describe, how Python solves such issue
>of interpreter speed? IIRC, Python can link C code, but then - you lose
>multiplatform advantage too ... so?
I don't know about the Python situation but Squeak [1] handles the situation in a couple
of ways. One is to write the code in 'C' and load it as a dynamic library or link it
in. If the extension is popular enough people port that 'C' library to the other platforms.
Another approach taken is to write the extension in a cut down Smalltalk dialect which
Squeak can compile to 'C' code and is then linked in. This becomes more portable across
the platforms but still requires a bit of tweaking across platforms.
This is how the 3D engines became optimised. They started in smalltalk and then various
parts of it were written as 'plug-ins' to get more speed. The MP3 and MPG support started
with using an open source library that did all the work and passed the image/sound data
to Squeak which then blasted it to the screen or sound system. Worked quite well.
Since REBOL has the ability to load dynamic libraries and call C functions (Pro only?)
then similar could be done there.
[1] http://www.squeak.org
Chris.
http://www.double.co.nz/dylan
[25/36] from: ammonjohnson:yah:oo at: 24-Oct-2001 17:36
----- Original Message -----
From: "Porter Woodward" <[pwoodward--cncdsl--com]>
To: <[rebol-list--rebol--com]>
Sent: Wednesday, October 24, 2001 7:35 AM
Subject: [REBOL] Re: facts we will have to face ...
<Snip>
> Even this would be a PITA. I'm not sure, but somehow I doubt that
<<quoted lines omitted: 6>>
> have a REBOL native routine to translate those bytes into something the
> /View engine could handle...
You got me thinking, & Holger will have to answer this one. (if it is
answerable) It would be cool to provide some sort of STYLE? (not sure I am
using the right terminology) that would allow for redirecting the display of
different programs into them.
[26/36] from: robert:muench:robertmuench at: 25-Oct-2001 18:46
> -----Original Message-----
> From: [rebol-bounce--rebol--com] [mailto:[rebol-bounce--rebol--com]]On Behalf
<<quoted lines omitted: 6>>
> eaiser to skin than WinAmp, it could reach a large audience. Is it worth it
> for that? I don't know (I'm not a big MP3 fan myself).
Hi, well I have to refine my statement: I don't see a need to play MP3s from
business applications ;-)) And yes, I see Rebol's market there. But for this
market other features/optimizations are more needed.
So I might be not the mainstream-guy to ask on this topic... Robert
[27/36] from: joel:neely:fedex at: 25-Oct-2001 14:39
Hi, Robert,
Do you consider presentations to be a business application?
Robert M. Muench
wrote:
> Hi, well I have to refine my statement: I don't see a need to
> play MP3s from business applications ;-)) And yes, I see Rebol's
> market there. But for this market other features/optimizations
> are more needed.
>
Think of a presentation (e.g., the example on the RT site)
which might include suitable audio clips either as:
1) background music
2) per page audio sound bite
3) on-demand (e.g. button click) audio information
Also consider the possibility of audio feedback in an O/S neutral
manner, such as alerts to signal completion of a long-running
process, receipt of a new message, timeout on an error dialogue
to which the user has not responded in a timely manner, etc.
It seems reasonable to consider MP3 as a "generic" audio format
for use an *any* situation requiring audible signals/information
by analogy with the fact that JPEG and PNG are "generic" graphic
formats that can be used in any situation requiring non-text
display of information (whether charts, photos, or just eye
candy...)
Just my $0.02.
-jn-
--
This sentence contradicts itself -- no actually it doesn't.
-- Doug Hofstadter
joel<dot>neely<at>fedex<dot>com
[28/36] from: robert:muench:robertmuench at: 26-Oct-2001 15:05
> -----Original Message-----
> From: [rebol-bounce--rebol--com] [mailto:[rebol-bounce--rebol--com]]On Behalf Of
<<quoted lines omitted: 3>>
> Subject: [REBOL] Re: facts we will have to face ...
> Do you consider presentations to be a business application?
Hi, no. It's a tool for communication but it's not a business application you
earn money with (only consultants like me do this ;-)). You use it to talk about
a business application.
> Think of a presentation (e.g., the example on the RT site)
> which might include suitable audio clips either as:
Well, in real business no one cares to much about internal presentations (only
marketing does). I hope never to have presentations with sound, it's hard enough
to view all the colorful and bad-designed charts and woerse if animation is
used.
I don't think you can replace PowerPoint here... and it doesn't make sense. Much
better way to go is, create a Rebol presentation and export it to Powerpoint.
But this will be a working-process-optimizer step, no suitable for most people
to use, but it would optimize my schedule. Robert
[29/36] from: petr:krenzelok:trz:cz at: 26-Oct-2001 15:20
Robert M. Muench
wrote:
> > -----Original Message-----
> > From: [rebol-bounce--rebol--com] [mailto:[rebol-bounce--rebol--com]]On Behalf Of
<<quoted lines omitted: 14>>
> I don't think you can replace PowerPoint here... and it doesn't make sense. Much
> better way to go is, create a Rebol presentation and export it to Powerpoint.
Yes, you can't replace PP. As for presentations - Scala is e.g. definity much
better, smoother, everything than PP .... But, as for Rebol, I think that you could
use some kind of Encapped player app, featuring presentation scripts/dialects ....
that way you could distribute your presentations ...
If you want other ppl (business ppl) to see your presentation though, you are right
that you would be better with PP probably, as nearly every office owns MSOffice
already.
As for multimedia presentations (Scala), Rebol doesn't provide us level of Scala
presentations smoothness/quality, and multimedia is not RT's priority for near
future, so ....
-pekr-
[30/36] from: joel:neely:fedex at: 26-Oct-2001 9:23
Hi, Robert,
Well,... YMMV.
Robert M. Muench
wrote:
> > Think of a presentation (e.g., the example on the RT site)
> > which might include suitable audio clips either as:
>
> Well, in real business no one cares to much about internal
> presentations (only marketing does)...
>
All I can say is that there are times when people where I work
care *very* much about internal presentations (e.g., training,
presenting business case for mgt approval, keeping loosely-
coordinated groups in synch, training some new suit to what
a department does, etc. ad infinitum...)
Those are all just as much a part of "real business" IMHO as
retail sales or consulting.
> I don't think you can replace PowerPoint here... and it
> doesn't make sense.
>
The way I understood the message of
http://www.rebol.com/reblets.html#presenter
that's *exactly* the point (and sense). What if someone is
using a box that doesn't run anything from Redmond? Are they
not doing "real business" and therefore disqualified from
viewing/participating? The idea of a platform-agnostic
presentation capability (especially if it supports real-time
interactivity) makes tremendous sense to me, for all kinds of
reasons. And I think RT has proven that it can be done.
In the extreme case, send the entire presentation AND /View
on a single diskette/email. They'll easily fit!
-jn-
--
This sentence contradicts itself -- no actually it doesn't.
-- Doug Hofstadter
joel<dot>neely<at>fedex<dot>com
[31/36] from: greggirwin:mindspring at: 26-Oct-2001 12:20
Hi Robert, et al
<< > Do you consider presentations to be a business application?
Hi, no. It's a tool for communication it's not a business application you
earn money with (only consultants like me do this ;-)). You use it to talk
about
a business application. >>
I won't dive into the "what is a business application" side of the
conversation here beyond saying I agree with Joel on this one. The key
phrase, though, in your response is "It's a tool for communication". That's
*exactly* right.
Right now we're talking about a business presentation context, but that's
just 'the tip of the tip of the iceberg' (I use that phrase a lot when
telling people about REBOL to point out how far we have still to go to
exploit its capabilities) and an isolated example.
REBOL is a messaging language first and foremost. Most of us on the list
seem to be using it to play around in areas we're familiar with and haven't
even touched the messaging side of things, not far beyond basic remote
access and e-mail. Maarten is pushing things with remote service invocation,
which is targeted at developers like us and is for messaging at the program
level.
When you said "It's a tool for communication" I interpret it to mean
communication between humans, not programs and machines. This is where REBOL
should *really* shine. Cybarite has done a nice VID sample called EV-Pres
which uses EasyVID as its basis. Jeff has also done a little
animation/presentation engine. Then there's Oldes' slide show sample. With
these, and looking at IOS' Presenter reblet screen-shot, it should be clear
that you *could* build a presentation app to compete with PowerPoint. Most
people only want/need/use probably 1% of the functionality in the current MS
Office apps. But I digress...
REBOL's real power will shine when we think in terms of communication apps
that let specialists use the nomenclature of their repsective fields and we
exchange messages that are readable both by humans and by REBOL.
PowerPoint is a great example of what works in the context of a controlled
environment not working outside of a controlled environment. It's a closed
format and not easily distributed. People send me PPS files and I can't view
them and I'm running W2K! My wife can't run them on her iMac, and they take
*forever* to download. If I can't see the data, the communcation link has
failed utterly.
What other kinds of presentations could there be, besides marketing, you
ask? Well, how about animated algorihtms for CS classes, or a project status
presentation that shows you the gantt chart and you watch as the individual
timelines animate to show the progress of each item? What about adapting the
concept of Literate Programming to this area? Literate Presentations would
let you write your research report on opthamology as a regular report but it
could also be used to drive your presentation of the subject matter.
Sorry to ramble on here but I'm just about jumping out of my chair thinking
about the possibilities. Maybe because I had such a hard time getting
PowerPoint to work for me when I did presentations and they said I *had* to
use it. Switching between the machined running PP and the machine running my
example code was a pain. Inevitably you'd forget once or twice and the
audience would have to yell "SWITCH THE SCREEN!" because they couldn't see
the code you were typing. What we need is a "presentation IDE" for REBOL. :)
--Gregg
[32/36] from: al:bri:xtra at: 27-Oct-2001 7:33
Gregg Irwin wrote:
> REBOL's real power will shine when we think in terms of communication apps
that let specialists use the nomenclature of their respective fields and we
exchange messages that are readable both by humans and by REBOL.
Like my eText software? That lets one write plain text, yet have nicely
formatted HTML documents, which are automatically linked together.
Andrew Martin
ICQ: 26227169 http://valley.150m.com/
[33/36] from: greggirwin:mindspring at: 26-Oct-2001 14:36
Hi Andrew,
<< Like my eText software? That lets one write plain text, yet have nicely
formatted HTML documents, which are automatically linked together. >>
Right! But we have so much further to go. We have some really *great* stuff
that Carl, You, Robert, Gabriele, and others have written which will
undoubtedly be the springboards for many derivative efforts.
As an example, EasyVID defines the content and then defines the rules about
how to process that content. You could easily create a new set of rules to
emit different formats. Maybe one format writes out footnotes, where another
would create a pop-up definition, and yet another creates a hyperlink. A
section
could be an HTML page, a slide in a slide-show, a paragraph, or a
layout. Pretty obvious stuff, this.
The challenge lies in defining the lingua franca, one or more, which are
transparent and flexible, that allow us to produce and transform content
effectively.
--Gregg
[34/36] from: robert:muench:robertmuench at: 27-Oct-2001 13:00
> -----Original Message-----
> From: [rebol-bounce--rebol--com] [mailto:[rebol-bounce--rebol--com]]On Behalf Of
<<quoted lines omitted: 5>>
> communication between humans, not programs and machines. This is where REBOL
> should *really* shine.
Hi, first thing to mark from my side: I would love to use Rebol instead of
PowerPoint! But my client doesn't pay me for that, or more correctly my client
expects me to use PowerPoint. This thing isn't discussable...
> Cybarite has done a nice VID sample called EV-Pres
> which uses EasyVID as its basis. Jeff has also done a little
<<quoted lines omitted: 3>>
> people only want/need/use probably 1% of the functionality in the current MS
> Office apps. But I digress...
Yes, but no one else can create it. We can, we know how to program, we know
about languages and about nice technology methods. But 99,5% of the people our
there don't! And that's our problem. With presentations we target the wrong
market. These people are happy to be able to use 1% of PowerPoint.
I'm currently using my make-doc-pro for documenting my project. You won't
believe how much effort I have to bring in to get people used to the HTML files.
They expect word, powerpoint files.
Only one team member is using make-doc-pro too. But I needed about 3 weeks to
convinve him to try it out... That's just the reallity and I'm not going to
change this in a one-person-show.
So I suggest, instead using your power, time and motivation to convert those
people, let's create something that can transform into their world. The benefit
we have? Well, I'm going to be 50% more productive than my competitors and get a
50% better result! That's value and customers are going to pay you for this.
They could pick-up the powerpoint stuff and continue to work on it... but it
didn't took my 3 hours to create, only 20 minutes but I would tell, I made in 1
hour ;-))
> PowerPoint is a great example of what works in the context of a controlled
> environment not working outside of a controlled environment. It's a closed
> format and not easily distributed. People send me PPS files and I can't view
> them and I'm running W2K! My wife can't run them on her iMac, and they take
> *forever* to download. If I can't see the data, the communcation link has
> failed utterly.
I totaly agree. But that's the situation, I can't change, maybe you can in your
context.
> Sorry to ramble on here but I'm just about jumping out of my chair thinking
> about the possibilities.
You don't have to be sorry for it, I'm doing the same, but I try to get back
from our better Rebol world to reality and think about building a bridge between
those two places...
> Maybe because I had such a hard time getting
> PowerPoint to work for me when I did presentations and they said I *had* to
> use it.
I know for sure!
> What we need is a "presentation IDE" for REBOL. :)
... which bridges the gap to PowerPoint. Robert
[35/36] from: robert:muench:robertmuench at: 27-Oct-2001 13:00
> -----Original Message-----
> From: [rebol-bounce--rebol--com] [mailto:[rebol-bounce--rebol--com]]On Behalf Of
<<quoted lines omitted: 5>>
> transparent and flexible, that allow us to produce and transform content
> effectively.
Yep! And the solutions IMO is the use of dialects :-)). With make-doc Carl
started a very simple to use lingua france, I added some stuff to it trying to
follow his path and keep it simple.
Next thing I'm going to add is a dialect for doing projectmanagement (better
status) things, which can be used inside make-doc-pro.
My vision is to have a framework of small dialects, following some basic rules
to be mostly uage-compatible, which all can be used from make-doc-pro. After
this other output formats are going to be supported. Robert
[36/36] from: greggirwin:mindspring at: 27-Oct-2001 11:09
Hi Robert,
We're thinking along the same lines. My view is that the tools you and
others have built are not the end-user apps non-REBOLers are looking
for...yet. I have no doubt, though, that they could form the basis for those
tools.
Changing the world to REBOL view, and the different paradigms we create to
take advantage of it will be like the old joke Q. "How do you eat an
Elephant?" A. "One bite at a time."
--Gregg
Notes
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted