AltME groups: search

Some of them are natives, and some are mezzanine code.

That gives you a choice: use the natives for speed, or the mezzanines 
for convenience.

how to alter the speed of reproduction the  sound of  file *.wav 
?

I plan to keep running Opera on a regular bases.  I think there are 
more features than I'm seeing so far, but in a nutshell:


-	Separate Universe: Having a "another" browser is a good way of 
keeping things sepeate.  For example I might use Opera for my Qtask 
test accounts, and for checking up on some "grouping" of sites, since 
Opera is good at opening multiple tabs at start up (although it should 
stagger them since this is one of the speed hits).


-	Cache: It seems to auto pull a page it decides is the last version. 
 I'm not sure how it decides this yet.  But if I figure it out, this 
is a cool feature.


-	Magic wand: Great feature.  It should have its OWN password.  In 
other words.  Andy, Billy, and Carry, all use the same computer. 
 There are a lot of families that do this. IT would be nice to group 
your log ins to the same sites (AB and C all have separate Yahoo 
account, and separate Amazon accounts).  So they can basically Log 
in first with Opera, then go to town.  Even better would be an online 
service for this.  Can't wait for Identity 2.0.


-	Overview:  Opera has this cool feature of showing you a 3x3 grid 
of thumbnails of you fav sites.  This is cool.  So cool I want to 
see if there is a plug in for FF for this too.-

I have looked at Ashley's RebGUI work already, very nice.  Need to 
bring my basic REBOL up to speed though to start using it.  I did 
note the bundles part already as well, very helpful.

I've been noticing AltMe freezing when retrieving a message - when 
done, it goes back to normal. Is this a network latency or speed 
problem, or something else?

I've been using Altme for a project with a guy who is very non-tech. 
He did not know how to drag a window. Anyway, it is working out great. 
We are using File sharing to re-format a bunch of text files and 
with the abilty to add comments and check lists its saving a lot 
of time over traditional Email. He is still not really up to speed 
so once he is it wil really shine. And with the abiltty to just add 
new members where they can read any old messages to see where we 
are and what we have been doing.


I regret not using it for my Appraisal business. My partner and I 
had to email files back and forth all the time. And sometimes we 
needed to get files from one another but one of us was away or not 
at our computer. If we used Altme we would never have had that problem.

Altme is absolutly cool even with its efficiencies. I set-it-up in 
10 minutes for our small team, and the communication is - instant. 
The only problem is the noise - it has IM nature, so you go off-topic 
pretty fast. But other than that, so far, no other web based system 
can compare in speed. Simple AltME DMS is also good for some basic 
stuff. Off-line sync nature is also welcomed sometimes.

btw, IMHO,  the current altme droppings aren't due to networking 
speed/internet woes ... right now, when I post I get a turnaround 
well below half a second.

