AltME groups: search

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.

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 !!!

Now the question is - should we adapt, or do we create copy of such 
functions, to allow being compatible?

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

also the anti-aliasing was a result of my browser which rescaled 
the image minus 5 pixels... so it has nothing to do with your render.

well, it should do the same in R3. at least it did in earlier builds, 
but does PARSE have anything to do with that?

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

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/

Well you're right, it's the responsability of the client (parser) 
to do unit conversions.

But to do so, we need to know where the renderer draw each pixel 
(i mean the real coordinates) of a given shape, to calculate the 
bounding box.

Take an arc for example, it's impossible to calculate where the pixels 
of the arcs are drawn without simulating the complete AGG engine.

There may be various transformations to apply on that calculation 
(matrix, translation, scaling, rotation, skewing).
To calculate that, we have to simulate exactly what AGG is doing.

Mission impossible

For some reason, hinting is going to be hard to implement for DRAW. 
I talked this alot over with Gabriele, who felt it was not possible 
to do. It would still be very nice to have for truly scalable GUIs.

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

yep... just noting how to do it currently.

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 ?

as im browsing nodejs, i see so many features implemented which is 
missing from cheyenne, but i have already wanted to use, which makes 
me seriously consider switching to node.


cheyenne has the right foundations, but i feel it requires too much 
studying of the internals to extend it in a practical way.


i think it's better if u focus on red. that's something which not 
many ppl can and want to do, but would be able to affect the world 
big time.

I've just switched NginX in front of Cheyenne to do the reverse proxying, 
and other things

PeterWood: The point would be to keep the architecture simple.

I don't want to introduce another component, unless it gives a lot 
of value.

otherwise, im very well aware of how simple nginx is. i used it a 
lot as a frontend for rails/sinatra projects and even php, then once 
as an upstream for haproxy too.

but exactly because it's so simple what im expecting from it to do, 
i dont feel like adding it to my application stack which currently 
consist of rebol only...

Christian, The data in eh browser looks right now...thanks, but teh 
jquery script is still not working. I believe it has to do with the 
callback or lack there of ...

That's what I plan to do too for Red.

My main server is down since a few hours due to a non-technical issue. 
This affects all the following web sites:
- cheyenne-server.org
- curecode.org
- part of red-lang.org


The problem should be solved in an hour. This server is still owned 
by my former company, Softinnov, who forgot to do the renewal in 
time.

I want to log certain events from the webapp. What would be the most 
efficient way to do this (by this I mean one that would have least 
impact on server responsivenes). I would like to use something silimar 
to debug/probe debug/print .. Is it possible to have use the existing 
loging functionality to log custom stuff to custom log? (or is this 
just normal file append)?

Endo, thanks for the code. I will need something similar for sqlite. 
I just got a first db is locked error yesterday with it at UsrJoy.


What I'm trying to log is side-info (like usage info) so I don't 
want to inpact the speed of response by having aditional disk write 
in the request-response process (it has to be async).


Doc: I used debug functions for various info logging too now (and 
I do diff on trace in cron and send myself email if there is any 
difference), but I am trying to log more things and I would like 
to leave trace.log for errors only. I was interested if the existing 
functionality that serializes debug to trace.log could be used to 
log to some other file. like info.log . That would complicate the 
app-code the least.. otherwise I was thinking of what  Kaj  proposed, 
to have some queue to send data over via tcp to and it will write 
it to disk in intervals. That would bring another dependancy into 
app-code.. something like redis could automatically work like this 
I think.

It could be possible to extend debug object to handle an /info refinement 
that would log to an %info.log file, but that would put some burden 
on Cheyenne main process when in production. I thought about writing 
an OS logging service wrapper, but never found the time for that. 
I usually do all my writings from webapps into databases that are 
able to handle concurrent accesses reliably (so, not sqlite).

Judging by the documentation it should be able to do it, but I admit 
I usually mistrust such things

when I encap embed-demo.r, embed-demo.exe gives this error:

** Script Error: select expected series argument of type: series 
object port
** Where: get-cache
** Near: select cache file


Do I need to do something else? I uncommented "embed" in httpd.cfg.

One thing I need to do is add encrypted script files. What do you 
think would be the most logical method, modifying source or making 
my own interpreter?

patch it to do what?

Do not forget to run Cheyenne once after update your files to refresh 
the cache.efs file.

Can I use Task Master from jobs, if I added my module to UniServe?
something like:
jobs [every 5 s do [shared/do-task [...] ] ]

You might have to use a longer access path like: uniserve/shared/do-task

It looks like I can use on-timer event to do my async polling and 
then sending the results for each client.

When I remove AUTH line from WEBAPP section in httpd.cfg file, the 
browser always returns :ERR_EMPTY_RESPONSE error.
Here is my part of httpd.cfg
	webapp [
		virtual-root "/testapp"
		root-dir %www/testapp/
;		auth "/testapp/login.rsp"
		;debug
	]


in %testapp/  I have test.html and test.rsp they both very simple 
files, I have app-init.r also. But I can never access those files.
In Cheyenne log file I see following error:


10/12-3:11:39.3120-## Error in [uniserve] : On-received call failed 
with error: make object! [
    code: 303
    type: 'script
    id: 'expect-arg
    arg1: 'second
    arg2: 'series

    arg3: [series! pair! event! money! date! object! port! time! tuple! 
    any-function! struct! event!]
    near: [either url: second pos: find]
    where: 'process-webapp
] !


As a work around I put auth line to a rsp file that just do session/content/login?: 
yes and redirect. 
Do you have any idea? I tested with 0920 and r164.

Doc: "You can just pass a block! value as a job to the scheduler 
and call your code from there, it would be cleaner than hacking in 
on-timer."

How do I interact with "clients" connected via ws inside a "job" 
block?

I have "clients" block in on-timer event and I able to send messages 
to them. Is it possible from jobs?

It's a not big issue, but I noticed, that the include function does 
not removes BOM from the files. Do you think it's worth to improving 
it or let people to maintain it manually in the files which are being 
included?

By default, DO binds the code to the webapp execution context, to 
get the native DO (with binding to global context), you need to use 
DO/GLOBAL.

You can quickly port all older code by just adding /GLOBAL to all 
DO calls (especially for global libraries loaded in app-init.r).

btw: I yesterday used Ladislav's excellent!! closure with cheyenne 
and it didn't work. Then I found it's because of do which it uses 
.. It worked once I changed it to *do

If you let me know which ones, I'll try them out on my machine .... 
but I won't be able to do so just now.

I have a problem with cheyenne-r0920-cmd.exe on Windows, when I comment 
database section in my http.cfg it works, when I uncomment it gives 
the following error in chey-pid-9036.log file:


25/1-17:58:14.625-## Error in [uniserve] : On-received call failed 
with error: make object! [
    code: 515
    type: 'access
    id: 'invalid-path
    arg1: "/E/cheyenne/www/centrex//index.rsp"
    arg2: none
    arg3: none
    near: [info? new [
            req/in/target: form file 
            if ext: find/last req/in/target dot [
                req/in/ext: to word! ext 
                req/handler: select service/handlers req/in/ext
            ] 
            if not req/in/file [req/in/file: new] 
            if d?: declined? req [return false]
        ]]
    where: 'throw-on-error
] !


note that there is double slash before index.rsp I don't know why. 
Error happens before I use any do-sql or something. Web page doesn't 
work at all.

Gregg, I know your take on optimisation... ;-)


<start rant  ;-) > If I had the same opinion, liquid would still 
be 10 times slower than it is now.   each little part of the changes 
add up and after years it really adds up.  I have some new changes 
which will probably shave off another 5-10% when they are done.  
 It requires several changes (some probably removing  less than a 
%).  its been like that since the begining.  the relative impact 
of any optimisation is always bigger the more you do it.  


