AltME groups: search

Ashley: your wellcome for your consern but in fact integrating your 
new engine from MDViewer only takes my 2-3 hours ( in fact i spent 
more time like 10 hours to try to mixe both method has it wasn't 
has performant has your rendering full engine I cleared the mixed 
one and retake as it MD-Viewer engine then I adpat it to MDP standars 
) Now MDP-GUI has a super fast rendering engine like MDViewer (Ineed 
to enhance the speed of the toc window rendering that the only slowing 
remaining step). Another time what a work you made as  I trully knows 
it intimely (because of the work needed to integrate it to MDP-GUI) 
I can say that in front the previous rendering method you made really 
a ART WORK it's clear it's tiny it's easy to understand :)

ChristianE: Cyphre solved even following case - ability of menu to 
display on left or on right, depending if menu can fit the window 
or no. Ability to react for resizing (not sure about that one), but 
he used the same engine for context menu (right mouse button click). 
Otherwise - VERY good work. No problem with speed here. I will try 
tomorrow on P650, 256MB, W95 machine ...

Izkata has found a way to speed up your bug 1,000% :-)

#3885, #3895, #3896 and speed of 1.3.2 beta OK, passed all my tests

actually, it's possible that 3939 will be implemented. to-dec and 
to-int are unlikely to be used in loops, so their speed is not necessarily 
an issue.

crc-32.r with gigabytes files: [don't do it] - it works, the memory 
used isn't size relative - but on a 1GHz PIII, the speed is < 300 
kbytes/s! 
rebcode version is a lot faster (>2Mbytes/s), but 
1) rebcode isn't part of official releases 
2) the rebcode version of 'crc-32 needs whole file in memory.

so, back to RAMBO: #3650 - I vote for 'crc32 as another 'checksum/method, 

and maybe a RAMBO ticket for a port aware version of 'checksum would 
be a good idea.

speed: it's probably a bit slower (two calls to find instead of one 
to select) but i haven't done benchmarks.

yes, they still base upon what is awailable, so extending the bloat, 
praying connection to internet and speed of our devices is fast to 
work with what they deliver ....

Have any of you looked close at the MakeDoc2 formatter? It's a 2-pass 
parsing, first converting the text to rebol blocks, and then parsing 
the block(s) producing HTML code. Of course it's smart, because if 
you wanna make a parser producing e.g. PDF code, you only have to 
make a new second level parser. And there's also the problem with 
Table Of Content, which can only be completed after the first pass. 
My first approach with my NicomDoc format was to make a 1-pass parser, 
and build the TOC along the way as separate text, and then only combine 
the TOC and the rest of the document before output. Benefit with 
1-pass parsing would be speed, but downside is, that you need a new 
full parser, if you wanna make PDF code. Then again a parser going 
from some rebol block format to e.g. PDF would probably be almost 
same size as going from a text format (NicomDoc or MakeDoc) to PDF. 
hmm What about XML? Making an XML file from some rebol blocks would 
be pretty easy, same the other way. What should I do? Make a 1-pass 
or a 2-pass formatter?

I think, it'll be best for me to make a 2-pass formatter. Not optimal 
speed, but the whole task look much easier this way. And first pass 
should be a separate rebol script, which wouldn't need much change, 
only if standard changes. And then second pass scripts are made for 
each output format.