It almost feels instantaneous.  still I must relog every so often, 
If I want to be syncing again.  the server just stops responding 
after a few minutes.  :-(

Seems ok speed here.

yes, I see the same thing. I recall there was a sudden drop a couple 
of years ago in general speed and it has been like that since.

But now we can use rebcode to speed it up ?

Yeah, IN can speed things up a bit when repeatedly accessing the 
same member of a object, saving on lookup time. It can be used to 
provide object field access in rebcode by calling it with apply too. 
Useful function.

Another thing that would interest me, is how is the speed impact 
when using your above function, now even with closures - I mean the 
closure function copies everything on invocation and also make-instance 
itself binds everytime anew?

Yeah, local versions of that scattered around the world would be 
help with the speed..your's is too slow for me

Well, each of the elements (numbers) in a tuple is an integer from 
0-255. Doing a binary operation with that restriction and an integer 
without that restriction should maybe return none or an error? I 
guess, REBOL is optimized for speed doing this, so the result is 
undefined. (You can probably guess some internal rules/side-effects.)

These operations can be defined correctly. The values returned are 
improper imo. And the speed optimization doesn't gain much.

How do i check If a value in serie a does occeur in b on a specific 
position ? Currently im doing that with a foreach including a for 
loop..But somehow rebol should have something buildin i thought? 
or not.. unqiue intersect and difference are not good enough for 
this...and speed is a concern too..

talking about speed improvement!! that 'for loop is very slow compaired 
to the 'repeat ;-) thanks..

Well, you can write your own; if just prototyping, the speed isn't 
critical (we did 160 bit math for Maarten, using bitsets, at one 
point). That said, if you can use a version with rebcode, just wrap 
a mezzanine around the ops. 


That said, I wouldn't mind having standard SHIFT and ROTATE funcs 
that can operate on integer, or series values. Bit ops are also necessary 
for implementing certain algorithms.

right now every time it creates 100000 new nodes, my loop's speed 
steadily increases by about 0.065 %

but it seems it would be a speed - size tradeoff.

The way you speed up appends is to force the block to preallocate 
at least as much memory as you think you will need right away by 
specifying that number as the second argument to MAKE.

just for the record, I tried using lists, but in this stress test, 
they were quite memory intensive (compared to blocks) and eventually, 
the GC got slower at a rate quicker  than the speed improvement I 
did notice in the begining.  sooo as always, speed vs flexibility 
vs RAM still applies as always.

enblock (reduce deblock data) 3

Some meazzines i use sometimes. But they are meazzines, if speed 
reeally is  an issue..

Graham: as I need the date conversion again, I found that to make 
it useful, you have to add the error check anyway so it's:

>> t: now/time/precise loop 10000 [all [not error? try [d: load "sss"] 
date? d]] now/time/precise - t
== 0:00:00.031

>> t: now/time/precise loop 10000 [all [not error? try [d: load "1-1-2007"] 
date? d]] now/time/precise - t
== 0:00:00.047

>> t: now/time/precise loop 10000 [error? try [to-date "1-1-2007"]] 
now/time/precise - t
== 0:00:00.047

I would not use loading. to-date is more clear, shorter and with 
same speed.

hehe... well, there litterally are about 50 things missing yet. I'm 
emphasizing on having speed even on huge lists and minimal editing 
capabilities.

there's "to image!" and it's 600x600 pixels so I think it's REBOL 
redraw speed limitation...

even if the wind speed is not enought significant

for example today  on paris we have wind from north  N (360) speed 
12 KT.

OK, wind speed is shown by another widget.

What I want to symbolise is the wind speed and direction and the 
humidity

It's not a bug but an intented behavior : it's a pair input style. 
There is for steps, each step can add any value to the pair. The 
repeat speed is also a parameter.
ie:

 stick-style speed 8 steps [1 2 5 10] ==> 8 is the repeat speed (rate) 
 and 1, 2, 5 and 10 are the values added to the pair!, depending how 
 you move the stick.


 stick-style value-mode decimal! ==> value is a block of 2 decimal! 
 values rather than a pair!

it seems to be about the same speed

Henrik, it must be something special with your setup, and you get 
slow console output on the
do http://www.rebol.com/speed.r

speed-test, as we talked about. You could post your speed output 
here somewhere and specify your setup. Maybe others have a solution!

I get:
Console:   0:00:01.703 - 297 KC/S
Processor: 0:00:00.406 - 2128 RHz (REBOL-Hertz)
Memory:    0:00:01.344 - 35 MB/S
Disk/File: 0:00:00.203 - 150 MB/S

on a 2.4GHz Pentium 4, 512 MB ram (not sure about speed, it's an 
ASUS P4P800 board), ATi Radeon 9600, not the newest drivers.

I've been grumbling over a few observations I did on early versions 
of Canvas and ROAM regarding SHOW on three different machines: A 
slow PC linux laptop, my fast Windows PC with a Radeon 9500 graphics 
card and my mac mini with medium speed Radeon 9200 graphics chip. 
For my tests I used the ROAM object browser available in the desktop 
under Rebol/REBOL Tools.


When I maximize ROAM to full screen on my laptop and mac, they are 
rather slow at redrawing the highlight bar. But if I move the mouse 
quickly to the top/bottom of the list, the highlight skips those 
entries that can't be highlighted in time, and therefore it remains 
fairly responsive even if the frame rate is low.

However on my fastest machine with my powerful Radeon 9500, the highlight 
bar moves at a snails pace behind the mouse pointer, insisting on 
redrawing every highlight. It takes at least a full second to reach 
the current mouse position and the event system is locked and REBOL 
is fully concentrating on SHOWing the list face.


The amount of time SHOW takes to display the list view is dramatically 
dependent on the size of the window. A small 400x400 window is fast 
enough for normal use, but a 1280x1024 window is very slow.


It looks to me like a frame rate problem: Somehow my fast machine 
calculates a specific very high framerate (say 50 fps) that SHOW 
should handle for the list face, but can't keep up at all. Therefore 
50 SHOW operations take 2-3 seconds longer than they should and the 
delay occurs and it drowns out the event handling. This framerate 
is apparently tuned properly on the Linux and the Mac so it never 
becomes a problem there. How is this framerate calculated?


Also when I run the console benchmark program, I get remarkably bad 
performance on text output on my normally fast Windows machine, while 
the mac and linux consoles output text 5-10 times faster. Reports 
from other Windows users say my console is very slow.


I'm really just wondering if others with Radeon graphics cards and 
Catalyst drivers have similar problems.


Not all is bad: This framerate problem can be solved within REBOL. 
I did a simple delay system for Canvas which sped things up quite 
a bit on my machine and I've just done a dynamic method for ROAM. 
The delay system simply implements a DELAY-SHOW function which does 
not invoke SHOW unless a specific amount of time has passed. The 
method I did for ROAM is dynamic in that it measures how long a SHOW 
takes and adjusts the delay accordingly plus a tiny safety margin 
of 0.01 seconds. It works quite well. At the cost of a reduced framerate 
and sometimes missing a redraw at the end of a mouse move, I get 
a much more responsive ROAM, and the framerate adjusts nicely between 
large and small windows.

See if you can tell the difference between:

http://www.rebol.com/view/tools/roam.r
and
http://www.hmkdesign.dk/rebol/roam.r

Maybe right time. rebcode goes speed, iterated lists goes memory.

imo, with current speed of broadbands, where dial-ups are going away, 
something like 5 secs of timeout could be enough?

uploaded 0.0.11

Changes:

      New: Header can now be defined from the words in OUT-COLS or IN-COLS

      New: No longer need to manually create the subface for the list
      Fix: DATA was not properly initialized

      Fix: List was updated twice during all manipulation functions added 
      in 0.0.10

      New: Added /no-show refinement to FLT-LIST to speed up certain updates 
      that require setting the selected row before showing

Ingo, thought it must have been there.. Interesting behaviour. I 
wonder if it is intentional ? Could be for speed in high-throughput 
applications.

i'd guess path is going to stay this way for speed (internal only), 
but select could be a good interface to it.

You can speed it up a little bit by doing this:
view/new/title center-face main: make-face/spec 'box [
  size: 400x400 
  rate: 50 feel: make feel [

I see no speed difference, but maybe it needs to be measured.

Ah well, looks only about 1% faster.  I remember also Cyphre reporting 
that face refreshes speed up significantly when the offset is at 
0x0.

I add the probe do-events and here is the result:
probe do-events

make port! [
    scheme: 'event
    host: none
    port-id: none
    user: none
    pass: none
    target: "events"
    path: none
    proxy: none
    access: none
    allow: none
    buffer-size: none
    limit: none
    handler: none
    status: none
    size: none
    date: none
    url: none
    sub-port: none
    locals: none
    state: make object! [
        flags: 4719107
        misc: none
        tail: 0
        num: 1
        with: "^/"
        custom: none
        index: 0
        func: 12
        fpos: 0
        inBuffer: none
        outBuffer: none
    ]
    timeout: none
    local-ip: none
    local-service: none
    remote-service: none
    last-remote-service: none
    direction: none
    key: none
    strength: none
    algorithm: none
    block-chaining: none
    init-vector: none
    padding: none
    async-modes: none
    remote-ip: none
    local-port: none
    remote-port: none
    backlog: none
    device: none
    speed: none
    data-bits: none
    parity: none
    stop-bits: none
    rts-cts: true
    user-data: none
    awake: func [port][wake-event port]
]

anton, interestingly also, speed has nothing to do with it. you can 
do the same thing at keyboard typing speed.

(that is, run each iteration at keyboard typing speed, not full rebol 
light speed :-))

Just realised if I dont go to bed now the birds will start singing 
& the sun will be comming up again.. Rebol seems to cause time to 
speed up :-)

