AltME groups: search

REUSE might run into problems with multitasking. Ladislav has talked 
about adding a native atan2.

Probably should be implemented with a closure!

Yeah, a closure that returns a function is a good pattern. However, 
a closure by itself won't reuse the block. It's the reuse that is 
the problem - the block probably won't be task-safe.

but it has to reuse the same block, in a context

Fortunately, "or somethoing" includes wrapping a server task around 
your data. Shared service rather than shared data.

Nice work Steeve! I'm glad R3 gradient improvements in DRAW were 
useful. It shouldn't be a big problem to render SVG using R3 draw. 
Bigger issue is to be able to parse all the possible SVG content 
you can find on the net ;-)

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 :-/

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

i would prefer a silent functions which actually doesn't draw anything, 
but only returns the coordinates of the bounding box, or the coordinates 
of all pixels de traw (good idea btw).

COORDINATES draw-block.

return a block of pairs (coordinates) of the pixels to draw 
Carefull, may be really huge.
Perhaps a mask is better (an image or a bitset)

COORDINATES/BOUND draw-block

return only the min-max coordinates.

Well well...

but it means the internals need to have a persistency added to them, 
which definitely changes the architecture.

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.

I would also like tuples with a bigger scale.  something like 16 
bit color values...

A View proposal would be good, but we need to compile more information. 
We already have the GUI proposal.

Like the Parse Project page, we now have a View Project page:

http://rebol.net/wiki/View_Project

Please fill in your proposals.

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

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.

Here's a good start: http://rebol.com/r3/docs/project.html

4. Modularization of the built-in code (might be more of a personal 
project)

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

Wrapping UnixODBC in an extension would be a good idea, though that 
likely falls in the category of a third-party or community project.

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.

Opening the host code is definitely a short-term priority, before 
or during the beta period.

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.

Sqlab, a better console for Windows requires the GUI to be built-in, 
not in extensions. The GUI would be used to make the console.

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.

BrianH: that is not a good solution. If we want a good one, let's 
have it at least in R2 level. If you want the raw one, you HAVE to 
count on the default Windows version. Suggesting ppl to download 
xy MB crap is not the way to go to try REBOL at all ...

System admins won't be able to use a GUI console at all - they need 
a version of REBOL they can call from batch files.

On the other hand, the R3 console isn't that great by Windows console 
app standards - it allocates a console even when started from one. 
It really needs to use the console it was started from if any.

As I noted, I would be back in a few hours. So... here I am.

The current top priority is to get stdio working properly.  For Windows, 
this is a pain, but for everything else, it's quite easy.

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

1) portable fot system working with VID/draw

2) better way to handle events directly in draw content ? (don't 
know if this would be a gain or not)

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

A few quick replies...

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.

R3 is too buggy for him, but I think he has not considered himself 
getting a chance to fix those bugs. If he has a chance, maybe he'll 
change his mind.

cause its buggy, cause I've got no time for release 

surprises" nor can I use all of the several MB of code I already 
have which works in R2. going to R3 is a big endeavor for people 
like me who have a lot of code to convert." - Maxim

i'm interested too (cause i already made a partial svg converter 
for R3 ,see http://sites.google.com/site/rebolish/test-1)

But i'm afraid i will be disconnected from rebol stuffs during comming 
weeks.

Well, a "limited release" of the main host source is not entirely 
out of the question.  Meaning, released to a small group.

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

Cyphre told me that he is waiting for actual sources. So maybe giving 
him the latest host source would be a good start.

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.

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, listen to the chorus: Release some source, even if it is a 
limited release to the interested-and-qualified-helpers. You need 
help :(

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

is it still a mezz in R3?

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.

So, here's a rough game plan...

yep.  I also have a mac-mini now, so can also do some test on that.

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

That's a big topic. One we should move elsewhere, because it's likely 
to be many pages long.

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 a note - COMMAND. I was thinking lately, if the word is not 
too good to be used for extensions? Commands fit dialects. I thought 
that we could use ROUTINE in Extensions. But I know that it might 
be late for the change, or that I have maybe shifted understanding 
of what "command" word actually means ...

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.

It is a language author call imo ...

the case is to have a core group of people improving the host in 
parralel.

yes, I understand ... for later, maybe. But as for initial release, 
I would prefer Carl to implement (in regards to extensions) what's 
on a priority list. Believe me - if you shoul Carl, that maybe one 
day we have some ideas here or there, we will not get it for 3.0, 
as Carl will move onto other things.

If a few of us take up the task of managing all of the extensions/device 
interface code, that means Carl can work on other things.  Carl has 
already given us a reference on his idea of how to integrate native 
code into R3.  I wouldn't have done it any differently, honestly.


in any case, we will discuss it with Carl before commiting to any 
time to implementing it.

Exactly - we should be sure, that the design aspect is acceptable 
for Carl, in order to be accepted as a default part of the distro. 
The last thing we need that in such an initial stage, we will end-up 
with one host layer per one developer ;-)

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

devices could also be used for things like IPC or callbacks.   so 
we could test out different ways to improve multi-threading in rebol 
before commiting to a specific method.

We finally own a corner!

when rebol came out it was hands down the best parser implementation 
out there... 10 years later the rest of the industry is catching 
up to it.  We've pushed it a little further again.

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!

there is such a reward, vote for him in the user.r group ... right 
here in altme  :-)

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

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.

REVERSE, LIMIT and OF (but renamed I hope) are still on the todo 
list, and I really want all of those. My biggest pie-in-the-sky requests 
have been done though (with the exception of USE, which I have a 
workaround for).

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.

The main change is to move HOST Source to a higher priority.

BSD or MIT... yes that is exactly what I proposed... it it VERY well 
coded and exceptionally small the whole putty app is in fact smaller 
than rebol.exe IIRC :-)


it has a LOT of goodies beyond a full SSH2 encryption set and EVERYTHING 
is stand-alone it relies on no external dll or libs.

yes https should be on the list... as a separate scheme, or a config 
of the http scheme as it was on R2

SSL is what you need. HTTPS would happen as a side effect.

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.

BOUNTY:
Offered by:
	Janko Metelko

Task

 Open source code for OpenId consumer that handles a shared secret 
 authentication (not dumb mode).
	http://wiki.openid.net/Introduction
Amount
	$50
Terms
	Payment via PayPal

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

Does the web cam have to display inside a Rebol window?

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?

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.

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

if someone else is interested in unlock these cool protocols for 
R3 
please add a small amount  to make it more attractive...

offered by:
	TomBon
Task:

 R3 - Bindings for a KNNL - SOM (Self-organizing map) /Kohonen Network
	http://knnl.sourceforge.net/

	API - http://knnl.sourceforge.net/html/index.html

	Further Readings:
	http://en.wikipedia.org/wiki/Self-organizing_map
	http://www.ifs.tuwien.ac.at/dm/somtoolbox/
	http://accu.org/index.php/journals/1378
	http://www.codeproject.com/KB/graphics/som.aspx

	Alternativ:
	Quick Tutorial on how to construct a SOM.
	Perhaps to create a modul directly in R3?
	http://www.ai-junkie.com/ann/som/som1.html


Amount:
	$350
Valid until:
	01.04.2011
Terms:
	PayPal