:-) There's the idea for what keys to put on the left side of the 
keyboard to make it more balanced. Well, maybe it will become too 
big!? And then use Dvorak layout (http://www.mwbrooks.com/dvorak/) 
to speed up typing.

Hi ashley !! I see your MD2IDE it seems you have open the competition 
with my MDP-GUI hahahaha. Well I like the redering window on right 
of the Window. The bad point is that the previsualisation of the 
texte is not updated until the save action. Updating it dynamicaly 
could be a good thing. There is no button to short cut the insertion 
of the balise like in MDP GUI (feel free to retake from MDP-GUI evry 
thing you need). Personnally Im waiting for the new rebol/view version 
that will speed the drawing engine and be able to use AGG based styles 
like Cyphre showed us to do. what about integrating to your product 
MD2IDE the net releasing support (for example to update quickly a 
blog based   on carl's REBOL script)

maybe with AGG cpabilities we will be able to speed rendering enought 
to produce those kind of ticky widgets

[MDP-GUI DEV NEWS ] I improved the rendering speed by 300% integrating 
the MDViewer rendering method that ASHLEY created. That new algorithm 
really rocks !!! I had to change the inline formating flags to conserv 
the most speed. I conserv the ashley way to deal with inline marcker 
has HTML tags (e.g: <b>text bold</b>) I adapt ashley's code for all 
little  other différences that exist beetwin MD2 and MDP format. 
Next step is to enhance the toc rendering process. I remade the first 
start up process. I plan to give MDP-GUI.r, make-doc.r, make-doc.txt, 
ms-word.gif, in a single ZIP archive that make easier the release 
and use. As johnatemps says to me people wants to download and use 
and not try to configure the program durring lot of time.

I've also been thinking about building a very simple application 
to let you create pdf's graphically to make the process simpler. 
of course it would be no where near a DTP application, but it would 
speed up generation of more complex stuff

my plan is to eventually add a "simple" text mode for use when you 
care for speed instead of quality.

It's a speed optimization. This might change with REBOL 3.

speed or memory ..

Didn't want to sound "dramatic", but just wanted to provide a more 
accurate measure. Sure whatever datatype is used (char! or string!) 
in regex.r, that won't  change much the overall speed. ;-)

If you want to test the speed of parse, replace the any-type! with 
a skip - the forall you are comparing it to doesn't do that test.

it's not very readable indeed. but i was going for speed ;)

Btw, I've released an alpha version of a new MySQL driver implementation 
: complete rewrite from scratch to be fully async under UniServe, 
 optimized decoding in speed (faster code, streaming decoding, etc...), 
supports only servers v5+. You'll find it in the latest UniServe 
archive (see UniServe group for link)

MySQL driver release v.1.1.2 Download at : http://rebol.softinnov.org/mysql

- Fix for an infinite loop issue when the server times out the connection 
(unix platforms).

- TCP keepalive option activated by default (for longstanding idle 
connections).

- Send-cmd function optimized to be a little bit faster and use less 
memory.
- Added new-lines markers to resulting recorsets.

- Added option to switch on/off new-lines marker through port/locals/newlines? 
flag.

- Recycle call removed from read-rows function. Should speed up the 
results a little bit.
- Minor source code cleanup.

about escaping, Nenad's driver has such functions already, so i don't 
see that as an advantage for the native driver. Qtask has a native 
driver too (for speed reason with large record sets), but remember 
that when you use the mysql c library either your app has to be GPL 
or you need a license from MySQL (Qtask has a license).

No, not really...

One table would be much easier and I do not think the db would get 
so large that I would see major performance problems. (I always underestimate 
the speed of these db's.)

Thanks for the advice, Sunanda.

speed & ease of use are very important. Perhaps splitting interface 
into a low level speed way, and the high level easy way would be 
the wisest decision. Matrix is cool, but its not obvious to use to 
those that have yet worked on that level.

maybe kind of caching could be introduced to speed things, not needing 
to parse template with each request ...

I'll go back to IE and tighten down security before I go back to 
Mozzila simply because of the speed issue but before I ever go back 
to IE there are plenty of Mozz spin offs that don't share Mozz's 
bloat

Yes,  we took them out. REBOL ran a lot faster as a result.  I used 
to be a huge fan of continuations 20 years ago. But, continuations 
do not provide enough benefit for the performance hit on evaluation 
speed and memory usage.  (Stop and think about what is required internally 
to hold in an object for any period of time the entire state of evaluation.) 
 It's more of a programmer play toy than a useful extension.

Some of them are just bad -- ban them with a robots.txt


Some (like MSNbot) will respond to the (non-standard) crawl-delay 
in robots.txt: that at least keeps them coming at a reasonable speed.


Some are just evil and you need to ban their IP address by other 
means...Like flood control or .htaccess

REBOLorg has a fairly useful robots.txt
http://www.rebol.org/robots.txt

as for JS, I am not sure it is fast enough. I saw Sun's JS based 
desktop, and it was joke compared to even VID 1 alpha speed probably 
:-)

Improved IHM, improved redering speed...

robert the problem you see with selected line and sort is because 
to speed the sorting process I change the widget field (text, data, 
image) content and so they conserv there index. What I need to do 
to not loose perf is to change the actual color seek the picked content 
and pass to the select-line function the new index ;)

and ofcourse conserving a good process speed :)