I cant get the library to accept it :-(
make object! [
    code: 200
    type: 'syntax
    id: 'invalid
    arg1: "path"
    arg2: "intIpaddrS/"
    arg3: none

    near: {(line 68) write/append outFile reduce [either debug [currentFile 
    tab i tab] [""] hostname tab ipVrfForward tab interface tab vlan 
    tab mode tab trunkEncap tab nativeVlan tab allowedVlans tab upState 
    tab intDesc tab speed tab duplex tab intIpaddrS/(count1) tab QualifiedNetworkS/(count1) 
    tab tagMtu newline]}
    where: none
]

Use of 'return is partially a personal style issue. It is, literally, 
not needed if the last value your function handles is the one you 
want returned; in that case omiting the 'return can speed up a function 
considerably.


On the other hand, consider "literate programming" conventions: it 
can be polite to spell out the details so future code readers do 
not need to recapitulate your clevernesses just to work out what 
is returned......The code snippet below can return three separate 
things: spelling it out would help future generations!

    f: func [a b][
      either a > b [
          print a
         ][
         if a = b [b + 5]
        ]
     ]

Some of them will speed up parse performance, others will have little 
effect outside of their specific operation.

mostly, speed-up improvements. except for 2 functions AFAIK.
Do you know which ones guys ?
(Brian, you don't play :-)

if your code is slow, can always speed it up by running a faster 
cpu :)

If it's not fast enough you can speed it up by adding a rule to consume 
the unwanted parts.

I am the editor of the PARSE proposals.


It was decided that I perform this role because Carl is focused on 
the GUI work right now and someone qualified had to do it. With Carl 
busy and Ladislav not here, I am the one left who has the most background 
in parsing and the most understanding of what can be done efficiently 
and what can't. When the PARSE REPs of old were discussed, I was 
right there in the conversation and the originator of about half 
of them, mostly based on my experience with other parsers and parser 
generators. Because of this I am well aware of the original motivation 
behind them, and have had many years to think them through. It's 
just head start, really.


I am also the author of the current implementation of COLLECT and 
KEEP, based on Gabriele's original idea, which was a really great 
idea. It is also really limited. Collecting information and building 
data structures out of it is the basic function that programming 
languages do, and something that REBOL is really good at. I am not 
in any way denigrating the importance of building data structures. 
I certainly did not mean to imply that your appreciation of that 
important task was in any way less important.


The role of an editor is not just to collect proposals, but to make 
sure they fit with the overall goal of the project. This sometimes 
means rejecting proposals, or reshaping them. This is not a role 
that I am sorry about - someone has to do it to make our tool better. 
We are not Perl, this is not anything goes, we actually try to make 
the best decisions here. I hate to seem the bad guy sometimes, but 
someone has to do it :(


PARSE is a portion of REBOL that is dedicated to a particular role. 
It recognizes patterns in data, extracts some of the data, and then 
calls out to the DO dialect to do something with the data. It doesn't 
really do anything to the data itself - everything happens in the 
DO dialect code in the parens. It is fairly simple really, and from 
carefully designed simplicity it gets a heck of a lot of power and 
speed. That is its strength.


The thing that a lot of people don't remember when making improvements 
to a dialect like PARSE is that PARSE is only one part of REBOL. 
If something doesn't go into PARSE, it can go into another part of 
REBOL. We have to consider the language as a whole when we are doing 
things like this.

Here is the overall rationale for the PARSE dialect proposals:

- All new features need to be simple to explain and use, and fast 
at runtime.
- A good feature would be one of these:

  - An extremely powerful enhancement of PARSE's language recognition.

  - A fix to a design flaw in an existing feature, or a compatibility 
  fix.

  - A serious improvement to a sufficiently common use case, or common 
  error.


The reason I didn't want to put COLLECT and KEEP into PARSE is because 
it is a small part of a much bigger problem that really needs a lot 
of flexibility. Different structure collection and building situations 
require different behavior. It just so happens that the DO dialect 
is much better suited to solving this particular problem than the 
PARSE dialect is. Remember, PARSE is a native dialect, and as such 
is rather fixed.


There are some PARSE proposals that make parse actually do something 
with the data itself: CHANGE, INSERT and REMOVE. We were very careful 
when we designed those proposals. In particular, we wanted to provide 
the bare minimum that would be necessary to handle some very common 
idioms that are usually done wrong, even by the best PARSE programmers. 
Sometimes we add stuff into REBOL that is just there to solve a commonly 
messed up problem, so that a well debugged solution would be there 
for people to choose instead of trying to solve it again themselves, 
badly. (This is why the MOVE function got added to R3 and 2.7.6, 
btw.) Even with that justification those features might not make 
it into PARSE because they change the role of PARSE from recognition 
to modification. I have high hopes, though.


Another proposal that might not make it into PARSE is RETURN. RETURN 
is another ease-of-use addition. In particular, the thing it makes 
easy is stopping the parse in the middle to return some recognized 
information. However, it changes the return characteristics of PARSE 
in ways that may have unpredictable results, and may not have enough 
benefit. The proposal that has a better chance of making it is BREAK/return, 
though I'd like to see both (we can hope, right?).


Most of the REPs from Gabriele's doc have been covered. Most of them 
have been changed because we have had time in the last several years 
to give them some thought; the only unchanged ones are NOT and FAIL, 
so far. Some have been rejected because they just weren't going to 
work at all (8 and 12). THROW and DO are still under discussion - 
the proposals won't work as is, but the ideas behind them have merit. 
The rest have been debated and changed into good proposals. Note 
that the DO proposal would be rejected outright for R2, but R3's 
changes to word binding make it possible to make it safe (as figured 
out during a conversation with Anton this evening).


There are other features that are not really changes to the PARSE 
dialect, and so are out of scope for these proposals. That doesn't 
mean that they won't be implemented, just that they are a separate 
subject. That includes delimiter parsing (sorry, Petr), tracing (sorry, 
Henrik), REBOL language syntax (sorry, Graham), and port parsing 
(sorry, Steeve, Anton, Doc, Tomc, et al). If it makes you feel better, 
while discussing the subject with Anton here I figured out a way 
to do port parsing with the R3 port model (it wouldn't work with 
the R2 port model). I will bring these all up with Carl when it comes 
to that.


I hope that this makes the situation and my position on the subject 
clearer. I'm sorry for any misunderstandings that arose during this 
process.

not always. if you need maximal speed. and you  trust the data and 
rules.

dehex, agreed -- until the speed trade off becomes worth it.  Which 
may be if you are wanting to get more than just the language from 
the string.

Economical how, in space, speed, or complexity? e.g., repeated FINDs 
can seem inelegant, but are easy to understand and maintain.

If lines match more than one rule, what is the desired behavior?


Assuming you have test data, and if performance is the key, have 
you done any quick tests?

I remember having requested 3 commands to speed up the management 
of  our own stack in the past [push, pop and rollback]

n break allows you to tell the parser that you DON'T want any backtracking. 
 its a way to optimize rules for speed, if nothing else.

but n BREAK allows us to leverage smaller rules reuse, as if they 
where large complex rules and still benefit from the same speed of 
a root rule backtrack.

I think that Carl is trying to balance speed, ease of use, and debugability. 
In practice n BREAK would be tricky to debug, and doesn't actually 
reflect what PARSE does internally. Apparently PARSE isn't actually 
recursive descent - it just fakes it with a state machine.

same as mine, except i use THRU to speed up the process

ladislav, Remark changes the input on the fly to implement function 
html unfolding, and using that improved speed by 50 times, when compared 
with traditional series manipulations.

so yes its seriously usable   ;-P

its not a single change/part which is the issue, its managing the 
stack, allocating all those blocks over and over... the sheer speed 
of the parse loop, blows away all the other looped/recursive algorythms 
in my usage so far.

my take on "speed" is as follows - ppl sometimes object, that you 
use "interpreter". And my answer is - why should I care? The thing 
is either fast enough for me, or it is not fast enough for me. If 
you will try to edit video using REBOL level pixel manipulation, 
you surely will not be happy. But - if your app behaves real-time 
or generally time results are acceptable for you - why to worry at 
all?

I updated the above mentioned Rebol wikibook section - the speed 
discussion subsection added. So, read, it, please (the latest, i.e. 
yet unsighted version!) and see also the CureCode ticket #1570, which 
is related to this issue.

and extra speed consideration of having to allocate/copy/destroy 
a series

Just to get you up to speed, I think the major problem to fix is 
the editor in the area.  To fix : cursor keys, and pageup/down behaviour 
especially at boundary, and also cr behaviour.  Highlighting is also 
problematic.

pretty smooth - maybe I have to try it one day ... what I did was 
put a lot of text in Carls first test of the transformation matrix 
example, where he wanted to know if the behavior is correct - and 
if you have a lot of text and zoom into it, it gets slow - but there 
are people here who know better (and might prove me wrong) - for 
me it would be too nice if somebody proves me that the same stuff 
as in the link is in sufficient speed possible with Rebol, even if 
there has to be some clever arrangement of the objects to be shown 
- I mean that objects not visible don't get rendered

I guess so, Second LIfe has also pie menus. 

Graham: this didn't mean that there are other ways to use menus and 
of course depending on the input device there are better ways. If 
you have keyboard shortcuts for everything you can even be faster 
in doing things. If you have a scroll wheel zooming into is pretty 
natural as is paning with a extra button - but didn't anybody feel 
that in this zoomit demo one could surpisingly well use the interface 
and especially with what speed ? (just compared to putting the same 
functions to a traditional context menu)

Also one should just try to use mouse-gestures in Opera - after using 
them you always want to use them - even though I often out of habit 
do the same in IE or somewhere else and it doesn't work - the most 
important thing to note for me is that it's worth having an interface 
one can form habits in using it - only then usage will be very fast. 
If one puts the one or other stumbling block into it, it will never 
flow, you always have to concentrate on what you're actually doing. 
Just imagine driving a car and having always to think about how to 
steer or shift (for many of the european people :).

anton, what is the problem with checksum? It depends on syncing strategy, 
but you have those files on both side (client, server) anyway. afaik, 
the problem with checksum could be its speed. But since we have open/seek, 
we could do checksumming defined,e.g. 3 parts of files, first xy 
bytes, last xy bytes and defined skip somewhere to the middle of 
the file ... dunno if it would work though :-)

hummm drop down list is a nightmare of coding ... this is typically 
(in my opinion) one of the easyly doable in C/C++ but tricky to do 
with rebol. Tricky but why ?? Mainly because of the speed when you 
have to redreaw the main pane and the scrolling interface

as it's widely dynamical widget you will have to heavily use the 
redraw  i don't know if rebol can handle that properly in term of 
 onscreen drawing speed and on the plan of the memory(this point 
is the dark spot of rebol)

I have done extremely advanced styles in rebol, including a video 
editing timeline with scalable time and slideable tracks,  and face 
can be extremely fast when its used properly.  The only issue so 
far was Draw speed (fixed with AGG) and slow face blitting (cpu based). 
 Otherwise, if your face is not full screen, you can scroll 300000 
cell tables 10 times a second... (yes with advanced styles and resizing 
and the like).

Latest SVN change (Rev#16) now uses reduce/only to evaluate words 
/ paths without the need for compose. This allows code like:

display "" [
	image i
	bar my-width
	field my-data/field1
	...
]

to be written. It still does not allow inline expressions like:

display "" [
	text my-width - 3 form now/date
	text (my-width - 3) (form now/date)
]


although I'm working on adding support for the later(parenthesized) 
form. As a side note, this is a bit of a shift in my position. I 
used to be of the opinion that explicit declaration via compose was 
more efficient than implicit declaration; but it turns out to be 
less efficient in a number of ways:

	Coding: requires extensive use of compose/deep and parenthesis

 Obviousness: it's not obvious why code like "image my-image" doesn't 
 work

 Complexity: forcing use of compose/deep makes it harder to write 
 action blocks inline [that need themselves to use compose]
	Familiarity: It's not the way VID or other dialects work

 Speed: compose/deep is actually slower than reduce/only and a few 
 subsequent parenthesis reductions


You can thank Graham's comments above as the catalyst to change. 
;)

guys, those of you, working with databases - currently in new grid 
implementation, there are insert column, remove column, swap columns 
functions. Those do physically alter order in block of blocks (data) 
section. Apart from possible speed limitations, do you think it would 
be better to just virtually swap, insert (at the tail), remove (just 
make it invisible), or is it ok?

that's why I built in options to turn off updating when doing multiple 
operations. by doing that, operations can speed up tremendously.

Ashley is making the same point I am, "end user" vs. programmer (or 
tech).  Any time a programmer says "I do X all the time" all I think 
is that if "I can bottle the exact opposite of X I can make a billion 
dollars."


Hence I wrote above "The exception is when people are dumping databases, 
and those are not using formulas, but rather are for working out 
data.  This is done by programmers, not by users in general."


Never-the-less, if the goal here is the goal, which is for technical 
people to do this, we all still need a solve, which is speed to do 
it.


In Qtask we did part on the server, and part on the client.  So, 
we let you sort columns locally, but would send all the data to the 
server.  What we learned is:

The server would send down all the data.  Slow, but needed.
Then JS would arrange everything into a table.  Slow but needed.

Then JS would sort.  And we allowed 4 levels of sort… Slow, slow, 
slow, and turns out, not so needed.


It turns out that with anything more than about 20 lines it was better 
in the long run to just sort form the server side.


This is not to say this is how this will work where with Rebol.  
My point is more to the idea of playing with UI until you strike 
the right balance of speed and convenience.

keyboard navigation is however the only way to drive a gui at full 
speed .. by ignoring the gui!

and REBOL got the speed, I think, if you try Cyphres demo:

do http://www.rebol.com/view/demos/cyphre.r

And if you're really concerned about speed, this is a little faster:

to string! array/initial 5 "abc"

I'm interested to see who gets there first: The languages that try 
to graft safety and high-level features onto C (Cyclone, Vala, ...) 
or the efforts to speed up languages that already have the safety 
and high-level features.

BrianH, yes interesting question... ocaml is closing in to c if you 
want FP, Java speed-wise also but has a bigger ram usage and startup 
times I guess. but it's also hard to say "what is the high level" 
that we want. Is it Java like, is it dynamic langs, is it FP

How to read the profiles above: The first is nearly twice the speed 
of the second, but creates more temporary memory.

I know that rebol appeared to be the slowest language on debian language 
shootout , but then cheyenne is *much* faster webserver than any 
of the ones made in dynamic languages I tried (even lua). so speed 
is a relative thing it seems (like Brian says)

also when using dialects, there is often a huge speed gain, but you 
can't really code like that in most other languages.

yes, but it does not look to me like a viable way to replace a CHANGE 
X COPY/PART Y by a cycle of that kind, although I did not measure 
the speed difference, yet

A lot of the syntax features of REBOL were specifically chosen, as 
opposed to the characters used for those features in other languages:

1) To be easier to type on a US English keyboard without having to 
use the shift key as much.
2) To be physically easier to read quickly.


