AltME groups: search

guys, don't you  know any application, which would be able to generate 
traffic? I want to install two Mikrotik routers in Dual Nstreme mode, 
and I would like to test real-life thoughput. Copying one big file 
amongst two ends is interesting test for line stability, but there 
is a difference if you run one connection, or few hundreds ones ...

I just should generate 1000 opened connections and try to send random 
data ....

ie. I used Rebol to generate the postscript graphs

what I want to do is feed date data and let the graph program automatically 
generate the x-axis labels.

Anyone have a source for some code that is supposed to generate prime 
numbers?  I'm curious what the standard formulas are for that.

i can generate strings by default each time there are errors by default, 
so that there is no need to provide rules.
It's a tiny modification

give me a dll wich accept a binary stream and run it as a function 
and i'm ok to generate assembler with rebol

Hi, syntax question: 

i want to insert a row into a mysql db:

string-block: [ "value1" "value2"
insert db [  "insert into table values (?,?)" string-block ]


this fails (string-block is not evaluated i guess), but i dont know 
how to generate the following

insert db [  "insert into table values (?,?)" "value1" "value2" ]

(which works) using rejoin, remold, join, .. whatever.

no, rebpro I placed on server .... as I needed library access, but 
this time it does not contain decode-cgi, uh, I will have to generate 
my own rebol.exe with features I want?

Do you mean using it to generate file names that will be acceptable 
on any platform that REBOL runs on?
If so, I don't know, but I wouldn't take the risk.....

....I use checksum/secure and remove #{} part -- gets me a file name 
that is just letters (a-f) and digits.

I use the empty paren to generate an unset! value. Compose then dissolves 
a false condition to nothing.

Not really. MOLD is used as a way to generate script source (which 
would be loaded with DO); MOLD/ALL is for data (which would be loaded 
with LOAD). Both have their strengths, so there has been no talk 
of removing one or the other.

I don't know where to put this question exactly but has anyone created 
any code to generate an Outlook appointment request?

I did some MAPI test R&D a long time back, though I think I wrapped 
it in a DLL to call from REBOL. 

Can you generate an iCal %.ICS file and do it that way?

I mean, the biggest problem I saw in SKIP+ was that start parameter. 
By using a seperate index you are just asking for out-of-bounds errors. 
Remember, series references include a position - you can just generate 
another series reference in the new position by using AT.

The only difference between SKIP+ and EXTRACT related to bounds checking 
is that you can generate out-of-bounds references with SKIP+ using 
the start parameter, where with EXTRACT you would not be able to.

You aren't doing anything in the inner code that could generate an 
error, so no need.

We take several steps in various bits of REBOL.org system code to 
produce unique identifiers.

The code factors in not just now/time/precise but also things like:
-- user name
-- length? mold system
-- incoming IP address

But, ultimately, you cannot *guarantee* not to get an id clash that 
way. So (in cases where clashes matter), we also create a temporary 
file, id.tmp .... If that already exists, we generate a fresh id 
until we  get a unique one.   In the case of REBOL.org, the id.tmp 
files are deleted weekly, as a week old clash is not important.

Generate pools of passwords, and store a counter to use when you 
need to re-seed and generate a new pool. That way you can generate 
them over a long period of time and just pull them as necessary.

what happens if no random/seed is used in a REBOL program?


That same thing that happens with almost all random generators, which 
is a pattern is used.  REBOL has a starting seed value (unknown with 
out extensive testing).  However, it will (and should) have the same 
value upon start up.

The problem (you are perceiving) is with the word "RANDOM" 

Perhaps it should be called PATTERN instead.  


However, if seeded, RANDOM in turn will use a formula to generate 
more in the series.  This is indeed true random, in as much as the 
seed's size sets the size of the universe.


So, if you want to always have a random set, you need to get fresh 
random data (hmmm, I seem to recall mentioning this in another thread).


Of note, the RANDOM we use in slot machines is NOT like REBOL's random 
function.


REBOL's RANDOM (like most language random functions) is really SEED+OFFSET 
in a series. (thus a pattern).


I'm not sure what Carl did to make it secure, but my best guess is 
he is sucking in what ever he can find to make it Random (this doing 
what I'm suggesting in the first place).


For example, reading the mouse port, temperature, current time (to 
the jiffy), etc.  This would make RANDOM what you expected it to 
be in the first place…but in theory this would be slower.  In your 
case,  this would be the way to go.

random/seed now/time/precise followed by an indeterminate number 
of
   random/secure to-decimal now/time/precise
or a few waits
will make it harder for anyone trying to guess your passwords.


But none of that guarantees you won't produce a random number you 
already have. If you need your passwords to be unique, you need to 
do one of several things:

-- check each one against all previously issued (as I've suggested)
-- generate a unique pool in advance (as Gregg suggests)


Both approaches introduce a potential security flaw: the table/pool 
of passwords is an attack point for a hacker.

Given a good algorithm (like Mersenne twister), and a true random 
generator for seeding (like hardware sensors) a computer could cover 
the 60**8 range. A humain brain, even given enough time, can't (I'm 
talking about generating random combinations, not using loops to 
generate every single combination). Even worse, humain results would 
show heterogeneous distribution of results, while computer will give 
a uniform distribution. So in that case, computers would give you 
better randomness than analog brains.

You can sort of trick your way around things with ops in most cases. 
e.g.

	>> fn: func ['op a b] [op: get op  op a b]
	>> fn < 1 2
	== true


But I avoid doing that. It ends up not being worth it, IMO, when 
you start to reuse things, generate code, etc. Just use func alternatives.

the send/attach can generate the multipart components for you.

So generate all of your names in quotes.

The only way is to generate a stupid long ID to reduce the likelihood 
of a duplicate by a factor of... astronomical.

Generate a random id, then check if is not already issued. If it 
is, try again.
That works for me!

(Though there is the remote risk that my code starts getting slower 
aftre many thousand years of continuous operation, when clashes start 
becoming likely :-)

to generate IDs, I do a nasty infalable trick on mysql.  i insert 
directly, in a uid table.

I'm on 2.7.6 os x , symtom is rebol just goes mad using up 100% CPU 
and never quits , using "ktrace -p processid" generate an empty ktrace.out

More backports: AJOIN

ajoin: func [
    "Joins a block of values into a new string."
    block [block!]
] [
    head insert copy "" reduce block
]


AJOIN is native in R3 and doesn't generate an intermediate block 
(it reduces in place), but even in R2 it has advantages:

- It always returns a string, no matter what the type of the first 
value in the block is.
- It is faster than REJOIN.

Why you do not make your template just an unevaluated block and then 
you always generate a new object or you never change your template, 
just the descendants ?

There are ASCII? and LATIN1? functions that test, char!, string!, 
binary! and integer! in exactly the same way as the R3 natives, and 
a UTF? function that tests the BOM. When ENCODE and DECODE are written 
in R3, I'll backport them too if I can, though they probably won't 
generate string! values.

You have a good point about the nforeach reduce thing, but I am not 
convinced that giving up the ability to generate the data in other 
functions is worth it. I usually don't like to see DO/next in mezzanine 
code anyway: DO/next is usually a sign of a function that doesn't 
work in a REBOL-like way and has too much overhead to use. However, 
I still want Carl to fix DO/next in R3 - it doesn't work at all at 
the moment, and there are some proposed functions that can't be implemented 
without it.

I was already thinking a little that you probably don't really need 
them since you can change/generate code structures at startup or 
"JIT" and "cache" them ... but it was just a hunch.. not something 
I could imagine all the way down ...

I was thinking yes that cheyenne has to do something like this , 
but very efficiently since it has multiple worker processes to generate 
responses

anyone know of a way to get a persistent value based on someone's 
computer... the longer the string the better... (on windows)

this is with a /command license, so any accessible rebol feature 
is usable.

something like:
    -System install serial number
    -Disk serial number
    -CPU id


I want to generate an encryption key which isn't stored as part of 
the code.  It just makes it a bit more complicated to reverse engineer 
the stored password if the encryption key is different for all installations.

Thanks Sunanda, Steeve - I had a loop to generate it manually, but 
an enbase/debase-based solution is far faster  ;)

Pavel, yes it is. But you can say that binary! is subset of vector! 
- 8bit unsigned vector. With vector! You can generate for example 
16bit signed stream and then just add WAV/AIFF header. So vector! 
is superior to binary! from this point of view.

Thinking out loud is good. 


I've used them in the past, and sometimes they make things look a 
*lot* nicer. Other times they end up being a pain, especially when 
you're generating code. That is, you want to generate the arg dynamically.

ok, not thoroghly tested but:

set-faces: func [faces data] [
  set

    reduce foreach var faces [insert tail [] compose [in (var) 'text]]
    get data
  show faces
]

view layout [a: field b: field c: field d: field]
faces: copy [a b c d] ; generate this from the layout?

data: make object! [a: "Eeny" b: "Meeny" c: "Miney" d: "Mo"]

set-faces data faces ; whammo!

I could do that, but I need to generate it...

I have a question about the matrix functions in Draw.  Is it true 
they can only be applied to an existing draw sequence?  that is ,I 
am creating novel points to insert into a polyline that is yet to 
be drawn, it seems I cant  use the matrix functions to generate these 
points.

No.

But I used to be a fan of allclear -- they devised a very simple 
text-based dialect from which they can generate numerous diagrams.
http://www.allclearonline.com
It could probably be re-engineered in REBOL in a few weeks :-)

are there good articles on memory conservation anywhere? I noticed 
that some times memory usage for LIST-VIEW skyrockets, especially 
when using TO-IMAGE on list columns to generate bitmaps. that is 
not good.

REBOL [
	Title: "REBOL Logo Maker"
	Purpose: "Generate a Hilight image"
	Author: ["Carl Sassenrath" "Gabriele Santilli"]
	Version: 1.0.0

 Rights: "REBOL logo is a registered trademark of REBOL Technologies, 
 USA."
]

debug?: false
hilight-colour: 255.0.0 ;0.112.99	;request-color
character: uppercase request-text
font-type: "font-sans-serif"
xthin-chars: charset "I!J"
thin-chars: charset "1234567890ABDEFPRSZ"
normal-chars: charset"CGHKLNOTUVXY"
wide-chars: charset "WMQ"
xwide-chars: charset ""
special-chars: charset "*"

if font-type = "font-serif"[
;get-char: func [character][

 if find character xthin-chars 	[if debug? [print "xthin"] char-offset: 
 8x2 char-size: 14]

 if find character thin-chars 	[if debug? [print "thin"] char-offset: 
 7x2 char-size: 14]

 if find character normal-chars	[if debug? [print "normal"] char-offset: 
 6x2 char-size: 14]

 if find character wide-chars	[if debug? [print "wide"] char-offset: 
 5x2 char-size: 14]

 if find character xwide-chars	[if debug? [print "xwide"] char-offset: 
 4x2 char-size: 14]

 if find character special-chars	[if debug? [print "special"] char-offset: 
 5x-2 char-size: 28]
;]
]
if font-type = "font-sans-serif"[
;get-char: func [character][

 if find character xthin-chars 	[if debug? [print "xthin"] char-offset: 
 9x2 char-size: 14]

 if find character thin-chars 	[if debug? [print "thin"] char-offset: 
 7x2 char-size: 14]

 if find character normal-chars	[if debug? [print "normal"] char-offset: 
 6x2 char-size: 14]

 if find character wide-chars	[if debug? [print "wide"] char-offset: 
 5x2 char-size: 14]

 if find character xwide-chars	[if debug? [print "xwide"] char-offset: 
 4x2 char-size: 14]

 if find character special-chars	[if debug? [print "special"] char-offset: 
 4x-2 char-size: 26]
;]
]



font-style: make face/font [style: 'bold  name: font-type  size: 
char-size]

hilights: [
	transform 0 1 1 0x0 0x0
	fill-pen snow pen snow
	circle 10x10 9
	fill-pen black pen black
	circle 13x13 9
	fill-pen hilight-colour	;0.112.99
	pen hilight-colour	;serve dark green - 0.112.99
	circle 11x11 9
	fill-pen white pen white
	font font-style
	text 1 char-offset character 
		;]
	;]
]



insert-event-func func [face evt][
	if evt/type = 'resize [
		bx/size: out/size: evt/offset
		bx/size/y: out/size/y: evt/offset/x / 23 * 23
		n: to-decimal bx/size/x / 23
		;t-x: to-decimal bx/size/x / 23 + 5
		;t-y: to-decimal bx/size/y / 23 - 2
;		probe highlights ;logo-shape
;		halt
		hilights/3: n
		hilights/4: n
		loc: to-pair :t-x :t-y
		show out
	]
	evt
]