Oh, I hate that. Even worse, most of the time you can speed up the 
process of selecting from a dropdown by typing the first letter of 
your selection, but all of the time zone selections start with ( 
so that speedup doesn't work with them.

gains speed. have a look on how much your os spends to file-buffering 
in comparison.

... which I thought should speed it up and make it easier to iterate 
in a list.

usually speed.

speed and bw is a matter of the codec you choose H.264 is very high 
quality and very ligth. So much that it is used and become the standard 
for mobile cell phones.

I doubt is a cpu speed thing. Is must be bw, probably on my end. 
I have over 300+ remote units sending pkts to my server every 30 
secs. I am planning ot buy more bw but I have been lazy ...

what i like with shoutcast is the speed of connections

And it adds a lot of value to speed-up development time for applications.

But how about a three-state if too? lesser/equal/higher 0? Could 
speed up binary search and such?

simply what I wanted to ask - if that is normal with such VMs in 
other languages or we simply do allow such crashes because of various 
reasons (e.g. preferring speed, not doing checks etc.)

A SIGN opcode would set a word to the integer -1, 0 or 1 depending 
on whether an argument is less than, equal to, or greater than 0.


sign: ["Set variable to the sign of a value (-1,0,1)" word! word!]


It would be preferable to have SIGN work with all numeric arguments, 
but you might choose to implement this as sign.i and sign.d for speed 
- either way is fine by me. The SIGN opcode, when combined with BRAB, 
would enable functionality equivalent to the BRAS proposal (#3948), 
and so would supercede it. There are many other uses as well.

how do you tell the speed difference? I can't see it....

how great is the speed difference?

I rewrote my old 3d demo to rebcode to see the speed difference. 
But I found that normal rebol can draw 120+ triangles without slowing 
down and because I became bored adding more objects I stopped testing 
it :) Anyway, rebcode optimalised (just three or four functions - 
matrix multiplication, inversion and 3d to 2d conversion - are rewritten 
to rebcode, it can be optimalized more) version is here - http://krutek.info/rebol/ratrix.r
. z-buffer does not work very well as you can see.

To make objects move faster you can just change their speed, it's 
not rebol vs. rebcode thing :)

rebol limitation may show but it won't be rebol math speed limitation 
but rebol face refresh speed limitation :)

not necessarily - you don't have to refresh more than 24/sec, yet 
rebol math speed may become limiting factor, depending upon how complex 
your scene is .... but - I am not here to argue with you about single 
details, just wanted to see those two versions compared, that is 
all ...

Pekr as I said, here on this computer, classic rebol is capable of 
updating more than 120 trinagles at full speed (rate: 0) without 
problem. And after 120 triangles I became bored adding more so I 
did not test it :)

As I'm interested only in pure vectors, REBOL speed is succifient 
for me :)) But yes, REBOL can probably be linked to some external 
library (as Cyphre did with OpenGL) or SDL maybe? But I don't think 
it should be high on priority list, other things are more important.

But I think the accuracy is fine if you are doing animations and 
effects based on atan2 function - where speed is more important than 
precision

How many RHz do you get with: http://www.rebol.com/speed.r

Nice job, John!


I have played with it a bit : the keys were not friendly for Azerty 
keyboards ;-)
And I wanted it to fly without "Control".


So the same things, but use Arrows to increase/decrease speed in 
both directions.
do http://membres.lycos.fr/didec/rebol/NicomVoxel.r


You can also try page up/down to change the view altitude, but rebcode 
part is not fully ready for that (can give error if you go too far).

They would be really usefull for editing faces,and other object-based 
REBOL resources... if they are in opcodes, we could expect a big 
speed improvement, even if that meant to "freeze" some aspects of 
the object within the rebocode loop. (JIT compile on demand  ;-)

yes speed did often seem to be in the 30-100 times faster!

if we also could have direct access to the buffer that is used for 
outputs so we can skip the View engine, but throw pixels directly 
on screen, even more speed can be gained.

i need a speed reverse byte function with rebcode , for example 1100 
0000 => 000 0011
any idea ?