The first means that REBOL is easy to write quickly even though it's 
more verbose than many other languages; it's just fast to type. This 
is why we use [ ] instead of ( ) or { }, lowercase identifiers, and 
- instead of _. The second is why we use / instead of . for path 
separators, and don't make the difference between . and , that important, 
because they are difficult to tell apart without slowing down your 
reading speed, and why more spaces are required between elements 
than are required in many other languages. This makes REBOL easier 
to debug and understand.


There's a ticket for the comma issue http://issue.cc/r3/537which 
also applies to other characters, but that ticket is likely to be 
dismissed. If the ticket were accepted, REBOL would be much more 
difficult to read and debug, which would make it slower and more 
awkward to program in. Not a good tradeoff.

Marco, that is problematic, as copying face objects may destroy certain 
bindings in a face, essentially causing faces to be "entangled", 
some functions work only with the old face and some only with the 
new face. It depends on the style and how it was written. Memory, 
speed and complexity of the operation gets worse, the bigger the 
layout.


It's easier to just generate the face once, store the values and 
use GET-FACE and SET-FACE on the layout.

Henrik: well, actions need to look into a function table, but natives 
probably need to check the type. unless the code for the action/native 
is very small the speed difference is probably unnoticeable.

Some benchmarking should be done to see how much speed it is actually 
gained, while trading for clarity.