view/options center-face out: layout [
	origin 0

 bx: box 23x23 green effect [draw hilights effect [key: green]][  
  ;logo-shape][	; 

  file: request-file/only/save/file join %hilight- [character ".png"]
		if not file [exit]
		if not find file ".png" [append file ".png"]
		save/png file to-image bx
	]
][resize]

in any case, a way to automate this is pretty easy IMHO. just do 
drawing and measure the amount of pixels which overlap wrt previously 
defined recurring shapes.  generate a view app which shows the highest 
matches in order and then a simple yes/no to confirm.

Oh, then maybe I have to restart View to have it generate the new 
index.r (in local folders)

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

...to to-postscript to generate multiple pages in one go.

and then i generate a single page of postscript from all the layouts

LIST doesn't iterate styles that need state (IIRC). I would generate 
the layout dynamically and put the whole thing into a scrolling pane, 
unless that ends up being too slow or memory intensive.

I've looked at the solution for a bit, and I don't think it's flexible 
enough.


I would rather leave the event handling system untouched and then 
in the window-feel specify that we need to do something after the 
engage. Then there would be another event handler, which handles 
events generated by the original 'detect. Is it possible to generate 
events inside the detect, that can be handled by the window-feel 
after the engage?


The problem would otherwise be that the event needs to be handled 
in every single engage function (dozens).

