World: r3wp

Thanks Henrik for the append vs insert optimization too!

Thanks Henrik, I was a bit confused by looking thru the core and 
dictionary functions - the examples don't really show advantages/disadvantages 
for real world apps

one thing that amazes me is that PARSE is very fast, despite being 
one of the most complicated functions to understand in REBOL. if 
you learn how to use it, it can perform some quite amazing tasks.

and once again, we'll be turning this upside down for REBOL3. :-) 
there are a lot of new functions to aid in the creation and manipulation 
of blocks with simple code that also performs very well.

Yes I've only used it for my licence creator applet - I't's one of 
the core items I need to master. At the moment I'm trying to get 
blocks/series to fit into recursions I have created in legacy apps

I don't mind re-learning these for R3, I thnk I need to learn R2 
to master R3

sorry this wireless keyboard has a stutter ;-)

So the immediate thing I've picked up is as you use append Rebol 
has to re-form the block on each iteration! Is that right?

generally about speed: I rarely worry about REBOL/Core speed. I made 
a database once that was mainly about in memory block manipulation 
in REBOL. On an old 500 Mhz Celeron laptop, I couldn't saturate it, 
when throwing queries at it from 3 fast PCs over a 100 MBit LAN. 
I think it was about 100-1000 times faster than a MySQL database, 
but of course with the price that it's in-memory and that it had 
very few features.

be careful about wording, as 'reform is a function in REBOL. :-) 
all it has to do, is allocate more space. Just imagine a cramped 
desk and you want to put some things on the desk. Which is faster? 
Is it to remove one item at a time from the desk to place a new one 
there, or just swipe the desk clean in one go in order to free all 
desk space immediately?

The processing seem's amazing compared to say one of my c# apps.

yes, and they say interpreted languages are slow, right? :-)

Yep sorry Henrik, I meant allocate more space

Well really VB and C# are interpreted as well

the code for a c# app is compiled into an intermediary psuedo code 
then interpreted by the CLR (Common language runtime)

generally you just want to reduce the cases where you need to allocate 
space. if you reduce the number of cases and that reduces the number 
of garbage collections needed and there is a greater guarantee that 
all the allocated space will be freed up. REBOL is good, but the 
garbage collector isn't super intelligent so it helps to simplify 
its work.

I was going to ask how efficient the GC was in Rebol - it's one thing 
that is good in c'# compared to c++

how it works exactly is unfortunately undocumented. Only Carl knows, 
so everything we know is based on observations and tests.

when your re-painting screens and such you have to force GC or the 
display struggles

View is a bit different, because it hogs memory quite badly. You 
can do a few limited things there to speed up display, but not much 
in terms of helping GC.

Video processing on R3 looks amazing

the difference in performance on R2 vs. R3 in graphics is also quite 
amazing, mostly thanks to much reduced memory requirements to create 
and manage graphics.

Using the alpha channel allows for some great transparencies and 
other effects

btw, about your append question... no, append does not need to allocate 
memory at each call. each series has some space free, and when that's 
up, a bigger space is allocated, usually with 2x increments (until 
a certain size, then it's linear). however, the whole series needs 
to be copied when that happens. so, if you append 1000 times, it 
may happen just 2 or 3 times, but still, if you know the final size 
already, you can save a lot by just preallocating it.

if you don't know the final size... it's usually better to let rebol 
do its magic. but, i'd suggest timing the code and deciding which 
is really going to perform better, as there are many variables involved.

gabriele, doing "magic", isn't that degrading performance in the 
long run, if he has to perform the operation thousands of times?

Thanks, I think with the speed that's been mentioned compared to 
my old recursions in c# I'm worrying about nothing.

Biggest customer i've got has 250,000 x 20 rows x 15 tables

Gabriele, what I'm mostly concerned about is how memory is eaten 
up over time, because GC isn't done well enough. Do you know anything 
about what will be done here in R3? Will the GC be documented?

steveT, if you have the memory to fit that amount of data, then REBOL 
will process it without problems.

cool, I think I used to suffer a little because if your try to open 
a recordSet in visual studio it creates a natural bottle-neck because 
some idiots might have bound controls - and it has to handle that. 
I had to do all my processing of data on a 'SQL disconnected basis' 
 know what I mean by that?

I think from what everyone says once you get data into REBOL it's 
wonderful. I just wanted some options for pulling the data in.

for those cases:  Learn PARSE. I haven't fully learned it yet, but 
the things it can do is just.. wow :-)

I will. Will there be something standard in R3 to say pull a csv 
file in to blocks?

PARSE in R2 already does that to some extent.

an example of that would be much appreciated ? I need to print this 
thread out and digest what everyones suggested. Thanks so much for 
all the help.

I don't think much time will be spent on building special import 
functions unless its for media formats, which would really require 
performance.

read/lines is a start to turning CSV into blocks -- you get one block 
entry per record.

right , thanks I'll have a go with that. I'll save all these snipets 
and perhaps we could build a database how-to to put on the new users 
docs.

about PARSE: http://en.wikibooks.org/wiki/REBOL_Programming/Language_Features/Parse

thanks for that Henrik I'll have a look! Sorry i need to sign-off 
for a while (wifes picking up new car) please carry the thread on 
without me I'll print it later - thanks one again.

I found Brett Handley's parse tutorial a big help: http://www.codeconscious.com/rebol/parse-tutorial.html

Thanks Peter

I too found Brett's parse tutorial very helpful.

Hi Henrik, I read your blog about Natives vs. Actions vs. Mezzanines, 
thanks it explains the speed differences.

I regularly import CSV files into REBOL.

The only trick is that I insist they be tab-delimited rather than 
comma-delimited, and that none of the strings contain tabs. That 
way, we can be sure that tab occurs only as a field delimiter.
The code then is
   data-block: read /lines %csv-data-file.txt
   foreach record data-block [
        record: parse/all record to-string tab
        ....code to handle the 'record block
    ]


If you need to handle actual comma separated where strings can also 
contain commas, you'll need to tweak the parse.

Thanks so much Sunanda, a couple of my customers receive stock update 
files as csv's (I don't think we could get them to send tsv's ) but 
that will fill a requirement brilliantly. If I decide to move any 
more complex apps to Rebol I may need to wait till I can get R3/command, 
I believe that will give me odbc (for excel and access) imports etc.

I've learnt an awful lot over the past week! But I think one of the 
most profound lessons I've learnt,

I quote from one of the WIki guides on the language


 This is perhaps the most important single piece of advice when learning 
 REBOL for the first time: 

    forget the past. Forget what you 
 already know about programming.

    REBOL is different. If you know 
 other programming languages such as C or BASIC, and you expect to 
 program REBOL the same way, 

    then what you will get as a result 
 is C or BASIC. Nothing better. We've seen this happen many times. 
 courtesy of Wikibooks




Every function or data routine I've written this week, I have stepped 
back from and thought "that's the c# way of doing it!"


Rebol opens up wonderful ways of approaching software tasks - I think 
I'm just entering my second week of de-programming.

Just posted this to my blog http://swt1962.spaces.live.com;-)

BTW SteveT, the CLR doesn't interpret its bytecodes, ever - it compiles 
them to native code and then executes the native code. Interpretation 
isn't what makes .NET and C# slow.