AltME groups: search

Yes, I know. But imagine me being an evil man. I will register with 
RT. They have their own CA, register me, give me certificate. I will 
do evil script. PPL will trust me, run the script, and damage will 
come. They turn to RT, and RT tells them - that developer is Petr 
Krenzelok. And I say - what? I never registered. So, the only way 
of RT to know I am who I am is, that I will visit some CA, provide 
some evidence (ID card, driving license, passport), and register, 
no?

What I am talking all the time about is - how to build trust in distributed 
environment. Some of us will need to produce scripts with lowered 
security. If I see a requestor asking me for lowering security, I 
will not run the app, unless I can be sure, that it comes from Gabriele 
for e.g., and that if Gabriele ruins my HD data, I can visit DevCon 
next year and ask for refundation :-))

a digital certificate is just like a paper certificate - the value 
depends on the issuers, and the parties involved.

so, if rt can identify me (eg in person at devcon like you say) and 
tell you via certificate that a script is really from me (identification 
+ authentication), you can then trust the script if you trust me

that is why I think we should think about signatures (which is just 
a hash) and certificates in a bigger picture - mainly when we think 
about SDK apps or browser plug-in apps with lowered security level 
... the truth is, it does not need to come with initial release, 
but should not be forgotten about.

that probably mean at least one thing - you are part of early testing 
group. So, now off to private chat and prepare for being investigated 
:-)

Yes, in this context, "gob" is someone's mouth, and smacking is raising 
your hand suddenly to your mouth, as you would do when surprised.

yes, it is half a time between the first and second developer's release 
- so, guys, give us unlucky some spoilers :-)

Pekr, there just has to be absolute certainty that low level things 
are working correctly and that nothing is missing before moving upward, 
so there is a lot of testing and scrutiny going on right now. And 
it's booring. :-)

And about me..

test - got "Internet busy" status and my message did not appeared 
here ...

so, AFAIK, Max is not here, and I did not ask him. Well, what i wonder 
even more is - why guys like Volker are not included :-)

hehe ... are you sure you are not in the beta and teasing others... 
acting as if you arent' on the beta?

and if I where part of the beta, which I might be but acting as am 
not, would I tell or would I just be acting as I am not... then again, 
maybe I am just trying to appear to be making up this denial, in 
order to look as if I really am not, but trying to appear that I 
am in a false positive kind of way.   :-D

yes and someone put a huge gauss blur on it

we need someone willing to play with schemes and mainly test http 
and so on. anyone? you need some free time and possibly some understanding 
of http so that you can give better feedback ;)

Petr... and you think I would not have added him already if he had 
time? :-)

but only week and a half to finish the strategy

and as for July, I will be just few days at work, then vacation, 
most of it off-line (rock festival for few days, High Tatras from 
21.7., but that time, it should be already a public beta release 
....)

task! works but is not complete functionality-wise (and has some 
bugs)

ah, I thought that task is easier part - "just" starting threads 
... well, then that mutex:// thing, and internal isolation of "contexts" 
:-) Hmm, maybe complicated enought to be difficult to implement ...

I've made a layer demo to test performance in R2 and R3. The demo 
is coded for R2 using FACE, but I guess you guys can easily convert 
it to R3 using GOBs.

do http://www.fys.ku.dk/~niclasen/rebol/test/layer.r


Use mouse to move squares around. Right-click a square to remove 
it. In the source, you can change the offset and size of the window 
in the beginnig, where playground is defined. The demo produce 100 
squares. A little down, there is the
loop 100 [
Change that to have more squares.
I hope, it can help.

I think that Rebolek did some 1000cows script, and reported difference 
was 2fps for R2 vs 20fps for R3 gobs version ....

Yes, you can do http://bolek.techno.cz/reb/1000cows.r, works both 
in r2 and r3.

I've got about 15fps with 1000 cows and 2 fps with 2500 cows (default 
cow-count when you download). R3 can do about 20-25fps in both cases 
on my machine.

According to http://www.rebol.net/r3blogs/0076.html, in REBOL 3, 
CHAR! is a 8bit and 16bit character.


This could be problematic, I guess. Why don't we have two different 
datatypes instead: 16-bit CHAR! and 8-bit BYTE! The 16-bit CHAR! 
is in UTF-16, just like Java.

STRING! is BYTE! string.
UNICODE! is CHAR! string.

How you you think about that?

Not that I need 8-bit chars. I just think that 8-or-16-bit chars 
could make things complicated. They should be of different types, 
or something complicated could happen, such as:

>> insert a-string char8
>> insert a-string char16


now, a-string contains both 8-bit chars and 16-bit chars. How would 
I deal with that.