Brian, delimit function: 

- For long-term readability, I would avoid reusing 'copy as a variable. 
I suggest 'result, even if it means using another word.

- I understand with the /copy refinement you are able to get more 
speed in creating the result block, but I think I would prefer just 
letting the user copy the data before passing to delimit. This would 
give a simpler implementation, easier to read again.

I don't wish to devalue your effort in getting this version - I did 
a similar thing optimizing conjoin - made it harder to read.

Brian, I think Jaime was making the same point, as I do above, about 
speed vs clarity, with regards to /copy. Some benchmarking is needed 
comparing:

- delimit/copy data    ; <--- delimit with /copy refinement implemented
- delimit copy data    ; <--- delimit without /copy refinement

In theory, the
    pick [false-val true-val] none? option

pattern should be faster for straight value return than the pattern
    either option [true-val] [false-val]
when no evaluation is required.


I used while on purpose instead of foreach since it doesn't rebind 
the block passed to it. That should speed things up too.

speed.... MUCH faster on lookup

You can also not write your own 'do. IMO itis ok that  some things 
 are only possible at native level. Its  not  lisp.

inc/dec/shift are essential enough for speed and commodity, these 
could be an exception. (Maybe  evenn '<< and '>> as  operators, and 
allowed  in parser?)

geomol and others...  INC with lit-words is seriously flawed in actual 
use ... a: inc a  ?? what's the point of it...


