AltME groups: search

I've been playing with Shadwolf/etc SVG 06 svg renderer today and 
am at the point where i am working on linking in gradients.  The 
test SVG i am using (because it seems to be a good mix) is http://en.wikipedia.org/wiki/File:SVG.svg

Icarii, your svg file is too much complicated for me.

It's using both gradientUnits="objectBoundingBox" and gradientUnits="userSpaceOnUse" 
 to render the gradients.

userSpaceOnUse

 use real coordinates for the vectors used by gradients (what i do 
 currently).
objectBoundingBox

  use % vectors which have to be converted into real unit,  depending 
  of the real size of the object (after rendering) where the gradient 
  is applied (what the fuck  !!! it's magic).


I have enough pain to construct correct gradients in real units for 
the moment.Your svg file is too much complicated.

Currently my problem is with the linear gradients when a matrix operation 
is applied on them.


The linear gradient use a vector v = (x1, y1) - (x2, y2) to indicate 
his direction and length.


grad-pen is defined like this:  [grad-pen linear normal xy 0 len 
angle [... stop colors]]

And i calculate his values with:

- xy = (x1,y1)
- len =  length of the vector v 
- the angle of the vector v


When a matrix is associated with the gradient, i multiply the coordinates 
of the vector v by the matrix before calculating the other values.
It's working well when the gradient is vertical or horizontal.

But when the gradient is inclined , the matrix multiplication give 
a wrong vector and i don't know why.

To be precise, the resulting vector seems to have the correct position 
and length, but a wrong angle.

And what i got with rebol: http://sites.google.com/site/rebolish/test-1/lizard-rebol.png

Steeve - your work is quite impressive! Just don't become demotivated 
by possible lack of responses :-) If you find some bugs, or you come 
up with some ideas of how to make View more SVG friendly, write your 
notes down, we can discuss it with Cyphre. I think that we are still 
in rather initial phase, so we can e.g. change the way of how e.g. 
gradient-fills work (I do remember someone reported that you can't 
translate gradient definitions between /draw and SVG)

This matrix must not be applied on the gradient's vector as-is, but 
on something else.
And i found what, at least...


The documentation of SVG is lacking of a good explanation about this 
curious matrix transformation.
All we can read is that curious sentence:


When the object's bounding box is not square, 
the stripes that are 
conceptually perpendicular to the gradient vector within object bounding 
box space 
will render non-perpendicular relative to the gradient 
vector in user space 
due to application of the non-uniform scaling 
transformation 
from bounding box space to user space

What does that mean ?????


It means that the SVG gradient must be rendered without using the 
matrix transformation.

And THEN the transformation matrix must be applied on the resulting 
strips.

You see the problem ?

The matrix must not be apllied on the gradient's vector, but on the 
resulting strips produced by the use 
of the initial gradient's vector.


What foolish morons have designed such a complicated way of constructing 
gradients.

Can't they just give a matrix that can be applied on gradient's vector 
as-is, no they can't, it's to simple.
Morons, I said !!!


Because of that i had to make more transformations to obtain the 
REAL vector.
step by step I do something like that:


1/ Take the initial gradient vector V and apply the matrix on it, 
it gives a vector V1

2/ RE-take the initial vector V, rotate it of 90 degrees, apply the 
matrix on it, and rotate back the resulting vector
. It gives the vector V2

3/ Project the vector V1 on the line V2 (orthogonal projection). 
It gives a third vector V3.
4/ That's all, the REAL vector to use for the gradient is V3.


It take me a while to figure that, by analysing the Inkscape rendering. 
Morons i said !!!

Well i thought SVG 's radialGradients will be easier. I was wrong.
SVG Proposes another stupid feature (yet another one).
Actually they can specify 2 circles.

One where the gradient is really rendered. And another one used as 
a window which clips the first one.
What the heck is that !!!!

it's why in a SVG's radial gradient, there is 2 different  centers 
 (cx, cy) (fx, fy)  for the 2 separated circles.


When the 2 centers are equals, then there is no prolem to render 
it whit the rebol's radial gradient, easy.
But when they differ, it's impossible.

I can't blame Rebol to not allow that, because it's a really stupid 
useless feature.

in fact, i think i could simulate that behavior.
By 
1/ rendering the radial gradient in the initial circle.

2/ create an image with that circle and clip it with the shape of 
the second one.
3/ Use that image as a pattern for the fill-pen attribut


