[REBOL] Re: starting to be really late!?
Karl Robillard wrote: >Hey Ed, that's an excellent summary of how Rebol differs from other mainstream >languages. > >Everything else in this post I have said before, but I like to restate my >thoughts whenever this topic pops up, as Robert notes that it does, every few >months or so. > >I believe the artificial limits placed on Rebol by RT is the problem and agree >that the strategy is wrong. I don't want another platform and Rebol is >doomed to failure if it insists on trying to compete with all the existing >ones. I want Rebol as a tool to bind my existing platforms and applications >together. > > And I have to ask why do you want to limit rebol in becoming kind of Arexx universal glue, when it can actually provide much more usability? I can see the main rebol concept as very good - the one of rebol block and mixture of code = data (even binary ones) principle. My opinion is, that there is not so much effort needed to push rebol in certain areas. How do you want to judge what aproach is right? You want kind of arexx, someone else might be interested in Authoring tool (right cyphre? :-). But then I often hear that that why to compete with Flash etc. kind of argument and my opinion is - that is not true. E.g. I have no intention (limited by lack of free time) to learn FlashMX to become fluent in such environment and besides that I think that some nice changes to View would eliminate such need. The problem of past of RT was imo their investors. I do remember when RT switched to IOS (Express back at that time) kind of strategy. I really disliked it. They had no corporate experience imo and what is more, even IOS development stopped while there is so much what can be done to make it better. While the glory days of RT employing several good coders is over, I think there can be way how to handle current situation: - community cooperating with RT - View 1.3 project is good start. I think that all ppl there are properly focused, no extra noise on particular channels etc. The difference between 1.3 effort and last year effort is clear - Carl's almost daily involvement, while in the past Carl appeared just once per 2 or 3 months to check. Other difference is often beta releases for betatesting - the way to go imo - RT concentrates on addition of general engines. E.g. - why to wait for RT to add particular functionality, feature, if we could add it ourselves? And yes, I mean addition of virtual machine, or at least specific area dialect engines for fast manipulation (e.g. working with image data). That way we could add additional effects ourselves, or in the case of RVM, code some additional ports/drivers to other environment ourselves, while stying fast - the advantage agains linking to libraries is obvious - rebol app would stay self-contained, RT would be freed from I-want-this-he-wants-that kind of feature requests. In fact, talking to Carl few days ago, he mentioned he thinks of addition of such principles into rebol more and more. That is imo a good sign. - also - Carl said that he could add more functionality into rebol, if we would help to find C source codes, .e.g. that he would be able to add RGB24 convolver in less than day probably. GIF saver and wav loader were also mentioned in that respect. So, it is also upon us. Similar thing I remember about .zip, .arj., .rar code, where the idea was to treat them like ordinary directories or to create schemes for them, something like zip:// ...The offer was made, but we (the community) failed to deliver ... so ... There are of course other things ... newer GC, async networking sitting in separate dev. tree, not yet merged, things like more granular event system, language extensions, direct draw modes etc. But - we should keep in mind we are short on resources. But I do believe, that if we work with so much dedication as can be seen in the case of View 1.3, the things will get better and better. Of course it would be cool to be able to clone ppl like Romano, Volker, Gregg and many others, who do wonderfull work for 1.3, but the situation is as is :-) -pekr- >-Karl > > > -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: starting to be really late!?
I think Carl did mention Visual Studio actually (in View 1.3 world). He said compiler settings are very strict for compatibility. Anton > Hi bry, > > bic> question on rebol and .net, IIRC Rebol is > bic> written in ANSI C right? So I'm wondering > bic> what compiler is used to build Rebol, if > bic> it's lcc then maybe Rebol Technologies could > bic> use lcc.net the lcc msil backend? from > bic> Microsoft Research. > > Because of cross-platform needs, I think gcc is probably used for many > platforms; probably Visual Studio on Windows, but I can't say for sure. > > -- Gregg -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: starting to be really late!?
Hi bry, bic> question on rebol and .net, IIRC Rebol is bic> written in ANSI C right? So I'm wondering bic> what compiler is used to build Rebol, if bic> it's lcc then maybe Rebol Technologies could bic> use lcc.net the lcc msil backend? from bic> Microsoft Research. Because of cross-platform needs, I think gcc is probably used for many platforms; probably Visual Studio on Windows, but I can't say for sure. -- Gregg -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: starting to be really late!?
question on rebol and .net, IIRC Rebol is written in ANSI C right? So I'm wondering what compiler is used to build Rebol, if it's lcc then maybe Rebol Technologies could use lcc.net the lcc msil backend? from Microsoft Research. > > Karl wrote: > > So I am consigned to use Rebol for various utilities where I can - things > like A J Martin's C# code generator. > > If you want a copy, just email me. It's not in the library, because I'm > expanding it frequently. > > -- > Andrew J Martin > Speaking in tongues and performing miracles. > ICQ: 26227169 > http://www.rebol.it/Valley/ > http://valley.orcon.net.nz/ > http://Valley.150m.com/ > -><- > > -- > To unsubscribe from this list, just send an email to > [EMAIL PROTECTED] with unsubscribe as the subject. > > -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: starting to be really late!?
Well Karl, I don't know how long you been part of the REBOL community but I can tell you that many in the rebolution have been upset at one point or another. However, as I have learned and many others is that just when we think the boat has sunk it seems that Carl Sassenrath pull together some amazing turn of events to bring us all back to our cause. (I sware his ears burn when we talk about him or REBOL for that matter). However, I'm very please with how things have progressed. I can't think of any other author of such a wonderful langauge that truely accepts and does indeed try to harness the power and intellect of his followers as much as Carl does. Its like Kennedy said at one time. Don't ask what your country can do for you - ask what you can do for your country. I think many have stepped up to the plate lately and have done just that when it comes to REBOL country. So lets be patient, I think many are going to be quite amazed at what is going to be released soon and you can thank many very intelligence, patient, and faithful REBOL developers - those on this list that have very often felt the same way as you do. Paul Tretter - Original Message - From: "Karl Robillard" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, January 10, 2004 3:20 PM Subject: [REBOL] Re: starting to be really late!? > > Hey Ed, that's an excellent summary of how Rebol differs from other mainstream > languages. > > Everything else in this post I have said before, but I like to restate my > thoughts whenever this topic pops up, as Robert notes that it does, every few > months or so. > > I believe the artificial limits placed on Rebol by RT is the problem and agree > that the strategy is wrong. I don't want another platform and Rebol is > doomed to failure if it insists on trying to compete with all the existing > ones. I want Rebol as a tool to bind my existing platforms and applications > together. > > My killer-app for Rebol is to be a next generaton ARexx. This is what I > expected Rebol to be from day one and is what I think of when I hear the > words 'messaging language'. I want a Rebol interpreter library which can be > embedded in applications and allow the application to implement datatypes & > natives. I don't see how this is possible (and be widely adopted) without > Rebol being open source to some degree. As I have pointed out before, > Trolltech has a successful business model where their main product is open > source. > > In a sense, RT does not eat its own dog chow. The interface users are given > to extend Rebol is the commercial External Library Access. By the way, the > platform vs. tool stance RT takes is apparent when they say this interface is > available to interface with 'legacy' systems. I'm sorry, but things like the > C language and OpenGL are not 'legacy'. RT, however, does not extend Rebol > this way. They create separate products with an embedded core (View, IOS, > etc) and extend the language with datatypes and natives. > > I have given up hope of ever being able to use Rebol this way and was very > disappointed to hear Carl talk about being satisfied with Rebol as an > application like HyperCard. Bleh. So I am consigned to use Rebol for > various utilities where I can - things like A J Martin's C# code generator. > > I hope I'm not repeating myself too often here on the list. > > > -Karl > > -- > To unsubscribe from this list, just send an email to > [EMAIL PROTECTED] with unsubscribe as the subject. > --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.560 / Virus Database: 352 - Release Date: 1/8/2004 -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: starting to be really late!?
> Hey Ed, that's an excellent summary of how Rebol differs from other mainstream > languages. Thanks. Hopefully it doesn't rub everyone the wrong way. > I believe the artificial limits placed on Rebol by RT is the problem and agree > that the strategy is wrong. I don't want another platform and Rebol is > doomed to failure if it insists on trying to compete with all the existing > ones. I want Rebol as a tool to bind my existing platforms and applications > together. My hope is that Carl has adhered striclty to his design principles in order to let REBOL complete its formative stages of development. During that period, it would be understandable to put a cork on the bottle, so-to-speak. Once this stage is complete, the vintner would explore ways of making REBOL as socially attractive and applicable as possible. Or so the dream goes... :) > I have given up hope of ever being able to use Rebol this way and was very > disappointed to hear Carl talk about being satisfied with Rebol as an > application like HyperCard. Bleh. So I am consigned to use Rebol for > various utilities where I can - things like A J Martin's C# code generator. I don't recall hearing Carl mention HyperCard. Was that over the mailing list? (I'm familiar with hypercard/supercard and metacard, so I'm interested in the topic.). Personally I don't feel bitter or frustrated by REBOL's status in the world, nor do I feel it is warranted. REBOL is Carl's personal language (the culmination of his experience, his technical/cultural priorities, his design principles and programming needs) and it has been a joy to use it over the years. I wish I could use REBOL more and promote it for commercial projects, but my set of needs are significantly more mainstream than those of its maker. Regards, Ed -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: starting to be really late!?
Karl wrote: > So I am consigned to use Rebol for various utilities where I can - things like A J Martin's C# code generator. If you want a copy, just email me. It's not in the library, because I'm expanding it frequently. -- Andrew J Martin Speaking in tongues and performing miracles. ICQ: 26227169 http://www.rebol.it/Valley/ http://valley.orcon.net.nz/ http://Valley.150m.com/ -><- -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: starting to be really late!?
Hey Ed, that's an excellent summary of how Rebol differs from other mainstream languages. Everything else in this post I have said before, but I like to restate my thoughts whenever this topic pops up, as Robert notes that it does, every few months or so. I believe the artificial limits placed on Rebol by RT is the problem and agree that the strategy is wrong. I don't want another platform and Rebol is doomed to failure if it insists on trying to compete with all the existing ones. I want Rebol as a tool to bind my existing platforms and applications together. My killer-app for Rebol is to be a next generaton ARexx. This is what I expected Rebol to be from day one and is what I think of when I hear the words 'messaging language'. I want a Rebol interpreter library which can be embedded in applications and allow the application to implement datatypes & natives. I don't see how this is possible (and be widely adopted) without Rebol being open source to some degree. As I have pointed out before, Trolltech has a successful business model where their main product is open source. In a sense, RT does not eat its own dog chow. The interface users are given to extend Rebol is the commercial External Library Access. By the way, the platform vs. tool stance RT takes is apparent when they say this interface is available to interface with 'legacy' systems. I'm sorry, but things like the C language and OpenGL are not 'legacy'. RT, however, does not extend Rebol this way. They create separate products with an embedded core (View, IOS, etc) and extend the language with datatypes and natives. I have given up hope of ever being able to use Rebol this way and was very disappointed to hear Carl talk about being satisfied with Rebol as an application like HyperCard. Bleh. So I am consigned to use Rebol for various utilities where I can - things like A J Martin's C# code generator. I hope I'm not repeating myself too often here on the list. -Karl -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: starting to be really late!?
> Hi (Ed I'm answering to your post but it's not only meant WRT what you > have written), Got it-- no problem. I'll reply to some of your points anyway. :) > this "too late" etc. discussion continually shows up every couple of > months. Is Rebol the problem? I don't think so REBOL itself may be a problem if its design decisions inhibit sufficiently broad acceptance of the language. Left idle REBOL provides little benefit-- developers and users are the true run-time engine. If a critical mass of developers is not reached, there will be fewer projects using it and fewer programs written in it, etc. Sounds like a chicken-and-egg problem. > To me the View 1.3 project is a first small step into the right direction. Yes! I hope it works well for all involved. > How much are you going to pay for this? Nothing? Will this work... I am always willing to pay RT something when there's good value, and it's within my budget. I've been a good customer, but I understand that not everyone is fortunate enough to afford taking a chance on development tools. > No, it's not the technology, it's what we do with it. ... Rebol > seems to have many unique features but we failed to use these > to create something that the markets want to have. I agree. This reminds me of a post on Gadgetopia that has stayed with me a while: "Problems No Platforms Will Fix" http://www.gadgetopia.com/2003/05/27/ProblemsNoPlatformWillFix.html >> I believe that there are marketable & revolutionary products >> in REBOL, or a REBOL-like language. > Which ones? My personal feeling is that REBOL should be used for things it's designed to do well. Gotta work with what you've got. Dialecting combined with simple networking make a powerful combination, and I think that represents fertile ground for interesting programs. In most other areas of development, other languages are on equal or better footing. >> * information retrieval & consumption >> * database interaction >> * content creation >> * games/media players >> >> and that history implies that the web has the first 2 solidly covered. > There is one big missing, not solved yet: Integration of 1 and 2 to get > value from it, so that 3 and 4 can be produced. Could you elaborate a bit? Best regards, Ed -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: starting to be really late!?
On Thu, 8 Jan 2004 01:23:31 -0500, Ed O'Connor <[EMAIL PROTECTED]> wrote: > To compete with Flash -- or any well-established commercial product or > open-source language-- let's face it, it probably is too late. RT has > limited resources and bandwidth to stake a claim against Macromedia, > Adobe and numerous other public or privately funded companies. Hi (Ed I'm answering to your post but it's not only meant WRT what you have written), this "too late" etc. discussion continually shows up every couple of months. And, what do we do? Is Rebol the problem? I don't think so: The applications, solutions are. What sense does a technology make if there is no killer-app for it? IMO RT has the wrong strategy (if any at all). With the size of RT one must use a complete different strategy. A good running niche market can be very comfortable to live in. To me the View 1.3 project is a first small step into the right direction. RT uses the community! Finally! We all want RT to succeed, because we want to keep our Rebol. How much are you going to pay for this? Nothing? Will this work... > It's true that the "X-Internet" label was a marketing buzzword, but REBOL > never appeared (to my eyes anyway) to be mainstream market-driven or > customer-focused. Good languages and technologies aren't often the > product of markets or concensus, so it probably makes sense. Right, it's the need others have. I want to see a discussion about things like: 1. How can RT make money? 2. What kind of killer applications do we need? 3. What's the market for Rebol? If we are going to answer these, it's just a matter to get it done. But this is much more simpler than answering the questions. > If popularity or money were truly central to the mission, consider the > following choices: > > ... > > Looking at the above list (and I appreciate many of the items as much as > I dislike other ones), REBOL doesn't look like a commercial, > market-focused > language. No, it's not the technology, it's what we do with it. So what's the USP we can create using all the points you mentioned for our advantage? Rebol seems to have many unique features but we failed to use these to create something that the markets want to have. I don't know about the success of AltME, FTP Gadget etc. I think it's working. But it's working because these people get some support from RT, without RT supporting their partners, neither will be successful. IMO this is something we can accuse RT of. > So rather than targetting a market opportunity, Carl created a > language-- a > platform, really-- that embodies his principles in a personal programming > language (wasn't that what his original manifesto said?). I've been using > REBOL off-and-on for over 6 years, and that's longer than I can say for > most commercial products I've worked with. I believe that there are > marketable & revolutionary products in REBOL, or a REBOL-like language. Which ones? > Given the limited resources of RT, the small user-base of REBOL, and the > _heavily_ commoditized state of programming languages, I'd love to see an > updated vision or roadmap for REBOL (forget delivery dates, naturally). And I would love to see RT focusing on partnerships, or if this isn't RT's focus, to give this ability to some here. I'm trying to do so, but it's horrible slow and takes a lot of time to work with RT. Without a sign, results in this process, I'm keeping my fire low. Maybe one day I have an opportunity to push RT ahead, and than I hope they will listen... > * information retrieval & consumption > * database interaction > * content creation > * games/media players > > and that history implies that the web has the first 2 solidly covered. There is one big missing, not solved yet: Integration of 1 and 2 to get value from it, so that 3 and 4 can be produced. -- Robert M. Münch Management & IT Freelancer Mobile: +49 (177) 245 2802 http://www.robertmuench.de -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: starting to be really late!?
Hi Ed Good post - thanks.. > Before I close this overly long message, I'll posit a parting thought. Tim > Bray and other bloggers have asserted that there are 4 main kinds of apps: > > * information retrieval & consumption > * database interaction > * content creation > * games/media players hmm... Well what's missing from on that list is 'thinking tools' Rebol does good things to ones head, and especially in the context of what else is out there. I consider Rebol is a catalytic idea - a thinking experiment for programmers not a product in the contemporary neoconpostdotcom sense. Or if is a product then its true value is memetic. Part of its meme is programming for fun - and programming to design and be different and anticipate where the 'new' paradigm will be in 15 years.. But Rebol needs a home also, and I've always felt that it should be as a first language or in some happy creative academic environment. Where people are encouraged to invent the future and play with ideas deeply. It would only take a couple of CS departments to adopt it. That's part of its Logo heritage too. I think in France there is a the best chance of that happening right now. Elsewhere, I am sure the Chinese, Japanese, and Koreans would love Rebol, if they knew about it , and if it would support Unicode. - Jason -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: starting to be really late!?
To compete with Flash -- or any well-established commercial product or open-source language-- let's face it, it probably is too late. RT has limited resources and bandwidth to stake a claim against Macromedia, Adobe and numerous other public or privately funded companies. It's true that the "X-Internet" label was a marketing buzzword, but REBOL never appeared (to my eyes anyway) to be mainstream market-driven or customer-focused. Good languages and technologies aren't often the product of markets or concensus, so it probably makes sense. If popularity or money were truly central to the mission, consider the following choices: * platform-independence, instead of support for Win32/COM/CORBA (or Unix system calls) * support for common open network protocols/formats, no proprietary ones * free-form syntax, instead of C style syntax * language name choice is slightly awkward (COBOL, SNOBOL) instead of a hipster name * lightweight cloning instead of rigid OOP * ideas from Forth and Logo, instead of more popular C, VB or Perl * designed for "programming in the small", not for general programming or big-iron middleware * code interpreted instead of compiled * execution speed is respectable, but not a hallmark feature (such as with K, euphoria, erlang) * single execution thread * no modules/libraries, foreign functions, continuations, spawning of sub-processes (& other exotic MIT hacker profile) * interactive console and your favorite editor, instead of a 20 MB IDE * tiny disk footprint, instead of 5, 10, 20 MB or more * minimal install, instead of a 20 step Wizard-driven system infestation * think about your code instead of relying on rich, integrated debuggers * minimal GUI layer, not mature (missing html controls & formatting, no data-grid control, etc.) * no wysiwyg or GUI/forms design tools * /command db access not robust (i.e., count occurrences of #? in the SQL statement and bind a value to it) * BNF style grammars instead of a Regex engine * limited XML support, not mature * Latin characters instead of UTF-8 or Unicode * closed source instead of open source * REBOL is not available/mature on the number 2 desktop platform, Apple (2-3% of the market) * dialects instead of well, I've yet to see common problems that language dialects solve (but I hope to) Looking at the above list (and I appreciate many of the items as much as I dislike other ones), REBOL doesn't look like a commercial, market-focused language. Normally I would expect the data to form a profile of one or more marketable customer segments, i.e., scripter, hobbyist, corp. programmer, sysadmin, hacker, etc. The profile I arrive at from the list above is one of... well, a rebel. So rather than targetting a market opportunity, Carl created a language-- a platform, really-- that embodies his principles in a personal programming language (wasn't that what his original manifesto said?). I've been using REBOL off-and-on for over 6 years, and that's longer than I can say for most commercial products I've worked with. I believe that there are marketable & revolutionary products in REBOL, or a REBOL-like language. Given the limited resources of RT, the small user-base of REBOL, and the _heavily_ commoditized state of programming languages, I'd love to see an updated vision or roadmap for REBOL (forget delivery dates, naturally). Before I close this overly long message, I'll posit a parting thought. Tim Bray and other bloggers have asserted that there are 4 main kinds of apps: * information retrieval & consumption * database interaction * content creation * games/media players and that history implies that the web has the first 2 solidly covered. Will REBOL compete with the web, or will it mature enough to allow you and me to create robust apps in the latter 2 categories? Hey, despite the frustration, confusion and the passage of long periods of time, this is still mostly fun, right? Good luck with /View 1.3 all. Ed -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: starting to be really late!?
Ashley wrote: > If REBOL doesn't do something you need *today* you have four basic choices: > > 1) Change your requirements > 2) Wait > 3) Use something else > 4) Change your approach 5) Use Rebol to generate source code in another language. For example I'm using Rebol to generate C# code, allowing me indirectly to program in Rebol and achieve a Windows compatible user interface. :) Andrew J Martin Speaking in tongues and performing miracles. ICQ: 26227169 http://www.rebol.it/Valley/ http://valley.orcon.net.nz/ http://Valley.150m.com/ -><- -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: starting to be really late!?
Hi Max, While I can certainly add many things to your list of what can't be done or changed in REBOL I think it all boils down to, "Can REBOL do most of what I need it to do today?", if the answer to that question is *no* then perhaps it is the wrong tool for the job you have in mind. If REBOL doesn't do something you need *today* you have four basic choices: 1) Change your requirements 2) Wait 3) Use something else 4) Change your approach I'm not actually advocating any of these, just attempting to address the last of them as 1-3 have been discussed at length. ;) Regards, Ashley -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: starting to be really late!?
I also agree with your whole post, Max. Anton. > > > First there was the rebol - x-internet app, nearly alone then > > > others stepped in into the game - Flash MX ... now they are > > moving ahead > > > to mobile devices : > > > > > -If RT makes shell command access free (officialy, not just the > browser hack) > -If RT gives us the binary native!-capable module linker > > Then much discussion about rebol's missing capabilities is moot > as then rebol can become a GPL just like python (actually much > better) with all of rebols superior's methodology. > > want rebol to be the glue in your IT infrastructure, then shell > acess does that. > > You want OpenGL speeds (if only in 2d) ... then a binary module > would let us. No need to wish for RT to do it. yeah you can use > a dll but that's not optimal and expects you to convert external > datastructures in rebolesque equivalents which really aren't > equivalent... and data conversion of large blocks of data is > REALLY slow... just ask cyphre how fast importing/exporting images is... > > These two features alone make REBOL several times more usefull as > a technology and industry-wide acceptable. > > IMHO they would let REBOL, as a platform, soar on its own with > less pressure on RT to do everything. > > Direction of rebol comes by every few weeks and we've all stated > our opinions, but I think that rebol's core weekness as a coding > platform is its closed-in nature. The moment you want to do > something that demands high-speed, guaranteed rates or actual > complete and unbridled integration to external processes, then > rebol USUALLY comes short. > > yess that is not rebol's primary vision (is it meant as a > messaging language), but when every else does the above and you > can't then it becomes a cause for concern for any > pipeline/infrastructure IT manager. > > I also wonder why RT never packaged rebol AS a .dll or .so you > can use IT INSIDE binary apps... so that you use rebol's > integrated messaging capabilities within an application. > > this could yet broaden rebol's approach as a macro/scripting > language (like a much better VB or arexx script engine). > > > my 2 cents > > LET the flames roar ;-) > > > -MAx -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: starting to be really late!?
Ashley I agree with most of what you say, but because we do not have acces to rebol from the outside, we cannot compliment it, if we need it. In the example you give, in my workflow I still have to render the 6k image, cause it will go to film print (and then projected on screen at a movie near you). working in thumbnail isn't an option at my level. but I can't solve the problem, in this case, unless I can use rebol's data directly. For example, text/font drawing in rebol is a farce (I can't change that). Face does not handle anti-aliasing for any of its graphics (I can't change that). things like that REALLY are important when you want to create vertical APPLICATIONS. That's the problematic word -APPLICATION-. rebol is THE BEST for quick and dirty but has many shortcommings for full-blown apps (for which it was not destined, initially). I remember a post from Carl S. where he admits (in a quick comment, long ago) that there are more people using rebol as a GPL (General Purpose Language) than he tought would have and that he should change some things in the roadmap to adapt for this reality... but left no details... If we COULD implement such things ourselves (by having binary access to rebol's data via plugin modules OUTSIDE of rebol), then those issues CAN be fixed by anyone who really needs the solution. Adding external hooks, for example, giving us a face object's raw binary bitmap memory space, when rebol is finished drawing. This would let us add gfx to that face's bitmap in REAL TIME with external plugins (many of which ARE multiplatform) and then returning when the bitmap is ready, would allow me to use rebol as a production-quality compositing software, no slow interpreted data transformations need to be done as the image supplied as raw pixel info would be used direcly by the external binary code and then quickly refreshed in the window. same thing for converting raw window events into better keyboard support, IF I need it. Currently I can only do some pre-canned effects, put laim-quality typography and add very limited transformations. If you want a list, just ask Cyphre he's stopped ranting, having done it for s long, without much effect (maybe view 1.3 altme world is making his requests move along more?). I want to incorporate image-magik into rebol ASAP (during the course of this year for sure), but I can't use it for the actual in-rebol view window in real-time. I can only see it being a real-time thing, if image-magik's processing is done in separate memory space (in a window a canned .dll would open by itself) using a simple dialected string version of a processing tree, which it executes line-by-line with absolutely no inteligence. It could also be done as a stand-alone process ,using a tcp-port for receiving commands, but then we haven't solved anything really... anyhow, back to work... -MAx --- "You can either be part of the problem or part of the solution, but in the end, being part of the problem is much more fun." > -Original Message- > From: Ashley Trüter [mailto:[EMAIL PROTECTED] > Sent: Wednesday, January 07, 2004 7:09 PM > To: [EMAIL PROTECTED] > Subject: [REBOL] Re: starting to be really late!? > > > > > For multi-media, modern typopraphics, I think it is very poor. > > But for any sysadmin, config screens, basic lists, tables ... > > I'd add 2D user interfaces to your list of what REBOL is good > at, which is > the biggie for anyone developing more traditional applications. For > realtime 3D / intensive multi-media stuff, use something else. > > I'd be carefull about statements that REBOL can't do x well, > I have often > found that (like PERL) there is more than one way to do > things and often a > change in approach / algorithm is required. As an example of > this, one of > the applicaions I sell provides the facility to graphically > annotate an > image (typically 6 mega-pixel) and move / resize these annotations. > > The initial implementation did the following: > > - apply any effect to the image (eg. grayscale) > - draw (eg. a red circle) > - square crop the viewable area of the image > - fit the image to a screen-height x screen-height display area > > This approach certainly worked (apart from ending up with pixelated > drawings!), but the FPS (Frames Per Second) was down to about > 0.5! At this > point I bemoaned the fact that REBOL/View was too slow and > didn't let me > directly update pixels, I even looked at external libraries > to handle the > drawing component but I wanted to keep the applcation 100% > REBOL. I then > looked at changing my algorithm: > > - square crop the viewable area of the imag
[REBOL] Re: starting to be really late!?
> For multi-media, modern typopraphics, I think it is very poor. > But for any sysadmin, config screens, basic lists, tables ... I'd add 2D user interfaces to your list of what REBOL is good at, which is the biggie for anyone developing more traditional applications. For realtime 3D / intensive multi-media stuff, use something else. I'd be carefull about statements that REBOL can't do x well, I have often found that (like PERL) there is more than one way to do things and often a change in approach / algorithm is required. As an example of this, one of the applicaions I sell provides the facility to graphically annotate an image (typically 6 mega-pixel) and move / resize these annotations. The initial implementation did the following: - apply any effect to the image (eg. grayscale) - draw (eg. a red circle) - square crop the viewable area of the image - fit the image to a screen-height x screen-height display area This approach certainly worked (apart from ending up with pixelated drawings!), but the FPS (Frames Per Second) was down to about 0.5! At this point I bemoaned the fact that REBOL/View was too slow and didn't let me directly update pixels, I even looked at external libraries to handle the drawing component but I wanted to keep the applcation 100% REBOL. I then looked at changing my algorithm: - square crop the viewable area of the image - fit the image IF crop size > display area size - apply any effect to the image (eg. grayscale) - fit the image IF the display area size is >= crop size - draw (eg. a red circle) This small change increased the average FPS to about 1.5 and resulted in clean [non-pixelated] drawings. Good, but could be better. My next change was the biggie: instead of working with the image itself, work on the rendered screen representation, that way, instead of having to worry about a 6 mega-pixel image all I had to worry about was the 768x768 screen view of it. This bought the FPS up to 40 FPS with no user-level changes. I am now looking at similiar issues with large REBOL data structures on small memory foot-print devices. Yes, loading a 76MB 1,000,000 row table into a hash! solves my access problems but consumes 750Mb of memory. Now, if I can work out a way of working with the same file in 'open/binary mode and only use 76MB of memory ... The point of all this is to illustrate my belief that REBOL can do most things you want it to do, but you have to think about *how* you can do it and what the tradeoffs of your aproach are. Regards, Ashley -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: starting to be really late!?
Humble minds thinkg alike :-) -MAx > -Original Message- > From: Jason Cunliffe [mailto:[EMAIL PROTECTED] > Sent: Wednesday, January 07, 2004 4:36 PM > To: [EMAIL PROTECTED] > Subject: [REBOL] Re: starting to be really late!? > > > > > -If RT makes shell command access free (officialy, not just > the browser > hack) > > -If RT gives us the binary native!-capable module linker > > Yes > > > Then much discussion about rebol's missing capabilities is > moot as then > rebol can become a GPL just like python (actually much > better) with all of > rebols superior's methodology. > > > > want rebol to be the glue in your IT infrastructure, then > shell acess does > that. > > Yes > > > These two features alone make REBOL several times more usefull as a > technology and industry-wide acceptable. > > Yes > > > IMHO they would let REBOL, as a platform, soar on its own with less > pressure on RT to do everything. > > Yes > > > Direction of rebol comes by every few weeks and we've all stated our > opinions, but I think that rebol's core weekness as a coding > platform is its > closed-in nature. The moment you want to do something that demands > high-speed, guaranteed rates or actual complete and unbridled > integration to > external processes, then rebol USUALLY comes short. > > Yes > > > yess that is not rebol's primary vision (is it meant as a messaging > language), but when every else does the above and you can't > then it becomes > a cause for concern for any pipeline/infrastructure IT manager. > > Yes > > > I also wonder why RT never packaged rebol AS a .dll or .so > you can use IT > INSIDE binary apps... so that you use rebol's integrated messaging > capabilities within an application. > > Yes > > > this could yet broaden rebol's approach as a > macro/scripting language > (like a much better VB or arexx script engine). > > Yes > > - Jason > > -- > To unsubscribe from this list, just send an email to > [EMAIL PROTECTED] with unsubscribe as the subject. > > -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: starting to be really late!?
> /View exists and needs work. But 1.3 is not radical change as I understand. > It may be his second name and I've owned several Amigas, but the honest > reality is Rebol is almost completely crippled for multimedia at this time. > Rebol multimedia a is about the level of 1995 even 1988 in too many > respects I just wanted be clear about my /View flames today... For multi-media, modern typopraphics, I think it is very poor. But for any sysadmin, config screens, basic lists, tables, logins, installs, common data controls --- simple clear people-friendly button clicking and minimal test/data display jobs Rebol/View is very valuable indeed. And Easy-VID is a fine creation :-) - Jason -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: starting to be really late!?
> -If RT makes shell command access free (officialy, not just the browser hack) > -If RT gives us the binary native!-capable module linker Yes > Then much discussion about rebol's missing capabilities is moot as then rebol can become a GPL just like python (actually much better) with all of rebols superior's methodology. > > want rebol to be the glue in your IT infrastructure, then shell acess does that. Yes > These two features alone make REBOL several times more usefull as a technology and industry-wide acceptable. Yes > IMHO they would let REBOL, as a platform, soar on its own with less pressure on RT to do everything. Yes > Direction of rebol comes by every few weeks and we've all stated our opinions, but I think that rebol's core weekness as a coding platform is its closed-in nature. The moment you want to do something that demands high-speed, guaranteed rates or actual complete and unbridled integration to external processes, then rebol USUALLY comes short. Yes > yess that is not rebol's primary vision (is it meant as a messaging language), but when every else does the above and you can't then it becomes a cause for concern for any pipeline/infrastructure IT manager. Yes > I also wonder why RT never packaged rebol AS a .dll or .so you can use IT INSIDE binary apps... so that you use rebol's integrated messaging capabilities within an application. Yes > this could yet broaden rebol's approach as a macro/scripting language (like a much better VB or arexx script engine). Yes - Jason -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: starting to be really late!?
> First - let me add that I almost completely disagree here. So, here we go > why: I thinks an argument worth having so thanks for your comments. > It has to be defined what does invisible mean? I mean all non-gui tasks. smart programmable embedded messaging transport, data/event access and handling, connectivity between applications, information engineering.. > disaster? And that is why View 1.3 is under development? That is why > direct draw modes were/are planned? That is why Carl told us that > multimedia is his second name? :-) /View exists and needs work. But 1.3 is not radical change as I understand. It may be his second name and I've owned several Amigas, but the honest reality is Rebol is almost completely crippled for multimedia at this time. Rebol multimedia a is about the level of 1995 even 1988 in too many respects How many formats can it even talk to ? Look you can't even do basic binary clipboard copy and paste or drag'n'drop of an image or sound into a /View application That's insane in 2004 and says up front this is a very limited cool demo proof of concept gui which does not play with the rest of the multimedia universe. Will that be in /View 1.3 ?" If so I apologize on that count. Multimedia is many things, but surely includes interoperability with real-world formats that other people and tools use. > what? Why? :-) What is the single advantage of making flash in rebol? > That you would be able to run your "rebol" app inside the browser? Rebol on the browser would be nice. But the whole point is that Flash is moving to the desktop and the server. There is a huge opportunity for embedded dynamic server-side and peer-peer dynamic flash generation. For example even desktop flash apps still can't save .swf file at runtime. Macromedia change their flash server-side tech about every 18 months. Latest is Flex. They've all been expensive > Or where can I find flash and not rebol? Unless there is one-button-press > conversion of rebol VID app into flash, it still means to program > separately for View and for Flash ... hmm... VID-Flash was not what I had in mind. Rebol is not good for building whole applications Flash, but it could dynamically transform data/event/mesage streams into swf to be loaded by parent Flash applcations in many useful ways. > >pro adds 400 fscommands including socket, http, ftp, mail, file i/o.. What > >more does one want or need? Even a Rebol-based swf2exe for Windows, Mac and > >Linux [in that order] could be a very successful and useful product. And a > >viable way to introduce Rebol to much larger and visible audience . > > > That can be done without any need for Flash. What does Rebol offer? - brilliant elegant different fun innovative programming language --- I love it - a very tiny but smart and friendly community --- kudos and thanks but not enough to sustain development on many fronts or persuade CTO etc - some built-in Internet protocols --- that's everywhere now - weak gui with weak documentation and not even a layout IDE - no Unicode :-( --- oops sorry there goes the rest of the world. bye. China Japan Korea Vietnam never heard of them ! Flash now provides graphic designers and programmers with an platform and tools to work in many ways. You want to load or server data then interface it in diverse modern graphic ways? Flash wins hands down. - REBOL could be a powerful complement to Flash for data and messaging. - Flash can be a powerful complement to Rebol for gui front end. - There is large growing community of Flash programmers. How many people know /View? How many books or web sites share /View components etc ? > I can install Apache in 3 mins, configure in 2 - so 5 min to run profi > http server on my desktop machine. You mentioned Jabber - so, OK - that > is something i agree with, if you think something like more advanced IOS > server, with direct communication and also polled communication, ability > to use some file-sharing principles, sync to multiple servers ... kind > of grid of various protocols, that would be cool. I can imagine rights, > roles, rules, workflow engines, which would allow you to model various > scenarios - that is REAL business oportunity, and it is a pity RT > dropped IOS development - it could be much better. Yes I agree. > >How about a really good mod_rebol component for Apache? > > > > > I agree - but then - fast-cgi is not all that bad and you also > mentioned money - how does RT makes money with that? Sell a good rebol http server suitable for robust Vanilla integration and one-click install At a fair price I'd buy some :-) Look at where Dave Winer's Manila - Radio Userland development is all going. WikiBlogs were the major new web technology growth since 2001. Now moblogs and fotoblogs are happening. http://joi.ito.com/ and friends > that RT should done the most general things ever and the rest should be > done by user-base. My top priority is: > > - general VM dialect - which would allow
[REBOL] Re: starting to be really late!?
Jason Cunliffe wrote: >>Is rebol ever going to catch up once again? We need Rebol with more >>media capabilities, better memory consumption characteristics and even >>better with general virtual machine in 2004, or probably never >> >> > > > First - let me add that I almost completly disagree here. So, here we go why: >While View is nice and capable of more, I really think Rebol's best >strengths are not graphics/media, unless RT got massive investment and had >some very different kind of marketing director working for them. imo Rebol >is best for invisible stuff. > It has to be defined what does invisible mean? Apache mode? Yes. Few other unix clones - no-way - waste of time. I e.g. did not understand, when Reichart told me, that he would like to see View for Solaris. Why? Because of FtpGadget? Excuse me, but now I call that total waste of energy and resources. Would it bring money to RT? Probably yes - but imo only short time. And Carl created Rebol because of some vision imo. And as for vision - sooner than later the world will be full of wireless mobile devices so I ask openly if we are going to stay behind or not. Something like View for Solaris or even systems like BSD is completly secondary point, if you think in some 3 + years. The only good thing is that such devices are going to be faster and faster, so maybe some Linux View version may run on them. > As things stand I believe it would be a >relative disaster for RT to spend too much more effort on /View devlopment. > > disaster? And that is why View 1.3 is under development? That is why direct draw modes were/are planned? That is why Carl told us that multimedia is his second name? :-) But maybe first - the problem with me disagreeing is - media - what is media? I don't think rebol should turn into media player - I just mean - ability to work with gfx faster. >Better to integrate and use make-swf, > what? Why? :-) What is the single advantage of making flash in rebol? That you would be able to run your "rebol" app inside the browser? Or where can I find flash and not rebol? Unless there is one-button-press conversion of rebol VID app into flash, it still means to program separately for View and for Flash ... >and work on tight useful Flash >integration. Look at the cool swf2exe prodcuts which have come out >Screenwaever, Northcode, FlashStudioPro. That's easy money and opens up >desktop flash applications to compete with Rebol very quickly. FlashStudio >pro adds 400 fscommands including socket, http, ftp, mail, file i/o.. What >more does one want or need? Even a Rebol-based swf2exe for Windows, Mac and >Linux [in that order] could be a very successful and useful product. And a >viable way to introduce Rebol to much larger and visible audience . > That can be done without any need for Flash. > The >mobiles will follow. > >Rebol Projects worth investing in? > >How about a really *great* http server in rebol with integrated tfp, xmpp >[Jabber], mail etc.? > > I can install Apache in 3 mins, configure in 2 - so 5 min to run profi http server on my desktop machine. You mentioned Jabber - so, OK - that is something i agree with, if you think something like more advanced IOS server, with direct communication and also polled communication, ability to use some file-sharing principles, sync to multiple servers ... kind of grid of various protocols, that would be cool. I can imagine rights, roles, rules, workflow engines, which would allow you to model various scenarios - that is REAL business oportunity, and it is a pity RT dropped IOS development - it could be much better. >How about a really good mod_rebol component for Apache? > > I agree - but then - fast-cgi is not all that bad and you also mentioned money - how does RT makes money with that? >How about rebol for bluetooth/wifi enabling digital video and still cameras? > >Let the others build media engines, let rebol be the modular engine they use >to communicate. > > So now I hope I reached the point which explains it all. I should not mention media - as by media I mean - fast, smooth refresh/movement of elements around screen, fast effectcs, nothing more - I in no way meant RT should duplicate works of others and make native divx, avi whatever codecs inside. I fully agree with integration. In fact - my pov is, that RT should done the most general things ever and the rest should be done by user-base. My top priority is: - general VM dialect - which would allow for to use subset of commands, would be fast and would not require to write external modules in C, as they mean end to cross-platform scripts unless ported to certain platform. TAO did it right with Intent imo. btw - on AltME world Carl told us, that such kind of VM would take one person average month to code. Imo worth real consideration then. - if not general VM, so dedicated VMs then - we call them dialects - currently we heave 'secure, 'remove-each ... we want
[REBOL] Re: starting to be really late!?
> -Original Message- > From: Jason Cunliffe [mailto:[EMAIL PROTECTED] > Sent: Wednesday, January 07, 2004 1:07 PM > To: [EMAIL PROTECTED] > Subject: [REBOL] Re: starting to be really late!? > > > > > First there was the rebol - x-internet app, nearly alone then > > others stepped in into the game - Flash MX ... now they are > moving ahead > > to mobile devices : > -If RT makes shell command access free (officialy, not just the browser hack) -If RT gives us the binary native!-capable module linker Then much discussion about rebol's missing capabilities is moot as then rebol can become a GPL just like python (actually much better) with all of rebols superior's methodology. want rebol to be the glue in your IT infrastructure, then shell acess does that. You want OpenGL speeds (if only in 2d) ... then a binary module would let us. No need to wish for RT to do it. yeah you can use a dll but that's not optimal and expects you to convert external datastructures in rebolesque equivalents which really aren't equivalent... and data conversion of large blocks of data is REALLY slow... just ask cyphre how fast importing/exporting images is... These two features alone make REBOL several times more usefull as a technology and industry-wide acceptable. IMHO they would let REBOL, as a platform, soar on its own with less pressure on RT to do everything. Direction of rebol comes by every few weeks and we've all stated our opinions, but I think that rebol's core weekness as a coding platform is its closed-in nature. The moment you want to do something that demands high-speed, guaranteed rates or actual complete and unbridled integration to external processes, then rebol USUALLY comes short. yess that is not rebol's primary vision (is it meant as a messaging language), but when every else does the above and you can't then it becomes a cause for concern for any pipeline/infrastructure IT manager. I also wonder why RT never packaged rebol AS a .dll or .so you can use IT INSIDE binary apps... so that you use rebol's integrated messaging capabilities within an application. this could yet broaden rebol's approach as a macro/scripting language (like a much better VB or arexx script engine). my 2 cents LET the flames roar ;-) -MAx --- -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: starting to be really late!?
> First there was the rebol - x-internet app, nearly alone then > others stepped in into the game - Flash MX ... now they are moving ahead > to mobile devices : > > http://www.theregister.co.uk/content/64/34740.html Actually there has been recent discussion and complaints, even in the excellent Flashcoders list, about too little real progress by Macromedia in the mobile area. http://chattyfig.figleaf.com/ Yes press announcements, but too little new tech, products or applications in real life. Largely a by-product of the lousy economy I think There has been lull and now lurch in cheaper compact memory. Color iPod/camphones with Flash in 2005/2006 ? I hope and think so. > Is rebol ever going to catch up once again? We need Rebol with more > media capabilities, better memory consumption characteristics and even > better with general virtual machine in 2004, or probably never While View is nice and capable of more, I really think Rebol's best strengths are not graphics/media, unless RT got massive investment and had some very different kind of marketing director working for them. imo Rebol is best for invisible stuff. As things stand I believe it would be a relative disaster for RT to spend too much more effort on /View devlopment. Better to integrate and use make-swf, and work on tight useful Flash integration. Look at the cool swf2exe prodcuts which have come out Screenwaever, Northcode, FlashStudioPro. That's easy money and opens up desktop flash applications to compete with Rebol very quickly. FlashStudio pro adds 400 fscommands including socket, http, ftp, mail, file i/o.. What more does one want or need? Even a Rebol-based swf2exe for Windows, Mac and Linux [in that order] could be a very successful and useful product. And a viable way to introduce Rebol to much larger and visible audience . The mobiles will follow. Rebol Projects worth investing in? How about a really *great* http server in rebol with integrated tfp, xmpp [Jabber], mail etc.? How about a really good mod_rebol component for Apache? How about rebol for bluetooth/wifi enabling digital video and still cameras? Let the others build media engines, let rebol be the modular engine they use to communicate. Anyway the mobiles will move moer and more to become embeded linux type devices I expect. so better to enjoy the broad media sdks avaialbel there don't you think? It is soo much work to develop viable media capabilities - sound video etc. For it ito be sucesful has to embrace many formats for improt and export. Thats a huge amount of expensive testing, debugging, extra documentation etc. Cool Proof of concept is not the same as globally adoptable, industy-ready product. - Jason -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
