World: r3wp

I really like new march plan - finally some low level Core stuff 
- rebin, plugins!

yes, looks good

It says no ReBin yet

Yes, no rebin yet, but that it is planned for march, because of low 
dependenices, and because it is needed for host code to be released 
.... ?

I just visited AGG newsgroup after one year, and some interesting 
projects do emerge. Community agreed that any open work will be done 
to BSD version (2.4), which is a good sign (although RT has probably 
no problem obtaining special license).


Dunno why, but there are (apart from Cyphre) another few Czecho-Slovak 
guys, and one of them is doing rather interesting project. AsmJIT 
and BlitJIT libraries, with MIT licence. Author says about it:


Antigrain is great piece of software with great licence, 
but without 
better acceleration it's quite slow.  So blitjit can increase speed 
of 
your applications in way you can't imagine. For example is there
complete 
MMX/SSE2 extension for antigrain ? No, but don't panic, other
libraries 
also have problems with cpu specific features.


The reason why it might be interesting is, that generally there is 
no good 2D HW acceleration out there, and here is what author of 
LibNUI answered to Cyphre:


I'm the author or nui (http://libnui.net) which is a GUI toolkit 
based  
on OpenGL (and now OpenGL ES / Direct3D). This project was 
started  
some 8 or 9 years ago and I've been working on it and with 
it amlist  
daily for that time. My experience is that it's some 
orders of  
magnitude harder to have HW support for those features 
that to add a  
JIT to your engine in order to optimize your bottlenecks 
(I've done  
some of that for pro audio dsp code). The reason is 
that no two chips  
work exactly the same and behaviour even tend 
to change over driver  
releases. To diferent cards, even sometimes 
from diferent vendors,  
will not give you the exact same scan convertion 
or rasterizing, and  
I'm not even touching shaders diferences...


It seems to be x86 only so far, but maybe guys like Cyphre or BrianH 
or Anton or anyone skilled in those areas should keep an eye on those 
guys :-) Here's a link:

http://code.google.com/p/blitjit/

... as for those another AGG based Czech and Slovak projects:
http://www.rw-designer.com/
http://www.crossgl.com/

Shouldn't we get those guys hooked to REBOL? :-)

Can someone see the private message from Ernst on RebDev? He posted 
to admin question why he has so low rank, but I could see the message 
and reply to it.

I don't see it. which number does it have?

it seems the rank of 10 is standard for new users.

Petr, cool links. Yes, I think we should get them into Rebol.

Henrik - 2756, 2757

eh, first one is 2755

I don't see 2755 and 2757.

how do I post private message to Carl?

pp carl

hmm, private messages are folder dependant? What is difference in 
pp vs pu?

they should not be folder dependent.

I had not noticed the 'pu command, but I guess it would be a public 
message stored in the folder for the user.

Hmm, then message is  misledading? I do pp Carl, and the header states: 
"posting private message in #thread-number-here ..."

ok, what if you try 'pu carl?

Enter private message in #8

ok, then pu is for private messages in his folder, while pp is for 
private messages in the current folder.

makes sense ...

Henrik - as there is not much comfort in RebDev chat - not using 
other gob types contradics their purpose, no? I do understand, why 
keeping GUI desing simpler might have advantages, but stating that 
effects are not needed so far, because Draw dialect can serve us 
well for GUI purposes, might also mean, that we could discard effect 
pipeline? :-)

No, it just means that I have not needed effects yet. I think they 
should definitely be possible, but we have to be careful not overexposing 
it. MAKE-GOB could introduce a level of control that we don't want 
in a style, making a single style a big mess with hundreds of lines 
of code, because you have to reference GOBs.

So far GOB management happens in 20-30 lines of code in one specific 
place in the R3 GUI design. It's very tight and controlled and by 
adding an effects GOB there, would make sense in the R3 GUI design.