But it would be a mess of  computing time and of memory, because 
in the draw block we would have images used as pattern instead of 
computed gradients

Ok, i finished with Radial gradients (less the impossible feature: 
2 different centers)


SVG use a matrix transformation to convert a circular radial gradient 
into an ellipsoid.

And you know what ? 

We can do the same thing with grad-pen which provides 2 scalling 
factors (grad-scale-x and grad-scale-y)

So in that case it's easier than for linear-gradient.
1/ take the focal point of the Radial gradient (fx, fy)

2/ Create 2 vectors starting from this point: 1 vertical and 1 horizontal, 
using the radius as their length.
3/ apply the matrix transformation on them.

5/ get  the component X of the transformed horizontal vector, and 
the component Y of the transformed vetical vector
6/ grad-scale-x:  x / r
7/ grad-scale-y: y / r

That's all folks

Guys, i updated the lizard.svg rendered with Rebol http://sites.google.com/site/rebolish/test-1/lizard-rebol.png

To compare with http://sites.google.com/site/rebolish/test-1/lizard.svg.


I'm glad to announce that i see absolutly no differences inside Google 
chrome.

All the grandients (linear and radial) are perfectly rendered by 
Rebol.

the difference in your render and SVG render is mainly the anti-aliasing, 
which is crisper in the svg renderer.... probably has a better algorythm 
setup than the one use by R3... this is probably manageable within 
AGG, but AFAIK there is no control for it within R3.

You know it's a problem when you can't replicate the bug and focus 
clearly what the problem is.
Carl put a spell on me because of that (in his last note)

wahoo ... lot to read .. T___T  basically there is in Draw/AGG some 
limitations due to gradient  system and matrix translation bugs i 
don't know if they have been solved  since i pointed a them ...

can't anyone shake that area and put rebol in it ....  something 
like a rebol os-commerce all strong and mighty in 200Ko ... Ok you 
can go to 2Mo last limit... lol

(and yeah you will say to me but why you don't do your solution os-commerce 
like based in rebol ?)

hum the amount of  capabilities in a e-shop web site clients are 
used to see now in days  are big...

Stat tools,  catalog edition, shiping, card. And then the hosting 
solution simply doesn't know about rebol so if it's not apache/php/mysql 
or apache/java/mysql  you are fried unless you have full access to 
the hosting solution and you are able to install what ever you want....(cheyenne!/rebol/mysql-protocol 
etc...)

As far i am, i made some useful tiny mezz, perhaps some could be 
in R3.

reuse: funco [b [block!]][head reduce/into b clear []]

** REUSE, reduce a block, but re-use always the same block 

** Actually, 3 time slower than a reduce block, but save memory and 
GC recycles if used massivly.
** I use it to pass small blocks of coordinates.

mulm: func [

 {multiply a matrix [a b c d e f] by coordinates x y, return coordinates 
 [x' y']}
	x y m [block!]
][
	reuse [x * m/1 + (y * m/3) + m/5 x * m/2 + (y * m/4) + m/6]
]

atan2: func [

 {Angle of the vector (0,0)-(x,y) with arctangent y / x. The resulting 
 angle is extended to -pi,+pi}
	x y
][
	if x = 0 [x: 0.0000000001]
	add arctangent y / x pick [0 180] x > 0
]

Project: func [

 {orthogonal projection of a point P on a line AB, return coordinates 
 [x y]}
	ax ay bx by px py
	/local sx sy ux uy ratio
][
	sx: bx - ax
	sy: by - ay
	ux: px - ax
	uy: py - ay
	ratio:  sx * ux + (sy * uy) / (sx * sx + (sy * sy))
	reuse [ratio * sx + ax  ratio * sy + ay]
]


vector-length: func [x1 y1 x2 y2][square-root add x2 - x1 ** 2 y2 
- y1  ** 2]

My, my, my...


I think some features in SVG, are too much work to implement with 
Rebol.

1/ The "objectBoundingBox" units.

Which means, coordinates and lengths are ratio or percentages. 

And they are converted to real units depending of the bounding box 
of the shape on which they apply.
It's easy to calculate when the shapes are boxes or vectors. 

But when it comes with arcs or curves, it becomes a pain in the ass.


It's not a real problem because Inkscape for example has an option 
(simplify shapes) to convert all the ratio units in real units (ie. 
pixel units).

So, I don't see the interest to rewrite DRAW from scratch with Rebol.

(because it's what it means, to be able to calculate all the bounding 
box)