It's all the "meat" that comes after using the dialect to generate 
the face tree. There just isn't enough functions to manipulate the 
face tree. VID is almost a misnomer in this sense, because the dialect 
only performs the very first part of controlling the UI. The rest 
is up to the meat.

Presumably in a completed GUI we wouldn't need to generate anything 
on the fly

game engines use this simple system.


-create very transparent images with a gaussian fall off.  actually 
give the prefered shape to your image... so if you want a triangle-like 
flame, generate a smooth triangle with alpha/color falloff.

-create a block which will store a list of pairs, each one holds 
the position of a single "particle"

by interactive I mean will this be rendered or running live?


with a rendered system you can crank up the particle count and just 
pregenerate the whole data set as a series of images.  then when 
you need to see it, just cycle the image of a face.


usually, people use a few particles for preview... then generate 
"flipbooks" which are just rendered images and include thousands 
of particles with their alpha channel density reduced to practically 
nothing (like 2% visibility)  this generates very pretty effects, 
but at a cost of rendering time.

you can't generate events in normal view R2.

I of course use other programming laguages for my work. REBOL is 
mostly useful as a helper for me.

I use it to generate data, parse big files to extract something, 
automated FTP/HTTP/EMAIL jobs, small GUI applications.

I didnt realise you could see the data stored by using SOURCE that 
is good.  I have pretty much changed it all together based on the 
extra information, so thanks.  Is this better or worse?  It is smaller, 
but it does more maths, but avoids the need to sort.
;; Generate all IPv4 dotted decimal masks
allMasks: has [t i allMasks][
	allMasks: [255.255.255.255] t: 255.255.255.255
	if allMasks = [255.255.255.255] [
		for count1 4 1 ( - 1) [ 
			for count 1 8 1 [
				i: to-integer power 2 count	
				t: poke t count1 (255 - (i - 1)) 
				insert tail allMasks t
			]
		]
	] allmasks
]