Maybe it would be best to add 'effect and 'rich-text functionality 
to draw directly, as image is there too anyway. Would make it for 
one combined pipeline. Dunno how it would make low-level implementation 
more complex. Then we could discard other gob types ....

I note that in JS we can fade in visual objects ... will that be 
easy to do ?

Dunno, but I would like to have transitions and wipes available. 
It could be done even nowaday, just look at Jeff Kreiss present.r 
script. IIRC it is available on rebol.org. It contains whole dialect 
for movement, fading, etc. What I worry about is - low speed of REBOL 
for such stuff, at least in REBOL level and without Rebcode, we can 
better forget it. We also need to implement different type of timers 
etc. But generally - dunnof if we can get smooth results without 
real HW acceleration ....

Graham, each GOB can set its alpha channel with 1 integer directly. 
I don't think this is exposed in the UI yet, but it wouldn't be hard 
to do.

Do you think that gradients could help us with progressive fade effect? 
I mean - not fading whole gob, but because of using a gradient, it 
would look like progressive fading. Well, for real transitions (and 
there are few demos out there), anything REBOL based (e.g. pick/poking 
pixels) is gonna be slow, unless implemented directly as an effect, 
or unless Rebcode in new form is back ...

I hope gradients for lines drawings will be implemented ...

I'm not sure that would be simple to do unless you do it directly 
in DRAW, but then you will need gradients for lines, which we don't 
have yet.

It would help if GOB alpha was calculated per pixel as an effect 
and then we could do real alpha masks, but it isn't.

So - where do we write down our wishes for Cyphre to implement? :-)

Somewhere in rebdev. We have a high level GUI thread there. Might 
as well create a low-level one too.

I was thinking about CureCode for a while, as a "wish" requests, 
but not sure if we should "flood" it with such a stuff. Maybe a RebDev 
is better place, but Cyphre might not read it, because of its, well, 
"comfort" :-)

Just wanted to look-up some info about ReBin, as it is mentioned 
in recent March R3 plan, and found out following article:

http://www.rebol.com/article/0044.html


Pity it is almost 4.5 year old one. Hopefully we get it in upcoming 
months, as some features were really planned for ... sooooooo long 
;-)

Ah, damn, another big restructure of DocBase? :-) While Docs become 
more readable and graphically nicer, the person doing restructuring 
does not even distinguish Gabriele's GUI to Carl's one, so it really 
becomes an organisational mess and he ruined Carl's initial Docs 
for GUI ...

Can we somehow contact Kr bacon?

Is that _the_ Kevin Bacon editing R3 docs?

Question to R3 people:
In R2	>> LIST-DIR %/c	<-- will crash R2.7.6 
In R2	>> X: %/c

 >> LIST-DIR X		<-- will ask a security question to allow, and then 
 return desired results

In R3	>> LIST-DIR %/c	<-- will return desired results (no security 
for alpha R3a.37)
	>> X: %/c

 >> LIST-DIR X 	<-- will give ** Script error: invalid arguement: 
 %X
	>> LIST-DIR :X	<-- will return desired results.

Why do I need to put a : in front of my variable in order for LIST-DIR 
to work properly?  Doesn't seem to be intuitive, does it?

because of how path is defined (as parameter) in list-dir.

func [ 'path ...] instead of  func [ path ...]

don't know why this choice

Thank you Steeve, for checking into this

perhaps to allow this semantic:
list-dir c
instead of list-dir %/c
but it doesn't work

sh

sh

Steve, I'm trying to "capture" the source of LIST-DIR in a separate 
file, but I don't have the syntax quite right.

R3	>> SAVE %listdir.r SOURCE LIST-DIR	<-- donsn't work, I'm not sure 
how to sturcture this command

I got it
SAVE %listdir.r  :LIST-DIR

Try
  mold :list-dir
to get the source in a usable form

yep

Interesting,  MOLD :LIST-DIR returns the results inside of { }, where 
:LIST-DIR doesn't