2/ Outlines with gradients


Those fullishs can specify a gradient for the pen attribute (which 
draw the outlines).
Rebol can only have a gradient to fill a shape.
It can be simulated by drawing the related shape 2 times.
1 time with the pen gradient.

A second time with the fill-pen attribute (which can be a gradient 
too).

But the second time the shape must be, at first, downsized of the 
line width.

To do so, it means that we need to know the center of the Bounding 
box of the shape.
So, same problem than 1/


3/ The fill-pen attribute (gradient or color) never apply on the 
outline of the shape, event if the outline has no color but actually 
has a width.

It allows SVG for example, to have transparent outlines.
We can't do that with Rebol. 

Because the fill-pen attributes (or the gradient) fills all the shape 
at first.
And then the outline is drawed over.

If we don't provide a pen color, or we provide a transparent color, 
we see the fill-pen content instead, at the place of the outline.


Perhaps, that can be modified in Draw. A nice request but not a so 
considerable feature to my mind.

(And it can be impossible to implement this in Draw, if AGG doesn't 
support it at first).

re 1/

yes, I don't think this is a problem of DRAW but more problem of 
unit conversion. DRAW works with pixels as it it low level dialect 
(not only for rendering SVG format). So the higher level code(SVG 
parser) should be responsible for this until I am missing something.


re 2/ gradients for outlines were planned for addition so I hope 
this will be in the R3 final release ;-)


re 3/ transparent outlines are known problem. (BTW is this working 
properly in other SVG renderers? I'd like to see the results) This 
is because we are using rasterizer which is drawing one shape over 
another. IMO solution could be to replace the rasterizer with different 
one (for example like Flash) which is simulating 'Constructive Solid 
Geometry'.

But this would need major changes in the current internal implementation 
(and in fact also switch to higher version of AGG). 

My guess is it could also speed-up the rendering in some cases...I 
started to investigate this area but it needs more time which I currently 
don't have :-/

Ofcourse, the DRAW function wouldn't draw anything in case of using 
such refinement so no need to worry...I bet Carl will make the last 
decision about the wording and I know I'm not good at it so...yes 
something like that ;)

my idea for draw elements was to allow set words in the draw dialect, 
and then be able to interact with the strokes rather than the whole 
block... since the conversion to/from AGG-REBOL doesn't need to be 
done all the time, some time is spared.  most of the time, we only 
need the dialect to create stuff... then, we can just manipulate 
it.

also it would allow us to get information about the strokes   

ex:   [s: spline 50x50 100x100 30x4]  

print s/length?  ; get spline length, in pixels

print s/coord-at-length 45 ; get coordinate at 45 pixels down the 
spline.

Maxim, yes, I think this is one fo the ideas we discussed at DevCon 
in Paris.

If we add the DRAW shape->coordinates interface this will be yet 
another usage of it.

The current internal architecture already counts with sort of persistency. 
Currently we are just discarding all the internal shape paths on 
every redraw. I fear the main problem is how to handle this efficiently 
at the REBOL layer, especially GC handling...it can lead to big memory 
consumption in case programmer won't free all references to the DRAW 
elements etc. Or maybe a command for manually edstroying the 'DRAW 
internal context' would be the best solution...

Another question is, even if we solve the REBOL high-level access 
interface to it, how much would direct DRAW element modification 
at such internal level affect the performance, is it really worth 
doing that(ie make things more complex)?

Because in that case we will be only 'bypassing' the DELECT parser 
and AGG's internal Coordinate conversion pieline(s)...the rasterizing/rendering 
pahse needs to be always redone(but we could try to play with some 
clipping tricks here too). Both parts are already very fast but I 
agree there can be gain in some large data cases. This needs to be 
investigated before we decide to add such feature.

About having gradients for lines, this for me would be a solution 
to the problem that complex drawings that scale, can't be hinted 
properly. I saw this when making some icons for R3 and then scaling 
them. At 1:1 they look fine, but lots of detail is lost, when they 
are scaled down.

My suggestion was three keywords: hint, hint-x and hint-y.


Then you would first provide your scaling transformation, say 0.1. 
Then you provide your shape, and then add hint, hint-x or hint-y 
on each coordinate individually. Those would then be hinted to the 
nearest whole pixel internally.

Well, just turn of Antialiasing

 No. The difference between this and turning off AA is that you can't 
 make hinted rounded rectangles with AA and you can't get a pretty 
 hinted rounded rectangle without AA.

