Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

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:y:ahoo 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