Since REBOL 3.0 seperate STRING! and UNICODE!, I think that seperating 
BYTE! and CHAR! could be helpful. Let STRING! contains BYTE! only, 
and UNICODE contains CHAR! only.

This is a good question, actually. We need abstract datatypes but 
we also need concrete bitfields, and we need to be able to treat 
certain common values (char and integer at least) in either way.

doing some work on documentation and reading about the vector! datatype

I don't know if they are surprising, they didn't take long to get 
in, and I don't know if they'll stay, but a few mundane things that 
are difficult to do in under 10 lines in R2 can be done in 1-2 lines 
in R3.

ah, nice ... I found that Python has very nice block handling too, 
and I found some operations, which were not possible so easily in 
R2.

I hope rebcode is there already? :-) And that it was improved? And 
also that parser got some improvements, which were suggested for 
years? (not by me, but by others :-)

I think the main focus will be to make a good .dll core for now with 
a VID prototype. Getting that right first will make plugins, rif 
and all that easier.

and rebcode is there same way as unicode

I tried a lot of the bug reports in RAMBO that crash R2 just for 
fun, and R3 handles them just fine. Of course the code has been rewritten, 
so you can't make a direct comparison, but it looks to me as Carl 
was going through RAMBO in order to avoid making those mistakes, 
or the code quality has just improved for R3.

Henrik - it was the same with R1 vs R2 ... R1 was slow, it did not 
contain even networking, and was some 400 KB big. Then came secret 
Contra project, later released as Core 2.0, and including networking, 
it was actually some 150KB in size, much more stable and much more 
faster ...

I don't expect R3 core being any faster, but hopefully it will be 
natively extensible, and some strange GC bugs will be gone, or at 
least debuggable ...

My biggest fear is when R3 comes out... it will have so many new 
things, areas to cover, projects that will be made possible. It's 
seriously going to require at least 50 people to cover it all, and 
it will take a long time to cover it all and I think R3 will be vastly 
under utilized for the first 1-2 years, possibly longer, if people 
won't join up to fight for the cause.

It's amazing to think that this little nucleus that is R3 will make 
all that possible. I keep thinking that if PHP is a firecracker, 
Python is a handgrenade, Ruby is a box of dynamite, R3 will be a 
nuclear bomb.

But I understand what you mean. At least I think I do. Simply put 
many things are being put outside the rebol.dll and it is upon community 
to finish them. I just fear that Rebol has so bad reputation for 
its deployment inabilities, that we will not gain new ppl so easy 
...

but Bill Bucks try to help us, spreading the word, and also Syllable 
does a good job for us. Noone says bad word on Rebol on osnews, because 
if gurus from Syllable team decided to use it, then it must be a 
good langauge :-)

I would like View to become new cross platform gui toolkit, as Qt 
is, GTK is, etc., and if ppl would find it easy to use, especially 
to create non-traditional UIs, then actually we will have something 
nice in hadns ... it all depends upon VID completness. I hope it 
reaches at least state of RebGUI ....

well guys, I know how to attract ppl. One article, with one web with 
rebol plug-ins, and few demos. Give me that. Show ppl apps like Deluxe 
Pain clone, and they will like it ....

Henrik - is there some nice demo already? I would eg. would like 
to see particles running on R3. Should not be difficult to port, 
and could show general speed improvement :-) Maybe you could take 
short videos of R2 and R3 versions to compare :-)

Therea are no really interesting demos yet and we're not supposed 
to do benchmarks (even though we do for fun), since some debugging 
code is still present. I think also there is no hardware blitting 
yet in R3 View. R3 DRAW seems to be about as fast as R2 draw for 
now.

and will there be one?

Every feature without exception needed to be explained, and actual 
working examples given---scripts that demonstrate that feature in 
a clear and simple way.

the new dictionary will have Wiki features and possibly a comments 
section.

That will help, but the docs should be modified by the coders as 
the code is modified and what it does is still fresh in their minds. 
The very scripts they use in testing a feature could become an example.

well guys, I know how to attract ppl. One article, with one web with 
rebol plug-ins, and few demos. Give me that. Show ppl apps like Deluxe 
Pain clone, and they will like it ....

well, it all depends when you want to release. I think that for R3 
to be feature complete, and I mean all those plug-ins, rif, rebin, 
unicode, it will take another year to be there ....

I think, we should read it as: at of 6-Jul-2007, the beta was delayed 
a couple of weeks. I have a feeling, there is being hard work going 
on, but it could be delayed yet more. We'll have to wait and see.

btw - Python is going to get 3.0 version too, release mid 2008, and 
Guido says it will break many code. So our schedule is still ok, 
although Python is already ahead in some areas ...