its usually better to generate larger shapes and scale them down, 
this way you have sub-pixel precision when drawing.  all you need 
to do is scale the widths and transform the coordinate space when 
you draw...

for me the draw stroke persistence, is mainly for allowing interaction 
between the application and the graphics... text on curves... spline 
paths for animation, snap to edge, etc.

with two splines and enough information gathering, we can easily 
render bending geometry and stuff like that... right now... its highly 
complex, and we can use the internal AGG binary math to calculate 
all the coordinates to stuff for us... based on the current transforms, 
and stuff.

and we can 
 = "since we can't"

for me its not speed as much as massively usefull (and free) functionality.

Perhaps we could split it into a View Project and a DRAW Project.

I think I'll leave it for this page for now. We can split it in multiple 
pages later. Our discussions seem to criss-cross between DRAW and 
View anyway.

Steeve, sorry, it's a small hack. I grabbed the svg coords from inkscape 
manually and simply pasted them in a text file, made them pretty 
for rebol and converted them to DRAW in a simple way. I have no XML 
parser or anything like that.

and what  about the text display / font management issues ... and 
this can be linked to viva-rabol or SVG rendering... Cyphre do you 
plan or have taken  some notes about that area ?

For instance, 1000 > i would be faster than i < 1000 because ops 
redirect to actions, and actions dispatch based on the type of their 
first argument. If the first argument is a literal value, the action 
of that type can be called directly. If it is a referenced value, 
it woulkd have to be dereferenced first, which is apparently slower.


As for PICK being faster than NOT TAIL?, that is one native compared 
to two, with interpreter overhead between the two. Low-level natives 
like PICK, NOT and TAIL? don't do much in comparison with the interpreter 
overhead. Large numbers of small operations tend to be slower than 
small numbers of large operations, if the amount of work done is 
comparable. This is why structure manipulation is faster in REBOL 
than simple math.

I intend to devote a whole site to these tests eventually.  with 
a very extensive and comprehensive set of test functions and statistics.

with the tests I did, I think I can probably optimise liquid by at 
least 20% just by changing the loops and changing none of the algorithms 
or features.


I am about to create a second reference liquid node type. which will 
be completely compatible from the outside, but with less features 
inside.  I expect to DOUBLE its processing capacity.

Code converted from R2 to R3 tends to need reoptimizing - the balance 
of what is native vs what is mezz has changed, usually for the better. 
All of the loop functions are native now, for instance. Also, some 
natives have been converted to actions, and vice versa.

yeah amd with the faster fuunction calling in R3 liquid should get 
an immediate boost in speed... it does A LOT of tiny function calls 
to manage the graph as if they where first level types with accessors 
instead of using a controler which loops over the graphs and limits 
flexibility.

if you are willing to keep a version of the keys accessible at run-time, 
then the keyed search algorithm is MUCH faster, but incurs memory 
overhead, and the creation of the keys, on big blocks, is not negligible 
(time not included in tests, but will generally put the keyed algorythm 
slower than the fast-find)

My priorities:
1. Finish PROTECT and the other security stuff.
2. Device extensions.
3. Port/networking stuff.

I might be a bit more detailed, and I will not mention things other 
ppl mentioned here:


The stuff that needs adressing, at least in the form that RT states, 
WHEN and possibly in what form, are those things implemented

1. Concurrency (tasking)

2. RIF - what happened to this concept, and how important it is for 
3.0 beta?

3. Codecs - is this concept of read-all-data-into-memory usefull 
at all?

4. Unicode - what about more locale support? I need to be able to 
sort using collations, or Unicode is half-way implemented for me

5. find/not - some ppl talked about it as about important feature. 
I can see only find/first on the list

pekr, my devices proposal actually extends a helping hand into thread 
space, LNS and inter-rebol coms  :-)

and/or ODBC? (ODBC can't be done on all platforms probably, so how 
to aproach it?)

I guess you missed it when Maxim and I wrote "Device Extensions".

ODBC as an extension is OK, https (ssl) is not - it should be default 
part imo, as there is no web without the security and certificates.

SSL could be built-in, but if we can't get it tiny it would be a 
problem. We should pare it down to what is necessary to establish 
a secure connection and make the rest external.

I have spoken to Carl about using putty's completely self enclosed 
and extremely tight, completely up to date SSL code as-is.