the first 1% looks like nothing when you compare it to the original 
100% but after you've removed 25% its now 1.33%... but when your 
app is 10 times faster, that 1% is now 10 % of the new speed.


btw, I'm not trying to justify this specific optimisation, but I'm 
trying to balance the general REBOLer consensus that optimisation 
(in speed, code size and RAM use) isn't important when compared to 
other Reboling tasks... 
 

Have you (using "you" in the general sense, not gregg specifically) 
ever looked at Carl's Code?  its some of the most optimised and dense 
code out there... it hurts the brain... and its very enlightening 
too.  all the little variations in the series handlers often are 
there by  design and all balanced out against the others.  Carl uses 
all of those little variations profusely... to me its in the very 
essence of REBOL to be optimal and constantly be refined, improved, 
and this usually means by shrinking it in all vectors.  

<end of rant  ;-) >

I agree with you Maxim.

But on the other hand, I never allow my team to sacrifice the readability 
unless IF there is a really good reason to do that AND IF they put 
enough comment WHAT and WHY they do that. Otherwise it wastes our 
time to "solve" the optimisation a few months later.

Optimisations are good / necessary if they are (can be) in loops 
(mostly), but they are dangerous especially if you are writting lower 
level code (mostly C, even Java) because compilers use code-patterns 
to optimize your code, so your hand-optimized code prevents compiler 
optimizations on modern compilers.

And worst, if you are using assembly, your optimizations may prevent 
to use CPU caches and for example when it works faster on one CPU 
it can be even slower than the original version on another CPU.

By the way, I tested on 3 different PC with R2, while loop was always 
faster then the until loop in the above case. Of course I didn't 
test the real case (using do-sql with millions of rows)

And of course Carl should write very optimized code in REBOL because 
everything else is depend on it. 
Hmm I think we should move to another group :)

I believe in optimizing on a case by case basis, as most do. And 
I believe in optimizing different things in any given case. Size, 
speed, felxibility, and readability are all fair game for optimization.


As far as AltME and other slow REBOL UIs, I remember Carl saying 
once that View is a miser, saving pennies, while VID is the government 
and spends millions. I think whoever designed the list model used 
in AltMe and other apps (e.g. IOS conference and messenger) chose 
to make the implementation small and quick to write, knowing that 
they might not be fast. They may also not have imagined how far they 
would be pushed.

You are right, giving a link is better than including the whole dll.

What do you think about making a setup package for Windows? Including 
that dll and some configuration options during the setup, service 
mode default, etc.
If do you think its worth to do, I can do it.

@Endo, you can do it, and Doc can link to it :)

graham, This will allow us to do Hardware-accelerated 2D/3D directly 
from REBOL.

I've been waiting sooooo many years to be able to do just what I 
am doing now  :-)

I created this group, cause ever so often these experiments come 
around and we loose them... this should become a quick repository 
of tests & disussion for profiling discoveries we do.


any test should provide the full test command-line code, so its easier 
for other to copy-paste & compare without having to re-type.


ever so often, a compilation should be done, highlighted in a different 
color for easy referral...

actually, you are not sorting or traversing a long serie.
>>reduce [a]
== [[1 1 1 2 2 2 ...]]

your serie contains only one value.

i suggest to do a COPY A instead

Do you use the skew command in draw ? or are you calculating the 
coordinates of your 3D objects for each layer.

(I think SKEW allow to simulate isometric rendering in AGG, but it's 
just an assumption, i never tried it)

will be nice to do the same exercise on R3

A thing should be noted.
repeat and foreach do a bind/copy of the evaluated block.

Even if they are the fastest loops, they should be not used too intensivly 
because they will polluate the memory.

It's particularly sensitive for graphics applications or services 
that linger in memory. 


So, that's why  I advise to use only LOOP, WHILE and UNTIL for intensive 
repeated loopings, if you don't want to blow up the memory used by 
your app.

as noted in the document test notes:

I specifically didn't do any GC control, cause I wanted, at this 
point, to see how the loops react under normal rebol execution.  

the GC normally is pretty aggressive and when you look at the tests, 
most loops roll for several hundred thousands times, so the GC will 
have kicked-in... if it can.

I did note, that there is a HUGE memory leak which occured probably 
in the actual benchmark procedure itself.


although I keep no reference to any of the data or transient test 
blocks and funcs, they are kept somewhere, and my rebol.exe process 
keeps growing and growing.... I caught it at 500MB !! but it didn't 
do any difference in actual speeds... after a few tests.... cause 
i was a bit scared.

Thanks for the info, Maxim. We can do a little deduction from that 
data to guess how REBOL is implemented. The scientific method :)

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.

The plus side is that what you would just do, before you try to optimize, 
tends to be faster in R3 than it is in R2.

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.

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.

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

do we have some access to R3 funcs into Extensions?

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.

Carl will say no if he doesn't like it.  


but do you really think that people which are going to be actively 
helping out in adding this type of code to the host to stray far 
from any ideals Carl may have?

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

Nice to read you working on the host code together with Carl. Hope 
in a couple of years I'll be ablet to do this too :-) You are a good 
group.

It is triage time, my friends. We are heading to beta, so we need 
to seriously consider what it practical to do quickly, and what needs 
be put off for a bit. REBOL is going to continue to have reasonably 
frequent updates - no more waiting years for the next release - so 
you don't have to act like your favorite proposed feature will never 
arrive if it doesn't make 3.0. We need to figure out what we need 
to make a useful beta.

REBOL 2 will still be here, and despite what some people have been 
saying it hasn't been abandoned. We have been focusing on R3 lately, 
but there will be new R2 releases to come. Migrating to R3 won't 
be an all-or-nothing affair. Gradual migration and mixed projects 
may be the norm for the short term. We don't want to block our users 
from uusing the killer features of R3 just because it doesn't do 
everything R2 does yet.

So, do we add https to the list? No matter if it gets adressed, it 
should be there imo. We somehow magically missed on that feature 
thru the whole development process. I never seen any blog, etc., 
which would even mention it ....

but there is some of that built in to R2 already... which is why 
I say its *possible* to do in R2 as a server, the SSL code already 
in R2  would just have to be adapted to act as the server side of 
the handshake/transfer.

I have a huge graphical application written in R2 (Canvas RPaint, 
close to 13'000 lines of code), that I can't get released because 
of host problems and differences in REBOL between OSs. I do much 
of my development under OS X, and I have lots of utilities and applications 
written in R2, that suffer from problems in REBOL/View, that I might 
be able to solve, if the host code was released. I have tried to 
look into the graphical part of R3, but I can't see, how I'm able 
to convert my code to R3.


(I'm sorry to say so, but R3 to me looks like a hobby project, not 
a serious business projekt.)

Geomol - you are completly off. I would not expect reaction like 
yours from person like you. Calling R3 dev. effort a hobby project? 
Where do you live, man? On a different planet? Sorry for being picky, 
but R2 dev. effort, compared to what we achieved with R3, is a complete 
joke, yet you call R3 being a hobby project?

Geomol, it sounds like you expect that R3 will never be able to do 
that. Why this attitude?

No, you misunderstand. I hope and expect R3 to be able to do that 
some day. I just look at the facts:
The project has been gong on for 4 years since 2005.
Where it is now.

When I can expect it to be in a condition, where I would begin to 
use it for real. (I've learnt to have very small expectations.)

I think that trying to get R2 View working properly under OSX will 
take longer than reaching the same goal for R3. I don't think there 
is much we can do in terms of speeding either R2 or R3 development 
up, so it's simply a matter of waiting until it's ready with the 
number of developers available to us. I don't want to disturb R3 
development with too much interference from R2.

Henrik, you've used R3 more than I have, I think. Do you remember 
my work on FITS files in the spring from my visit to the telescopes 
at Tenerife? I made images from the 16MB FITS files using R2. It 
took 1-2 minutes to compute one file, where it takes less than a 
second if using C. How do you think, R3 perform compared to R2, when 
it comes to brute force calculations?

PeterWood, I think that only a little step further is needed to have 
this. Developers want R3 to be used in REAL world scenario and do 
testing for passion; this is called "motivation". Even Carl admits 
the situation.  When CGI support, VID, and extension will be finalized 
expect an huge boost into test and debugging.

This "closed system" has nothing to do with source availability, 
of course. As an example, value lookup from words associated with 
function! contexts is 28% slower that of object! contexts, just because 
of the addition of one instruction for stack indirection.

it seems the word "closed" is too closely coupled to souce in CS.... 
by "closed system" I do put the emphasis on "system"  as in a chaotic 
system, like a complex frequency modulation patchbay or a closed-circuit 
video system where a monitor is in the view of the camera.

pekr... wrt shake... and what do you think the graph does ?  ;-) 
 


the graph is compiled in real-time everytime you change its structure. 
 you can create your own nodes and add them to the engine, using 
the graph itself as a visual development platform.


 as I said, I worked for those guys... I have an intricate knowledge 
 of how it works.  I also implemented a REBOL implementation of shake 
 callings its rendering engine and intepreting its (C) Header files 
 to integrate all the nodes.  :-)