Have you tried it with APPLY IN and such? How is the speed compared 
to REBOL?

I have not yet done any rebcode tests with liquid, as so far, its 
always interactive enough, so as to not require it... but I am going 
nuts with the engine  ;-)  liquidator is a testament to its stability 
and another user here is helping me push the enveloppe to  :-)


but obviously, It will come to a point where pure processing will 
be needed and in such a case, speed will always be a factor.

can i disactivate the label parsing/replacecing to gain speed when 
i build rebcode functions

but i build many many rebcode functions in real time, i need speed

It really doesn't gain you much speed. The label fixups are done 
once, at rebcode function creation time. After that it just calls 
the offsets - the label statement is a noop. I only do straight offsets 
when generating code (like you are). Be careful though, as the offsets 
are calculated from the end of the branch statement, not the beginning.

You can improve the overall speed elsewhere by combining strings 
of operations between writes to memory.

No, you can do it. The main reason that you have to branch back to 
the beginning of your interpreter at every step is because the next 
step might have been modified by the previous. You can speed that 
up though, by realizing that the only statements that really need 
that paranoia are memory writes and branches - other opcodes can 
by combined in your interpreter, like looking more than one move 
ahead in chess.

I ran it through remote desktop on Windows via OSX. speed was a little 
slow, but ok

speed improvement of http://perso.orange.fr/rebol/galaga.r

all video routines have been translated into rebcode, but it' s not 
so fast than in my dreams.

- Added a button to switch Draw randering between bilinear and nearest

you can use varchar even for indexes, it should speed up things significantly 
...

Maybe my test settings are different from your  requirements.

During testing I let two concurrent processes insert a record with 
three fields, one ip address, a timestamp and one text field with 
variable length from 1k to 8k., and this i do with full speed

Janko - I did small test for you. With no indices the speed was: 
0:00:00.516 and I used LIKE expressions, which need to do searches 
in terms of field values .... 

REBOL []

print "Starting test for Janko ..."

do %sqlite.r

attempt [delete %janko.db]

connect/direct/create %janko.db

sql {
CREATE TABLE [domains] (
[id] INTEGER  NOT NULL PRIMARY KEY,
[domain] VARCHAR  NOT NULL,
[user] VARCHAR  NOT NULL,
[processed] DATETIME  NULL,
[ok_count] INT NOT NULL DEFAULT 0,
[fail_count] INT NOT NULL DEFAULT 0,
[error] TEXT NULL
)

}

sql "BEGIN"

for i 1 1000 1 [

 sql reduce ["insert into domains values(?,?,?,?,?,?,?)" i i i i i 
 i i]
]

sql "COMMIT"

start: now/time/precise


sql {update domains set user = 'u3' where domain like '%1%' and user 
like '%1%'}

print now/time/precise - start

disconnect %janko.db

halt

What is the speed of this compared to using closure (with the extra 
block):
o: context [a: 2 * pi f: closure [x] [(sine/radians x) / a]]
And then call it by: o/f 1

Isn't the conclusion then, that closure doesn't need the extra block? 
It's possible to have the speed without, and the extra block will 
complicate the syntax.

I feel that you are asking whether we can use closures in Rebol2 
version too. The answer is "yes", see my implementation of CLOSURE. 
OTOH, this should be implemented natively, because there will be 
a noticeable speed difference.

the problem is not with incompatibilities but with the speed, Carl 
is afraid, that the speed difference will be too big to get rid of 
FUNC

maybe 2 cent of mine:

to me it looks pretty confusing, reading all the above - if I get 
the intention right I would separate it like this

1) how to (or do we want) initialization - no matter if with closures 
or just normal rebol funcs

2) how will closures be in rebol3, by default (breaks a lot as Ladislav 
told) or not
3) the static thing Ladislav began with

@ 1) 

- to me this doesn't belong to the whole closure discussion (if it 
deeply does I don't get right now why) 

- one possibility would be to add an refinement to func or closure 
also - no? - makes the order of the optional third block a bit awkward, 
but on the other side that's what refinements are for - no ?

@ 2)

- we should have closures and propagate them as the default version 
for normal people or newcomers if rebol3 is out - they are safer 
IMO and don't make too much trouble with unexpected effects, especially 
for people from other languages (especially from the current dynamic 
kind)
- so closure should be separate