GFX is part of Host layer, and Host layer is going to be internally 
done using Extensions probably, so your request might be accepted 
:-)

1. View/GOB
2. Win, Mac and Linux
3. SDK

I share my priorities with Maxim with a hope he will share his know-how 
with us so we can use it together to make REBOL better.... and of 
course releasing Host source.

1.  Mac and Linux

What I most want in R3 console are not different colors or fonts 
etc. , but a way to write commands longer than one line, 

meaning that I can define a function over more than one line and 
easily paste into the console.

R2 seems to delay checking and doing the input after all brackets 
are closed.

I can not understand that this requires a GUI.

Seriously, there are already Windows console alternatives on Windows. 
Let's just find a good one and test R3 in it. It'll be quicker.

I think that we should announce time for Q&A session, we can come 
up with moderation, if we wish (but not probably necessary), and 
the main person is Carl - so Carl chooses the time, the rest tries 
to adhere. As for me, I have no problem with any time, I just need 
to know - WHEN it happens :-)

portable fonts system working with VID/draw this means a font system 
than render the font for the same font file the same way on linux, 
macosX, windows seven, vista xp etc...,  and being able to know precisely 
the size in pixel on screen of the characters from the font we are 
using any time and any momment ( this is related to area-tc and what 
we noticed developping it actually area-tc rendering engine / event 
system works only properly on windows XP due to limitations in  rebol 
2) 

3) better draw dilect more hum light  and flexible ( no need to give 
the coords and call the text instruction in draw bloack any time 
we want to change the color or the font style of a particular bunch 
of text drawn on screen)

instead of [ pen 0.0.0 text antialised  0X0 "one text" pen 255.0.0 
text  0x20 anti-aliased " red " etc... ]  it would then nice to have 
" text antiliased black "one text " red " red " etc...]  the matrix 
push and clear should be a way too  optimise the management of segments 
of  set of draw instructions ine the  draw block.

dig up one of the proposition made a year ago by carl regarding the 
way draw could   work using aliases ...  hum at that time we hadn't 
worked on area-tc and the aliase to short set of instructions and 
arguement comming often in the draw block apeared us like a meaningless 
thing  but this kind of feature would be nice in a project  like 
area-tc where the size of the draw block matters in many way (debugging 
200K  of draw instruction to back trace why your text drawing engine 
is not drawing the proper way is a pain believe me) ....

shadwolf, graphics are not in priorities for this round of REBOL. 
 we need to finish the core first.  once that is done we will be 
able to fix some of the stuff in the host code ourself, thus allowing 
us to work in helping Carl... but there remains much lower and important 
issues than VID right now.

Three things come to mind:
1. Yes, core is the focus.... for me and for right now.
2. View graphics is open source (see next msg.)
3. VID is also open source.

On View: Cyphre was in charge of all graphics. But, he vanished into 
the Qtask black hole a year ago.


If someone else has guru graphics-system knowledge and wants to move 
it forward, that might be a good thing.

Maxim is active in graphics and GUIs.... so I was thinking he may 
be interested in those lower levels too.

I can't risk working 2 weeks and hitting an issue which can't be 
solved because its an unfinished part of the host.
 - Maxim on R3 View

If it helps to get the host code done first and then get someone 
to work on graphics, maybe that's a better idea. R3 is making great 
progress in other areas, which we don't want grinding to a halt.

I think we should get a hold of Maxim and see what he says. If he 
gets free access to the candy store, he might change his mind. :-)

darn, I go away a few hours and Carl pops in.... basically offering 
what I've been dreaming for the last Decade!
  

I would really like to participate in the host code, right now, I'm 
basically giving myself a very in-depth course in applied 3D graphics 
and I won't lie in saying I'd rather do it R3 if I would be sure 
that I won't run into an unknown and be stuck.


my comment wrt R3 being buggy, is not a comment on the quality of 
R3 itself, but the fact that many core things still change quite 
often.  so code using R3, especially very hard to debug and complex 
code like 3d arithmetics can become a nightware with the slightest 
little change.

true, I'll go there and see if there's more news for me.

From the sidelines, I hope this bears fruit Maxim (and Carl). Very 
cool.


One favour to ask.  Max, if you get hold of our low levels ... be 
gentle ... try and factor some of it down so the 2 dimensional 4 
digit brain types still have a chance to decode some of that whiz 
bang almost too far out of the box stuff I suspect you may have brewing. 
 :)

