World: r3wp

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 
....

I've been looking for something similar.

I don't really need to trim the whitespace ... just the junk

Perhaps I can just inch along the top and move down until I reach 
all whitespace across the image to reach my border.

Invert the image and then do it again ....

Henrik, are you doing some image processing too?

I was thinking about an automatic cropping tool, but I'm not sure 
how to do that.

I made a very simple auto-crop function, remember ?
I can probably modify it to perform the above function...

http://anton.wildit.net.au/rebol/gfx/auto-crop.r
http://anton.wildit.net.au/rebol/gfx/demo-auto-crop.r

(that's the function from September 2007)

A possible algorithm for the new junk cropper could be:

1) advance inwards from each edge until there is a full white line 
parallel to the edge.

2) if a white line was found for each edge, then advance inwards 
again, this time searching for a non-full white line, (eg. with a 
few pixels from the desired text in it). Step back a line and you 
have your crop region.