- with hopefully more asynch behavior by default build in, in rebol3, 
closures are anyway a must 

- if somebody got the concept of normal funcs - people can use it 
for speed reasons easily

- from Gabriele or Ladislav (or somebody else) it sounded a bit like 
one of the thoughts around closures involved the binding capabilities 
- I don't overlook this right now, but it still would be possible 
to change funcs like today, wouldn't it ? I mean there might be something 
like changing a function or rebinding it's body (or parts of it) 
can cause problems if local vars of a closure should be protected 
by this - on the other side who would do this, who doesn't know what 
he does ?


@ 3) maybe some of the static capabilities would be nice to have 
for closures then too, don't know - right now it's easy to build 
- how would it be done (in the language) with closures ?

And just some questions:

what function attributes will be added ? and what will they do, what 
purpose for .... :-)

will they be kind of dynamic or user extendable - so that own attributes 
could be defined - even if not too useful with rebol in some sense 
(or maybe it is - i'm not sure) - so some design by contract could 
be added without hacks for some needs (just mean it as an example)

will function get more similar to objects/contexts (or the other 
way around) - I mean that the concepts get closer ?

In java i got 2.5* - 1* the speed of rebol in a little POC. I guess 
 a full implementation will loose a bit, but could be more or less 
on par.

Rebolinth - the speed of blog is ok, what I wonder though is, how 
fast rebol 3 development can go, if there is so many ideas floating 
around :-)

cgi-servers can handle this to some extend, but cgi is cgi and not 
chat-speed.

would allow us to implement specific mechanisms very quickly and 
gauge memory useage tradeoffs vs speed depeding on application.

weren't they removed for 2.0 because of speed aspects?

yes, but that was not the only speed problem in r1

and, speed is the reason why you have both function!s and closure!s 
in r3

I guess shortcut-things and a little speed. and i made a mistake, 
my example must be
 f: closure[/local ta sl]

I have not been watching this very close, so to get me up to speed....you 
are writing an emitter from Rebol to PS?

it's a problem for speed, but perhaps there really is no way around 
it

perhaps it's equal in speed, I don't know. odd though, I can't see 
what's so slow about that code, other than the newline insertion 
thing

I have worked for many weeks on the problem and it's unsolvable, 
so I went to Ghostscript instead, but I'm unhappy with its speed.

RE: "How does Cheyenne's performance and security stack up against 
the other indians (Apache, Cherrokee, Hiawatha, ...)?"


Speed: close to Apache2.x for static files (tested a year ago, so 
new tests need to be conducted).


Security: not chroot-ed and no special protection against ddos attacks 
like Hiawatha, no bandwidth throttling (could be added), no CGI time 
limit (could be added), passes Nikto generic security tests flawlessly 
(last time check : few months ago)

Marteen, about your questions, there's currently several web sites 
running with several months uptime. Cheyenne is quite resistant to 
all classic web attacks (tested with the Nikto package). About speed 
and performances, I've done a few test a year ago but a lot of things 
changed since, so I need to do some new benchmarking (anyone tried 
with Apache's ab tool ?)

btw, I stoppend months ago monitoring production Cheyenne servers 
as they just work flowlessly and at great speed ! Dock rules ! 8)

high speed dialects? What is that?

Carl said something about a framework(?) for implementing high speed 
dialects, which he developed for rebcode (?)

What line speed do you have Anton? I'm on 1.5MB (ADSL) here.

(long story.............) but we can do speed boat rides.

That's it. As always: Speed or Space.

so you can read and trash all nodes, at disk speed, so its very efficient 
actually.

Good to understand your logic.

OK, then may I suggest then:


-	Left click - plays card (you should put this to a vote)

-	Right click examines card (since this is how every OS is designed).

But also:

Leave about 20 pixels below the cards.

When you move your mouse over a card, that space shows the word "Details" 
or "more"

You can discard from the details view of the card.


Unless the game is a trigger game, or speed is required, sticking 
to just simple left button to do most things is the best way to go.


Of course, until I learn the actual point of this game (the rules) 
and "feel" the cadence of the game, it is hard to tell.

I can imagine using Cyphre's JIT compiler to speed it up :-)