Carl: "Cyphre was in charge of all graphics. But, he vanished into 
the Qtask black hole a year ago." More precisely, you stopped updating 
the host code on CVS, and me and him stopped having the ability to 
do anything useful on that front in the little time we had available.

Carl: I have the same feedback from Cyphre - he was mainly waiting 
for the "Go" and synced sources ...

Carl, listen to the chorus: Release some source, even if it is a 
limited release to the interested-and-qualified-helpers. You need 
help :(

I second BrianH's opinion - please release to the first limited group 
of Devs, to prevent possible initial chaos. As for me - I think that 
we CAN manage the situation, even if you would release it publicly. 
Not many ppl use R3 Chat do download sources nowadays. I think that 
if you set some coordinator or two, e.g. BrianH, Henrik, Maxim  - 
whoever who will accept the role, then we will be fine and even other 
ppl can study the code and try some things for themselves ...

wow... carl and I here at the SAME time  ;-)

every other time you've been here, I was off line for a one or two 
hour period... and everytime you're not here, I'm there during those 
hours... hehehe

you could just setup a simple svn for it... its really simple to 
setup, and we can all easily participate and share our stuff, even 
if working on the same files.

simple and svn cannot be used in the same sentence, if I recall correctly.

I use visual C++ studio express.  (free and simple)

Then, I'll probably just drop you a zip of everything for you to 
try it and tell me what problems pop up.

A few days of smoothing it out... and we should be good to go.  But 
note...

installed... 226MB  (seems to include a few extra tools like C# and 
VB

Anyway, I'll put together a more detailed plan and get it to you. 
 I want this to go quickly, but not waste any of our time.

Got to go... but I'll work on a core-only host package for tonight. 
That's a good way to sync up, because the whole thing is simpler 
to make and link.

Just giving a little report about a very interesting chat I had with 
Carl:


- Host code package is in the works... given priority.  My impression 
is that Carl is really wanting for this to happen.  If any of you 
feel you can actually participate and do real tests and work, now 
is the time to raise your voice.
 

- Devices and the Extensions dll code are part of the host code. 
  Thus, by extrapolation...  We (i.e. Not Carl) could work on a model 
of Device extensions and propose it to Carl, if anyone (or group) 
wants to put the effort.  obviously using the current Extensions 
as the reference...


- As it stands now, adding Native Datatypes is complex outside of 
the rebol core  (ex: in host code) because of a few issues (GC integration 
being a major one).


- Carl isn't against the idea of finding a way to add Native (binary) 
user datatype but it most probably will have to wait a bit until 
Carl and Host developers find a way to make it simple and bug free. 
 a possible idea is to bave a special extension model which acts 
as a datatype marshaller, with defined commands as datatype actions 
(aka accessors in other languages).


- Talked a little bit about threads, but nothing really specific 
to say about it... I'll need to try it in practice so I can ask relevant 
questions.

as a concrete example, if its possible for me to add image! support 
in Extensions right now (code, test, examples, documentation).... 
I will, and if its done properly, Carl will just be happy to sign 
off on it.

if not, he'll point me in the right direction.  then, when I get 
to vectors... the chance that I get it wrong will be smaller, but 
we have to start somewhere.   We actually have to start doing it 
and stop just talking about it.  :-P

If Carl is needed to really implement devices well, at least we can 
help by getting the almost-well implementations done, so all Carl 
has to do is tweak and merge. We can do a lot of research...

Solve the annoying hardware issues and connection issues, even proving 
it with examples, and then Carl can just intigrate...

Yeah I know many people here think I hate REBOL -  but truth is I 
love REBOL more than most of you and I want REBOL DOMINATION!!!!!

I know that me and Brian don't always see eye to eye but I'm an honest 
person where Christ has a say and I am humbled to acknowledge that 
Brian is instrumental in some of the greatest achievements of REBOL 
to date and see him as the REBOLer of the YEAR!!!!! if there were 
such a reward!

and yes, Brian has put a lot of his time into R3 for free.  He has 
been pushing and helping Carl into doing a lot of things which are 
now part of R3.  He deserves our gratitude.  h might have shaven 
a full year off of R3's implementation just by himself.

Seriously, we owe a lot to Peta. PARSE is much better because of 
Peta's work. A bit of a drive-by though: Came, argued well and helpfully, 
then disappeared. I look forward to the next time Peta shows up :)

Peter's post was:

BOUNTY

Offered by:
	Graham Chiu