Carrot? So are we going to call a release Rabbit? :-) Knoc knoc, 
Neo ... and Neo sees rebol console on his monitor :-)

Question: How useful would you find the following, and what other 
aggregate funcs would you find most useful? 

fold: func [
	block [any-block!] "Block of values"
	accum "Accumulator value" 
	f [any-function!] "Function to apply"
][
    foreach val block [accum: f :accum :val]
]
sum: func [block [any-block!]] [fold block 0 :add]
product: func [block [any-block!]] [fold block 1 :multiply]
average: func [block [any-block!]][
    if empty? block [return none]
    divide  sum block  length? block
]

geomol, that kind of function is called FOLD, and we're hoping to 
have it as a mezz in R3.

and, please remember that august 1st is our internal deadline, not 
a public statement. so, there has been no announcement about the 
beta being august 1st. i hope it will be around that date because 
that is our deadline. only Carl makes official announcements, unless 
noted otherwise. :)

Is there a theoretical difference between FOLD and MAP?

I guess, it comes down to temperement and programming style. Expanding 
existing functions would mean:
add 4 [1 2 3 5]
adding new functions could give:
sum [1 2 3 4 5]

New functions means more words to learn and remember. Benefit is, 
that it's maybe easier to read the code. hm

SUM is a standard term, and a common aggregate func. It could be 
a shortcut for "add number block". Generally, I like the idea of 
"overloading" funcs to make them smarter, e.g. a dialected version 
of EXTRACT is high on my list, but it's a fine line, and each choice 
has to be made carefully.

FOLD vs MAP - FOLD accumulates, while MAP applys the func and returns 
a series of results.

geomol: the problem is, that there are at least two things that add 
4 [1 2 3] could do. and, i think the most "natural" would be for 
it to result in [5 6 7].

It's a little buggy ATM and needs more features, but the resize algorithm 
resizes the UI, no matter what you resize: the window or an element 
in the UI. So if you have a box in the middle of the window with 
stuff around it, and you make it bigger, the other elements are automatically 
displaced.

I just really hope that new VID will be fully featured GUI system, 
and that it will support most things needed to do larger business 
apps ....

It looks like mix of Amiga OS and some old kind of unix flavor .....

and it will be up to the community to complete it

I hope so ... as for actual look, I don't care much yet, as it can 
be fixed by some gfx artist later. I care more about subsystem as 
keyboard support (focusing), visual representation of focusing, disabling/enabling 
ui elements, flexible resizing, on-something handlers rather than 
one feel func, and self-encapsulated styles - no external dependencies 
....

Henrik - do you find gobs to be more difficult concept than faces? 
Or is it just that gobs are new, and you have to switch your thinking 
to the new concept?

keyboard handler? it needs to improve - there were no key-up events 
iirc, and also some very basic and needed key combinations to be 
supported - ctrl tab - this one is really needed to switch between 
tabs ...

Pekr, GOBs are more difficult, because they are more flexible and 
low level, so if you want to build just a three layer face of a color, 
a text and an effect, you need 3 GOBs. You need to define them and 
then put them together correctly. But there will likely be a simple 
way to build complex GOB setups skin makers, perhaps a dialect, so 
the outcome will be simpler than it was in R2.