... so you want to do in few months, what was not done in 12 years 
of View's existence? Cool then :-)

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

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?

no problem cyphre ;-)

just to explain: valid until means the bountie offer, not the
creation timeframe. it makes no sense to offer a bountie with
an unlimited timeframe to take.
of course the task can & should be made step by step without
any special due date.

so if someone is interested to do the job he should 'decide' until 
this date.

How do you get the source to the http protocol as documented here 
http://www.rebol.net/docs/prot-http.html

DevBase, aka chat. Be warned though - it was generated from a literate 
programming environment, so the source isn't structured in a way 
that makes sense to humans - only the generated docs do. Fixing it 
might require a full restructuring, which I have been working on 
in my available time.

Yes you do, because the .rlp was used to generate the original .r, 
not the current fixed .r.

You would include Needs: [charsets] in the header of the organizing 
script of your project. If we do it right, we might even be able 
to selectively import the words, though that might need some thought 
for loaded charsets - I'll give it some thought later, as mixins 
are currently file-based. I have an idea about how to do it though, 
in the preprocessor.

I think that the preprocessor will actually mix in the mixins itself, 
as if they were part of the original source of the calling modules. 
That way if you want to do selective import you would split your 
module into two, one that contains the shared stuff, and another 
that contains the local stuff that references the shared module. 
It's not as hard as it sounds.

of note, you are not supposed to look inside port in principle. so, 
apart from "playing" with it, you should not really expect to be 
able to do something like that.

How do you access make-http-request ?  What's the path to this function?

in what sense? how do you need to access it?

except from using print directly in the scheme code, there was no 
way to do that at the time.

one of the things i wanted to do, but never got to, was to parse 
the output of R3's trace, and then show you a step-by-step code execution 
like in debuggers.

Looks like everything is opened in binary mode as there are no refinements 
yet to 'open.


So, to implement a line oriented protocol like pop, do we read until 
we get a CRLF pair?

So you have to do a open tcp://host somewhere in your code

If you want to suggest a plan for better console, please do.

Graham, perfect for a third party to do (and has been for about a 
year).

We will need FTP. That is going to be a pain, but someone has to 
do it.

Henrik .. are you offering to do the ftp protocol?

If you're working with a line oriented protcol .. do you save the 
buffer to your own buffer and work on it line by line ( deline ) 
?

There's many ppl out there, who will want to try REBOL as a tool, 
and have ABSOLUTLY NO intention into coding some infrastructure things 
themselves. So - we can say such things as "do it yourself" in a 
community cooperative manner here, but let's not dare to present 
such opinions publicly ...