Hey Fork, what tool did you use to generate the isometric images? 
 Or what technique?

Then there's ascii char 160, which you can generate in rebol with 
to-char 160. I think they call it a 'hard space' or something.

Gregg, thanks!. Please the pointer on  how to generate the html file 
from *.RDML, is through make-doc?

LIST-VIEW uses the LAYOUT keyword to generate row faces at least 
for edit fields, possibly other places (don't have the source right 
here). Try adding:

vid 60x40 data [list-view with [data: [a b c] editable?: true]]

and double click to edit

I'm experimenting a little now, but with multiple resizable panels, 
I think it might be easier to generate layouts on the fly rather 
than keep a static layout that one updates various fields.

Shouldn't be ... both display and layout just generate a bunch of 
view faces at the end of the day. If it's really an issue you can 
always call system/words/layout from within RebGUI for those layouts 
that must be VID generated.

Tree is not a fully developed widget, so the easiest way of modifying 
it is to dynamically generate the spec. For example:

	blk: copy []
	append blk ["Pets" ["Cat" "Dog"] "Numbers" [1 2 3]]
	display "Test" compose/only [tree data (blk)]

Brett, I also grokked Gregg's "turtle" hunting metaphor.  Already 
I have filled more than a page of inspirations from it.  Here is 
a sampling of  my found design patterns, mostly in REBOL which are 
powerful "turtles" which are concrete examples of what Gregg said:


1. View console where a user can type VID/View lines, and hit return 
to see what they do.

2. Using print statements to the console from a View script to understand 
it (so easy to do protytping)

3. Parts of layout.r IDE with Nubs, and you generate scripts (which 
are human readible) from the GUI.
4. The source and help systems built-in to REBOL

5. Arexx for Inter-App-Messaging (I listened intently to Gab's Reb/Services 
talk saying "Arexx of the X-Internet")
6. awk file parsing. (I know Gregg wrote rawk.r a while back)

... "Turtle hunting" challenges us to develop more of these.

otherwise, zip or tar are ok for me (but i need to generate the thumbs 
manually)

Perosnally, I'm not convinced by these brain shrinking theories. 
I quote from Tony Buzan (The Mind Mapping Man) :


Recent research has shown that in a normal, healthy brain (that is, 
one in a healthy, aerobically fit body in which the brain is used 
well) there is no apparent loss of brain cells; only a growth in 
the interconnections, and therefore multiple intelligences of  that 
brain!


As the 20th Century ended, biologists at Princeton University came 
up witht the discovery ... that parts of the human brain can generate 
thousands of new brain cells, everyday


I can't find the original scientific reference - Google only guided 
me to http://biology.about.com/library/weekly/aa102199.htm

That's the point...and with R3 crosplatform tools I(or any Reboler) 
could generate hundreds of such apps with minimal effort.

I'm not sure what the maximum output from the Rossi process can be, 
but from what I've been reading it can actually produce much higher 
output than what is planned for the initial plant. For now, it is 
being limited it in order to have it operate in a safe range. The 
demonstration done in January showed about 12-15kW. It seems it can 
be self sustaining, but that might come after the theory behind the 
process is understood. As it is, it is a controllable process that 
can generate a known amount of energy given a set of operating parameters.

OK, I will ask the other way? How would you trust I am me? (or how 
to write it in english), if not to trust some third party = CA? IIRC 
Carl or Josh said, that new SDK (dunno if it was ment generally, 
or only for plug-in), could generate some special license key or 
certificate for me, so that users could check? Similar aproach as 
when you install driver and you have the ability to check, if it 
comes from trusted party. That was all my point why I asked if it 
is coming.

now as REBOL will be there in form of both DLL and .so, we could 
try to "merge" rebol with some technology, to see how it works out. 
Then you could create specific dialects, which could help programmers/users 
life easier. Such a dialect would generate target code ...

so, if we don't wrap upon OS specific printing support imo, then 
we already have our solution - generate html, pdf, postscript, but 
always - do the work twice ...

so, as for me, I would maybe prefer PS too, otoh, from the practical 
pov, I would maybe prefer PDF, because I can generate .pdf file, 
and send it to others too ....

I had something different in mind - simply when you want to prepare 
and send electronic files for your customers, at least for me pdf 
is de-facto standard. So by having ability to generate pdf, I have 
two works done in one way. Of course there is that Adobe Reader dependency, 
but .... however, I understand your case ...

right now I'm stuck in a mix of GS, Printfile and using postscript.r 
to generate printable output.

So, it sounds as though we might be able to generate html as well 
...

the layout engine can with the use of styles generate a flash or 
javascript gui ??

When I work in other languages, I generate the code using REBOL half 
the time.

The greatest killer app the world has ever seen could very well be 
built using Rebol, which would generate a massive following overnight. 
However, the killer app itself will be about an idea.. not something 
special Rebol offers, or any other language for that matter. When 
it boils down, all languages are pretty much the same. It becomes 
a religious thing and a preference.  There's a strong tendency in 
this biz for developers to stick with what they know, even if the 
alternative is 'better' (whatever that means)