lit-words are not word values they are labels, they are not usable 
unless the word exists "somewhere else"  its not THE a you are evaluating 
but AN a somewhere... which is why this is as alien to rebol as anywhere 
else.


if all series can change values "in-place" like append... why not 
allow this for scalars (and others) too?  its already an integral 
part of REBOL ... I don't see the "confusion" in   INC a   changing 
THE a... its exactly like  append a, but for another type... hell, 
I've wanted in-place editing for many things which aren't series 
and it would speed up code, just like not having to copy series all 
the time like python. 

ADD-TO a 10


when you do INC 'a  you HAVE to declare 'A somewhere else... which 
is not in rebol's philosphy.  this is completely different thinking 
to rebol... its much closer to C style... where you expect a to exist 
somewhere...    the lit word syntax, just cause a big confusion within 
the normal chain of rebol coding IMHO its not simple, and certainly 
not obvious... most newbies don't even get what a lit-word is.  just 
like SET which is used only (usually) to implement other tricks in 
the language... we shouldn't be using SET in normal code.  INC is 
not a trick word... its something I'd be using in many scripts, unlike 
SET which I seldom need to.  

just giving my view on this topic.  ;-)

The speed of datatypes comes from the fixed action list. It allows 
the dispatch to be a simple retrieval from a fixed offset into a 
function table, no lookup required. It is not the same thing as general 
class-based methods, which in a language with dynamically typed variables 
would need to do a lookup to figure out where to find the method 
to call, same as with instance-based methods.

I meant style I suppose, though even C is expression-based. The idioms 
would actually be more assembler-like than C-like, for 2-address 
instruction sets like x86. Still, this wouldn't add anything to the 
language that isn't there through other means, except speed. And 
while it wouldn't complicate the interpreter, it would complicate 
the semantics of REBOL, making it harder to explain, debug or reimplement.