World: r3wp

RE: VID3, I'm open to seeing new things.

I guess the answer, essentially, to my overall question is: REBOL 
programmers (or at least REBOL/View programmers) don't like Ajax, 
by its intrinsic nature.  Thus they are seeking to leapfrog apps 
that rely on Firefox and web standards by running on a new native 
cross-platform interface.  In the meantime, the bet is that those 
trying to maintain brittle PHP and javascript codebases will be fight 
a losing battl that will drown under its own weight, and REBOL/View 
will step in as the "real" Web 3.0.

And thus, effort is not directed by the core development team on 
browser-targeted development, though it's being pursued by those 
to whom it is of interest who also happen to like REBOL.  (e.g. Qtask)

Fork - I tell you the truth. We would all like to use REBOL for more 
than we can afford in our daily jobs, hence we are very jealeous 
to status-quo technologies, which are not cool, but popular :-)

In general, I don't like AJAX, but with HTML 5 it looks like it might 
become almost acceptable. Still, I would find it easier to generate 
such code from REBOL dialects than to write it directly. That is 
not the reason I don't do browser apps as often though.


The real reason is that most of the applications people use don't 
use web browsers at all. Most of the applications I use work offline, 
and no web interface works offline (though Google, Adobe and the 
Mono project are working on it).

http://localhostworks offline.  :)

Yes, definitely, I am advocating generative approaches... not wishing 
to generally pollute one's mainline code with javascript and HTML.

Sure. Then you can explain to the user why their firewall software 
is complaining about your application.

Or for that matter, why the address book app that used to take a 
few MBs of RAM is now taking hundreds of MBs.

Well, I am wondering how accurately I have summarized the REBOL/View 
point of, er, view above at 9:59:53 AM )

Fork, this is ok, really. I think we understand your point. Simply 
put - browser based apps are rational way to go with nowadays. You 
can run it everywhere, plus other advantages, minus some disadvantages 
...

Hey don't take my summary as a bad thing, ambition is good, I just 
want to understand the philosophical landscape... :)

yes, are ambitions are high - we are web 3.0, let's others play with 
web 2.0 for now, thinking they have something cool at hand. Then 
you see some total jokes as Sun posting their JS based desktop attempt, 
which is 10 times slower than SWISS (7 years ago View attempt without 
any optimisations :-)

and. We have, well, I have, - the name for the browser plug-in product 
- FireSide :-) We will Fire from the Side. And FireAnything is popular 
today ...

There is also no third small technology for browser plug-in, so small 
and agile as View ... so Flash, Silverlight, View .... or do php, 
perl, python, other guys have anything at hand?

So - now you know are very ambitious ambitions ... keep your fingers 
crossed for us :-)

are=our

Ok, I'll cross 'em :)

So what I'd worry about is having REBOL closed source and under control 
of a single authority structure, and then to entertwine the fates 
of the pieces together so tightly.  That could mean REBOL could have 
succeeded as a language and grown in acceptance if it hadn't been 
for REBOL/View having such high ambition for being the delivery vessel 
for apps.  Just my opinion...

REBOL is getting less and less closed source every day, and the authority 
structure is not that different than the developer groups of most 
major open source projects. Completely open acceptance of submissions 
is a nice-sounding idea, but once a project gets large they have 
to rein in the submissions just to keep the project semi-stable and 
reasonably bug-free.

If you want to really know the philosophical landscape here, then 
here are some basics:

- We trust Carl's judgement on language design - otherwise, we'd 
be using a different language.

- Most of the language features in R2 were intentional, even the 
ones that seem weird to people who are used to other languages.

- This is even more the case with R3, as the decisions made there 
have to get through a gauntlet of highly skilled REBOL programmers.

- The language features that were mistakes may not be the ones you 
think were, and most of those are getting fixed in R3.

- We value tight programming: It is not uncommon to replace dozens 
of lines of code with a just a few lines of tight code.

The correlary to that first point is that we accept the closed source 
core of R3 because it gets us a better language. If we have problems, 
we discuss them, and they get fixed. There are code escrows for the 
event of RT going out of business, Carl dying, whatever.

correlary -> corollary

I agree with you that the monolithic closed source of R2 was a problem 
that inhibited adoption. This a problem that is getting fixed in 
R3, and to a certain extent R2 as well starting with 2.7.6.

We could also mention open DevBase - all open-sourced parts are going 
to be uploaded there ...

R3 is the culmination of 8 years of experiencing what's wrong and 
right with R2. It's nature and philosophy is basically the same (small, 
simple, lightweight), but there are improvements in almost every 
aspect of it. I don't expect R3 to be feature and design complete 
probably for another 6-12 months as there are still many things missing. 
R3 is the third attempt at REBOL. The first one was about 30 times 
slower than R2 and ate much more memory, because the design philosophy 
was different (Carl didn't implement R1). With R2 we had the right 
philosophy in place, but the implementation lacks in many areas, 
and it has many bugs. With R3 we're getting much closer to fulfilling 
that philosophy with design from long experience with R2, openness 
and richness without the bloat.

There are code escrows for the event of RT going out of business.

 Isn't that only for big customers that had signed special contracts 
 with RT ? What about us ? In the worst case, will REBOL be open-sourced 
 or will we have to trash all our REBOL apps and go learn a new programming 
 language ?

I've got this application which does some http stuff ( posting images 
) and then waits for user input.  But after processing a bunch of 
images, VID becomes sluggish .. any suggestions as to what might 
be causing this?

Memory overhead that triggers a lot of disk swapping ?

loading images should be done into the same place, rather than just 
load them for immediate saving, e,g.


foreach source sources [write/binary target read/binary source] ; 
REBOL eats your memory for breakfast :-)

img: make binary! 1000000

foreach source sources [insert clear img read/binary source write/binary 
img] ; Should be better

Hmm...  I was setting the image to none afterward to release memory 
but perhaps it was not enough

recycle?

henrik, unless there's a bug, that should not really be better. using 
read-io and write-io with a buffer may be better.

Gabriele can you give us a brief understanding of what read-io and 
write-io are for or when to use them as I know there was a lot of 
communications from RT early on about shying away from using them.

Gabriele, I've seen it, but I'll make a test script to see if I'm 
right.

well, now of course it doesn't work. :-) oh well.

It's not my imagination that request-file/title {something} {button} 
- the button text never shows up (at least not in windows). It complains 
if it is not there but I don't think I've ever gotten it to work.

Paul, indeed read-io and write-io are no more necessary. however, 
if reusing the same memory buffer is the intent, then they're the 
only way to do that. it may be better to just copy a small part of 
the file at a time and let the GC do its job instead.

That is very good to know Gabriele.  Thanks.

So read-io is no better than copy/part correct?

I remember, that it is possible to use fonts, other than the rebol 
supplied ones, but can't remember _how_ (and haven't been able to 
find anything so far.

Is it possible to even use uninstalled fonts? (Truetype, Opentype, 
Type 2)?

yes

you just have to specifiy the path in the font definition

http://www.compkarori.com/vanilla/display/AGG

Ahh, I was sure, that it would work! Thank you!

Doesn't work on all distros though ...

works on debian based distros and puppy linux that I've tested.

I'm on Ubuntu, and it works for me.

Ubuntu is a debian based distro :)

Any view users here?  I'm looking for a routine that will trim the 
whitespace from an image, and will also trim junk from an image. 
I'm taking a rectangular piece of some scanned text, and if I cut 
partly thru the text above, or thru the top of the text below, I 
wish to remove those parts just keeping the word I'm interested in 
....