Nobody is going to learn Rebol so they can generate Javascript code.. 
and Javascript -> Rebol seems odd. 

I would rather see Rebol -> C or especially Objective C.. then you 
could export to iPhone. 


I played around with Jiggy for my jail broke iPhone.. which lets 
you use javascript to write iPhone apps.. works well. 
http://www.jiggyapp.com/

I already used Rebol -> ECMAScript (at least to generate data (mainly 
nasted arrays)) to skip a need to write something like XML parser 
on the client side, how most people do now:)

Terry, I am not going to learn REBOL to generate JavaScript code. 
I already know REBOL. I already have to generate JavaScript code, 
for my job at the very least. As for a REBOL-hosted JavaScript runtime, 
that is likely to be just a useful side effect.

And what I learn can be adapted to other targets, including C, in 
theory. Though C is a poor choice for generating iPhone apps - it 
would be better to generate LLVM code directly, as it has a better 
semantic model than C.

You would have to make a subset of REBOL a library that is statically 
linked to other applications, and that subset could not include any 
of the DO dialect functions. You could generate those applications 
using Mac-hosted standard REBOL code though.

Status:


- Asset management is a big question. There are design questions 
to solve with regards to loading and unloading assets to make it 
easy to switch skins. Carl has mentioned the three skinning layers 
in his blog post.

- I proposed a method to specify lists of materials in a very simple 
way like FONTIZE and Carl liked it, but it's not yet implemented. 
This is inspired by what 3D modeler software does to manage materials, 
rather than what other GUI engines do. It's much more formal.

- I proposed a method to generate materials for gradients in styles 
in a very simple way. Carl liked it. This is halfway implemented.

- There's a function to generate a gradient from a description in 
a compact way and then apply a function to it to create a real adjustable 
specular highlight. This means you don't have to work with a big 
set of tuples in a block to create a good gradient. You can see that 
in action here: http://rebol.hmkdesign.dk/files/r3/gui/026.png

- Carl is working on panels and groups. We're building small apps 
to try to reveal bugs in the layout engine.

- Panels has a bug that cause cells to overlap when resizing. This 
is not evident in my screenshots though. 

- Resizing with refresh bug has not yet been fixed and you may see 
it sneaking in, in some of my screenshots.

- Text handling (cursor movement, selecting, etc.) is still pretty 
basic. I think it's due to the event system being grabbed directly 
from VID3, as it behaves the same way. There needs to be a person 
capable of writing this code, as it can be done as an isolated project. 
Gabriele is a prime suspect here, but he's probably too busy at the 
moment. If not possible to do now, then it will have to wait a bit.

- Carl talks about getting more people working with VID3.4 this month 
to get them to write real apps to reveal bugs in the layout engine. 
Needs lots of testing.

- Text fields allow text to be painted right out to the edge of the 
area-size, which looks a little silly. Carl wants Cyphre to look 
at DRAW clipping.
- Accelerator keys - no work done yet.
- Disabled or focused items - no work done yet.

- I have skinned button, toggle, slider, text, area and progress. 
I hope to skin scroller and panel today.
- Constantly working towards simplifying styles.

OK, I got a quick job: I need to make a one-month calendar in VID3.4 
complete with day names and dates. I just need the algorithm to generate 
the necessary VID block. It must be coded in R3.

yes, a bit like that. I will need it to output a VID3.4 block or 
at least allow me to generate it easily from that function.

Ok, I'm building it of several parts. (This may change if I find 
some more clever way of doing it.) First there is a DATA-GRID, which 
is a TIGHT style that contains actors to generate a grid view and 
links to a block of data. DATA-GRID is a slave style in that you 
link it to a data block and then it will display what it can display 
of that block from a start index set in the style, so it works like 
a data window. TEXT-GRID is currently just a variant of DATA-GRID 
with different spacing between cells.


Next, we can move that start index around by attaching a scroller 
to the DATA-GRID, and set the DATA-GRID's ON-SCROLL actor to set 
a new index, based on the input from the scroller. The scroller will 
be set based on the size of the data block versus the size of the 
data grid. Presto, a functioning list view.