I prefer non OS look, own style, which will identify rebol app. Definitely. 
All claims of otherwise I find false and unsupported by reality check. 
But I don't probably want my app to behave differently keyboard, 
focus wise, etc. Could be tough to achieve, as I remember OS-X has 
its own specifics :-(

graham: the dialect is different, because it uses new dialecting 
methods from r3. also, the layout is intended to be abstract rather 
than concrete (ie you don't normally specify the size of things). 
the rendering is fully up to the "skin" and not to the layout dialect.

so you want altme to open up some big window and have altme windows 
inside it?!?

ie. i can make a "screen" panel style and a window style.

geomol, i'm sure cyphre knows about it, but i don't think we're going 
to explore that anytime soon. we have key-up for control, shift, 
and so on already.

yes, i get event/key: #"^-" and event/flags: [control]

Gabriele - re plug-in - it is different kind of app. But I would 
hate any single window to pop-up, even for simple dialog. And I mean 
to that extent, that I would ban such app, or it would be blocked 
by some add-block kind of extension anyway.

ok, but if you think about your app, you need dialog box, right? 
And what did currently R2 plug-in did? It popped-up in front of your 
browser ... that is not good. So to avoid this, you need something 
like windowing styles directly in VID level ....

But you are right that it can be solved by creating such styles ...... 
have you seen portals? Big ones? E.g. websphere? User has one website, 
and it has kind of small windows (javascript probably), which can 
be moved, resized, maximised, minimised ....

Pekr, in the plugin, you specify an initial window which appears 
in the browser. You are not allowed to open new OS-level windows, 
therefore if you want to open new windows they must be VID-level 
windows. How do you do that ? You add faces to the first face's PANE, 
 start calling them "windows", and use code such as Cyphre's SWIS 
system to implement it. Simple as that.

Petr, Windows allows having windows inside windows. but even if it 
did not, the host code can easily emulate them using the same code 
that handles gobs and so on (that is, no extra code to write).

i don't think, users should have to switch between using view many 
times or one view and adding window faces to the pane. the host code 
can do this easily enough: the screen-gob isn't the screen anymore, 
but it becomes the plugin window, and the "window gobs" you add there 
create virtual windows inside that.

Gabriele, I understand the fear completely and it can be a little 
frustrating to be kept in the dark for a little while longer. :-)

Does SWITCH need a /case refinement like we have in FIND and SELECT?

... as for multiple screen, my experience is as follows. Under Windows, 
multimonitor set-up is an ilusion. You can find it out, once you 
use e.g. VNC and connect to such a remote desktop - you can easily 
see one big screen. The interesting part is - even if one of your 
displays is moved 90%, it is still one big box of x*y size.


So, in regards to REBOL, I think it would be vital to being able 
to identify multi-monitor set-up, and not one big screen face. My 
expectation is to have screen-face having two (or more, according 
to active monitors) or more subfaces - desktop windows ....


It would be good to get correct behavior in that regard from the 
very beginning ....

hmm ... maybe we should at least have some strategy. Simply we should 
be prepared that screen-face is not screen face, but kind of desktop-face 
.... it should be indexed [1 [screen here] 2 [screen here]], it would 
be on pair with how driver identifies primary and secondary monitors. 
Not sure all drivers do it the same though, I mostly use nVidias 
.....

Petr, I have two monitors here, one 1600x1050 and one 1280x1024. 
screen-gob size only reports the first, but I hope we can add support 
for things like these soon enough (not for beta).

about it being i single big box - it is so on linux too, and i'd 
assume it would be so in all OSes that have legacy to maintain, but 
it depends on the desktop mode too.

hmm, if you have two monitors, maybe you could try "a trick" :-) 
try to place your window "off-screen" and watch, if it appears on 
secondary monitor? :-)

yes, i can move windows around the two monitors. i have this altme 
window in one monitor and other two on the other monitor.

... and if so, could we at least get some preliminary (one week before 
release) access to docs, to read some things and being prepared to 
jump on R3 more quickly?

i can have windows "in between" and so on. it's just one big framebuffer. 
if i do a screeshot, i get a big 3000x1000 image.

mainstream OSes do not support multiple monitors very well - they're 
mainly hacks. the way R2 and R3 work now, you only "see" the first 
monitor, but you can still move windows to the second one. this is 
not too bad, because windows get centered to the first monitor if 
you use center-face instead of being between the two monitors (which 
is bad, and some apps do that). so altme always opens on the first 
monitor, because it thinks the offset it saved in the prefs is offscreen 
if it was on second monitor.

yes, I used and a bit extended Gregg's keys dialect. I was able to 
shape and move windows by calling win32 api functions. I tried to 
wrapp also the monitor stuff, but if was upon my capabilities ....

btiffin - I am not sure I want R3 to break anything :-) But it would 
be nice, if programmer would have easy option to investigate state 
of monitor set-up, and eventually decide where to send the window 
to.

So aside from being coded to be "friendly" to any exisiting multi-montor 
display managers, there isn't much REBOL could do...at least not 
cross-platform...in my humble and zero experience opinion.

it could detect monitors ... they are often numbered 1, 2, 3 ... 
and their orientation, resolution :-) Then we could have 1, 2, 3 
etc panes to post our apps to :-) That is my very unexperienced opinion 
too :-)

Gabriele - you mentioned "skinning". Will basic VID3 design be vector 
based, or still bitmap based? And will it be upon "skin" just to 
skin existing element, or will skin include also code of how to draw 
the element?

i think, where windows go should be left to the user. what's important 
is that rebol does not try to center windows incorrectly, or to clip 
them to the first monitor and so on.

skinning is completely abstracted and you can have whatever look 
for the styles. currently we only use draw, not images, but some 
styles may require images. anyway it depends on the skin, vid does 
not care at all what you do.

(i personally prefer parse, but the new one is more efficient and 
so better for simpler dialects like vid etc.)

i share your pain, i use wine all the time, and there is actually 
one bug in r3 on wine that forces me to start the other pc with windows 
sometimes.