Task

 Modify Chris Langreiter's 3flex.r so that it can be encapped and 
 run inside its own context.
	It should not access any source files once encapped.
	It should be able to be then included into another application.

Amount:
	USD 35

Terms:
	Payment via PayPal
	Fees to be paid by recipient

BOUNTY (obfuscator):
Offered by:
	Janko Metelko
Task

 Open Sourced Rebol 2 code obfuscator that would change all names 
 of function / variables 

 in a cheyenne -like webapp and compact the code (without making the 
 app not work)
Amount
	$60
Terms
	Payment via PayPal

I'd like to pay someone to help me write a videoconference application 
in R2.  I've got a little VOIP script already working at http://www.rebol.org/view-script.r?script=intercom.r
.  Using the Windows MCI API that I knew, that simply writes a wav 
file to a file, and then transfers it.  I need a Windows/REBOL guru 
to help me continuously retrieve wave data in memory, to avoid gaps 
and delays in the sound.  Same thing with video.  My webcam script 
can only write images to a file - I need to have some Windows API 
code written to do it all in memory, without the delays associated 
with writing to a file.

Amount:  Please suggest an estimated amount

BOUNTY

Offered by;
	Shadwolf
Task :

 Getting R3 before i get too old to give a damn about having it ...

Amount: 

 Priceless...Does money havec to be always the main motor in all human 
 enterprise ? Doesn't it is better to fo it cause well it's me asking 
 it and you like me all those stuff...

Terms: 
	Feel free...

Graham, I got it and I agree. I just tried to show one of possible 
explanations why there is noone picking up the Bounties. I believe 
there is lot of great programmers around lurking on this Altme world. 
It seems to me they are just busy with their day jobs and rather 
want to spend the small piece of their free time(if there is any) 
in a different way than sitting in front of LCDs again. That's just 
my impression about the state.

TomBon, please don't take it too personal. The DLL interface was 
just an example as I saw it at the end of the queue. As I said in 
previous msg maybe I'm just overestimating the work and some Rebol/C 
expert will do it in 5 days for Win/OSX and Linux. Also while looking 
at the 'valid date' you gave to the task this seems to me more like 
'full time' job deadline than some fun bounty work.
BTW isn't Maxim working on the DLL stuff already?

I am, actually, a DLL interface could find its way back into my schedule 
next week, and would once again benefit multiple clients of mine.


I`ve already got some work done and a compiling setup all ready for 
it.   


thing is, the next hostkit / extension could make a bit difference 
in how this is implemented, so I was waiting for the next release 
of R3 before starting this project again... it has been several months 
now since this was last released by Carl.

my part here is $350 so you can see it as an official increase from 
the $200 I made in january. 

so if pekr, janko and will still offering their bountie the total 
would be $600.

but for fairness I think you should ask them if they are furthermore 
interested after such a long time.
for this reason I added the 'valid until' .

Offered by:
	TomBon
Task:

 R3 - Bindings for libcurl - the multiprotocol file transfer library
	http://curl.haxx.se/libcurl/

	C - API  -> http://curl.haxx.se/libcurl/c/allfuncs.html


  libcurl is a free and easy-to-use client-side URL transfer library, 

 supporting DICT, FILE, FTP, FTPS, GOPHER, HTTP, HTTPS, IMAP, IMAPS, 

 LDAP, LDAPS, POP3, POP3S, RTMP, RTSP, SCP, SFTP, SMTP, SMTPS, TELNET 

 and TFTP. libcurl supports SSL certificates, HTTP POST, HTTP PUT, 

 FTP uploading, HTTP form based upload, proxies, cookies, user+password 

 authentication (Basic, Digest, NTLM, Negotiate, Kerberos), file transfer 
	resume, http proxy tunneling and more!


 libcurl is highly portable, it builds and works identically on numerous 
 platforms, 

 including Solaris, NetBSD, FreeBSD, OpenBSD, Darwin, HPUX, IRIX, 
 AIX, Tru64, Linux, 

 UnixWare, HURD, Windows, Amiga, OS/2, BeOs, Mac OS X, Ultrix, QNX, 
 OpenVMS, RISC OS, 
	Novell NetWare, DOS and more... 

Amount:
	$150
Valid until:
	01.11.2010
Terms:
	PayPal

bounty for ZEROMQ closed. thx to andreas & kaj 
bounty for FANN, GAUL, KNNL and KOHONEN closed (moved to LUA)

ps: and thanks to gregg of course :-)