I will explain sorting, filtering and all that later.

just a joke to try to generate a coverflow animation.
REBOL []
angle: 10
angle2: 0
decal: 0x0
rot: 0
scene: [
	transform angle 50x0 1 1 0x0
	pen red fill-pen red circle 70x0 2
	pen green fill-pen green circle 85x0 2
	pen yellow fill-pen yellow circle 100x0 2
]
scene2: [
	transform angle2 decal 1 1 0x0
	pen red fill-pen red circle rpair 2 
	pen green fill-pen green circle gpair 2
	pen yellow fill-pen yellow circle ypair 2
]
img: copy empty: make image! 100x50
logo: copy logo-empty: make image! 200x100
locate: func [color /local idx][
	idx: (index? find/skip rgb to binary! color 3) / 3
	as-pair idx  // img/size/x to integer! idx / img/size/x 
]
view/new l: layout [image img image logo]
rev: false
for i 10 170 5 [
	angle: i
	change img empty
	draw img scene	
	rgb: img/rgb
	gpair: locate green
	rpair: locate red 
	ypair: locate yellow 

	either all [gpair/x > 35 gpair/x < 65][
		rev: true
		angle2: angle2 - 15
		decal: gpair
		change img empty
		draw img scene2	
		rgb: img/rgb
		rpair: locate red 
		ypair: locate yellow 
	][if rev [pair: ypair ypair: rpair rpair: pair]]
	change logo logo-empty
	b1: as-pair rpair/x 25 - rpair/y
	b3: as-pair rpair/x 25 + rpair/y 
	b2: as-pair ypair/x 25 - ypair/y
	b4: as-pair ypair/x 25 + ypair/y 
	draw logo [pen red scale 2 2 image logo.gif b1 b3 b4 b2 border]
	show l
	;*** PUSH ENTER TO ADVANCE
	input
]
do-events

could be usefull to generate the optimal coordinates

I am not very experienced in how making bindings in various scripting 
languages work but I have fiddled around this a little... python 
by itself doesn't do anything automatic I think - and to my knowledge 
python isn't the best example of easy binding to c libs, but there 
are comunity provided tools that help you generate the interface 
code etc...  most people I saw used SWIG (which works for a lot of 
languages) http://swig.sourceforge.net/.. but the chat was that 
if you use that tool you geet quite a bloated code for interface.

hum, or you can pass a header block to the write function as is:
>> write [ url!  [ User-Agent: "TOTO" ... ]  #{...data...}]

but it's bugy, you have to add yourself some missing header properties 
in the block to generate a valid request.

like Content-Type: "application/x-www-form-urlencoded; charset=utf-8"

Well, I mostly play with mezzanine and library code and backports, 
then generate a *ton* of bugs and wishes in CureCode about fixes 
for or enhancements of natives. Because I tend to be public with 
my work, that's what you see. Carl is mostly working on the new DevBase 
right now (and possibly articles and interviews). Once the new DevBase 
is up and running the source will be posted to it, then we can all 
work on stuff.

I like functions that generate functions, if that helps :)

Ammon, both COMPOSE and REDUCE generate a new block.

I haven't been able to generate the segfault with your version in 
the way that I could with the live version.

Pekr, the reasoning behind blocking patches is the same reason there 
is no browser plugin - R2 is insecure, and R3 won't be. Every patch 
that you can make in your %user.r is what malware running on your 
system can make with your user permissions.


The goal is to have tons of REBOL hosts around. Every application 
with a plugin interface could have a R3 host as a plugin. R3 is going 
to be able to generate programs now, not just scripts. It'll be a 
real development tool.


The problem with all this is that being able to patch the runtime 
using %rebol.r or %user.r, so can anyone else, and you won't know 
about it. Can you say exploit? We already had a false positive for 
R3 this year, an old alpha mistakenly marked as malware. We don't 
want the next time to be for real. The only way to avoid that is 
to make R3 secure.


The way to make something secure is to make the behavior of your 
code predictable. That means making your requirements explicit.

The BIND/copy overhead is still there, but being able to use FOREACH 
on map!, object!, module!, port! and error! means that you don't 
have to generate a block! copy of those types in order to work on 
them. Plus you don't need the EITHER or CASE to screen for those 
cases.