AltME groups: search

Perhaps a simple way to do this would be to implement double buffering 
by default and allow buffer access.

view probably is double buffered - but getting access to that buffer 
is something that im not sure we can do

would you consider it a good idea for 3rd party developers to make 
an RTF importer or will RT do that?

Max has to do better.

Graham... hmm... you used logic in some discussion, that is a very 
bad thing to do, as Terry and Louis teach us.

was thinking mainly for when we get an IDE and want to do code block 
folding etc.

you need to add platform specific things - that is, the devices. 
otherwise, the rebol code would not be able to do much (no ports)

yes, so you have to port also the platform specific stuff. How do 
you that e.g., if you want link-in REBOL into your delphi app, to 
be able to do e.g. do-rebol("some script here")?

perhpas someone has the answer to these questions? -> 

* Is Rebol3 a product beside or instead-of current Rebol?


* Is support still valid for Rebol2 products after release of Rebol3?

* Do puchaged licenses still work on Rebol3?


* Do commercial SDK / View / etc.. users need an upgrade? does it 
cost?

* Will Rebol2 product be still enhanced?


* What is adviced to do? Stick to Pre-Rebol3-versions or go with 
Rebol3?

if that was the case, then we'd need to have everything built in. 
do we want ajax js libraries built in because it does not help anyone 
if cgi authors have to pick them themselves?

then you misunderstand, what is important, and what is not.

 -- I think Gabriele misunderstands very little. :-) The thing is, 
 it's all about compromises. What is important to you might not be 
 important to me at all, and vice versa. So how do you choose what 
 to include, and how big is too big for REBOL to be? 


If something is wanted and needed by 80% of the community, or 0.1% 
that's doing something really important, those are easier calls to 
make. Many features have doubtful value to at least some people, 
but we can't use those as justification for adding other things of 
doubtful value. So, I want a good voting system, and tracking for 
new community mezz funcs, to see what gets used the most; what people 
want and need.


That said, I think security is so important now that anything we 
can do to make REBOL a better tool for writing secure systems is 
a good thing.

I am not sure I am confusing anything. If it is not there, then it 
is not there. I can give an example - Bobik - he left rebol, because 
of our often claims, that we can do anything. But he is looking for 
the end user tool. He does not want to code mySQL driver himself, 
he wants to use one. So, if you will have website with rebol features, 
what will be your answer to following bullet:

certificates support: 


Yes, or no? Am I able to easily send rebol email, signed, which displays 
in Thunderbird or Outlook, as signed? Am I able to choose from centrally 
installed certificates in Windows certificate container? That is 
my point. So - if it is only 3 lines of code, just take a note, and 
when RT will be thinking of security/privacy issues, please count 
such things in?

send signed email - yes you can do that. does it need to be in send? 
should send also handle return receipts? should it handle gmail apis? 
should it handle exchange servers? where do we stop?

Whereas guys from Delphi crowd were able to do that. Now you can 
blame me, that I was not able to make it. REBOL nor its community 
did not work as enabler for me here. And I can see only one sensible 
way to avoid that in the future - projects domain, bounty system 
...

now... why not having x509 parsing in rebol? that's surely possible 
and probably a good thing to do. but, tomorrow you'll find something 
else that's missing.

I remember exactly the same discussions when Terry was proposing 
RASH - we claimed we could do everything Flash can. Yes, in teory. 
But there is many ppl, who look for new tools in internet era. Some 
of them, don't want to code drivers etc. themself. In fact - they 
choose upon what is available. To avoid this situation, I propose 
bounty system, it would be vital. So guy like me could take some 
money and sponsor some development.

I know - but do you think ppl will trust some home made CA? I thought 
that I will come to one of three CAs here, and will ask for commercial 
certificate (dunno who does so internationally - Thawte? Verison?)

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?

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.

maybe, but not sure yet. it could just be that it has incomplete 
vid. or it could be that we are able to do it quickly...

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.

Kai, my point is, I don't want an atomic type (which is CHAR!) to 
present two different sizes. I don't want to write my code like the 
following:

myfunc: func [ ch [ char!] ] 
[
    either ( size? ch ) = 8 [
        ; do something about 8-bit char 
    ] [ ;
        ; do something about UTF-16 char
    ]
]

not been covered? What do you mean? New features, which are going 
to be a surprise? :-)

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.

Rewrites are a healthy thing to do. :-)

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

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.

Petr, Syllable doesn't have a Czech translation yet. I would think 
Syllable should be suitable for your country. Wouldn't you like to 
do a translation? Later when we have R3, you could do some joint 
promotion

there is a method to do that in R3 already. :-)

Thinking a little further, what if I want to add all the values in 
a block. With my suggested ADD function, I could do:
>> blk: [1 2 3 4 5]
>> add blk/1 next blk
== 15

But that's clumsy. With JOIN, we also have REJOIN. So if we have 
this new version of ADD, should we also have a READD? (Bad name!) 
Example:
>> blk: [1 2 3 4 5]
>> readd blk
== 15

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

Proper even spacing between UI elements. I think the window also 
sometimes does not resize properly, if content is resized. I may 
have missed some ways to do things in the layout dialect, so I may 
be wrong.

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

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?

Henrik - is there a concept of window in new VID? As I said - I would 
like to have one. We should decide upon what will view/new do. I 
am not sure I want it to open new OS level window. That will make 
plug-in apps suck big time. I would welcome the choice - for desktop 
apps let it be e.g. OS window, for plug-in, VID windowing ....

Gabriele, do you (or other in the R3 dev team) know about GLUT? It 
may be a fast way for you to have e.g. key-up events on all platforms.

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.

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.

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.

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.

Gabriele - one of your past discussion was also so called two-ways 
functionality. I mean - after you do layout in R2, from the "live" 
state, e.g. by moving UI element, get it back to layout. So once 
you relayout you loose that info. Could that be solved?

not sure I want, not sure it would be usefull. It is just that I 
remember one product which claimed to do something like that ....

Neither do I, but for an R3 beta I'll boot one of the boxes to...windows(tm). 
 Rasafrasa.

Henrik - you know me and you know what I fear - pekr coming to final 
r3 VID, playing with it for few minutes, asking - how would I do 
that? And getting the answer, that it was not inteded to do such 
a thing and that it would require VID rewriting :-))

brian, I'd start adapting simple scripts from R2 to R3. Do that by 
adding multithreading, adapting to async HTTP, etc.

we can link to SDL with Core, no? As others do. We can link to VxWidgets, 
if we wish to, no? View is simply yet another gui engine ....

AFAIK the plug-in interface is not yet finalized so it is too early 
to discuss ho this will be exactly exposed.


But there are more things to consider than the blitting. If you do 
SW redered graphics you need to render into the  backbuffer in the 
main memory then you transfer block(s) sing a blit to the gfx card. 
If you do HW accelerated graphics you need to transfer all bitmaps 
into the gfx card memory first..also you are limited by the OpenGL 
2D functionality (which is not so flexible and pixel perfect as for 
example AGG implemntation). Also setting pixels directly in gfx card 
memory is possible but this is surprisingly the slowest way to dorendering! 
Why? Because fur current PC HW bus architecture is such transfer 
very expensive operation comparing to moving one big block of data.

So as you can see all this (and lot of other issues) needs to be 
considered not to mention that the solution should be as much as 
compatible on most of platforms.

Once the beta is released it will give us good picture how to make 
the gfx system even more optimized and extensible.

I am not speaking for Rebol or Carl, but I do know that he and the 
team have been wonderfully busy, have been getting a LOT done, and 
they are very close to being complete.  Any snide comments will be 
rewarded with complete silence from me…

So, now I know, that the team is close to release. Do other hundreds 
of rebollers who are not here know too?

I think Pekr is just as curious as the rest of us and enjoys news...any 
news of Rebol3's present stage of deveoplment. I do not think he 
is off base asking for a monthly blog. Reichart, I read these many 
of these posts everyday and I rarely ever see "snide" remarks so 
I'm confused why your brasing yourself. Although, reiderating what 
we already know about the teams hardwork and that it should be "soon" 
does not add to the conversation or help Pekr's and the rest of our 
curiousities.  I normaly would not respond but Reichart's commnets 
struck a nerve with me: "I'm tired of offierng some info, and then 
having snide comments made..." If your comments are as useful as 
the one you made to start this tread, please just refrain.  Let''s 
move on...

ahhh, expectation managment ...  I am a terrible example of how to 
correctly do that myself ... if you bug me it will take longer and 
I will be unpleasnt in the meanwhile. but it does give me breathing 
room

you can do it in R2 draw as well:

draw [scale 0.1 0.1 box 100x100]

draws a box that appears to be 10x10

draw [scale 0.1 0.1 box 99x99]

draws a box that appears to be 9.9x9.9

Dunno how to best support printing on various platforms. I think 
that R3 team will let us to do our best in open-source part ....

that would be native support for printing imo. So - what's with postscript? 
We would have to be sure, that such engine can translate ANY possible 
UI you create in View ... is that possible? If not, you simply have 
to write some kind of dialect - and here we are once again - you 
will do the work twice ...

I remember, in SAP, they had their SAP Script - the tool you used 
to do your forms for printing. They left it, and integrated PDF instead. 
I wonder if the requirement for PDF reader is problem for you? I 
know it is a dependency, but it is imo being regarded de-facto standard, 
no?

I can't help being disappointed (although I trust the team to do 
great work)

yes, if BCD in general would be usefull for other things than money 
and bank apps meaning, then it could be the right time to do so. 
I was inspired by dictionary! to map! rename, so it seems the team 
is open to ideas in that regard....

having used VID3 for a bit now, I can tell you, it's SO EASY. it's 
amazingly simple, compared to the R2 VID. it's possible to do things 
in 10 lines of code that would require 500 lines of R2 VID code.

but... on-get-value has nothing to do with "defaults"?

I kind of see Henrik's point...How do you write docs for things that 
are not complete...ot just code but the actual conncepts of certain 
aspects do not seem to be naild down yet. How do write docs in this 
situation?

Pekr, we _will_ be getting back to these things you mention. it's 
just not the right time yet. There is plenty of progress, but still 
plenty to do in terms of code, where we can't just write docs out 
of thin air.

amacleod - there aparently is more things that are complete - you 
saw the mention docs are some 30% behind? And have you ever been 
in process of writing docs? I mean - in the team? Do you think that 
ppl only wait for the work to be 100% finished? Some concepts HAVE 
to be already in place. I prefer to rewrite/restylize docs instead 
of writing them in a hurry ...

yes, it did that from the start, but the other thing is much easier, 
when you have many attachments to do.

Petr, then you should not complain about VID, but about the docs. 
Problem is, we don't have anyone to write them. Brian is doing his 
best, but I don't expect him to be able to just do *everything* (user.r, 
testing, writing docs...)

i agree with you actually, but do you really have the time to write 
them? if so, i'm sure Carl would welcome you. :)

i will tell him that you volunteered for the docs, if you really 
want to do that. (then you'll be the one to get complains for once 
;)

petr: when i talk about "assumptions" you make - you make statements 
that sometimes have nothing to do with the current code or with what 
we plan in the future. you make them just by looking at some doc 
or something i or henrik said and then you "connect the dots" in 
your own way assuming that something is going to work in some way, 
or be limited and so on. most of the times, it's just the docs that 
are missing or the implementation that is not final.

Petr: let's assume that each person here did provide some input. 
there are 244 users here. reading all that would take a huge amount 
of time, and most of the feedback would make no sense unless you 
guys have actually used the system. you know, things are not going 
to be set in stone when beta is released, if we get valid input, 
we're going to listen to it. but, first, we solve the most obvious 
problems, and with a small group it's much easier to do so! you seem 
to underestimate the "management" work that is necessary whenever 
you have a bigger group. we don't have a person dedicated to support 
only - it's mostly me doing it, and i must handle three altme worlds 
at a time - if they were all big like this one, i wouldn't have any 
time for any coding.

There was a time, just when VID3 discussions had started last year 
that it was proposed to make VID3 way more scalable and powerful 
at a slight cost in ease of use. It certainly is way more powerful 
now. I can't see any dead ends or impossibilities where I'm sitting, 
like you can with R2 VID, but the ease of use never went away. It's 
a lot easier to use than R2 VID. I'm also betting that implementing 
new features will be a breeze compared to the wrestling you had to 
do for R2 VID.

Brock, it's mostly a time issue right now. Still a lot of loose ends. 
I have no idea of the porting process as it's not documented yet, 
and I don't expect to be doing the porting. I do expect that as soon 
the process is properly documented, anyone with experience in C-programming, 
will be able to do a port.

Syllable has extra-special threading, like BeOS. Threaded applications 
need to be ported. We do have a PThreads implementation for portable 
threading, but it's incomplete

has to do with ports

Hi Pekr, I'd love to get my hands on an R3 alpha ... and I maybe 
would even have the time to play with it, but at the moment I don't 
feel like I'd have the resources to do some serieous testing. 

So, on the plus side, you don't have to expect a flood of error reports 
from my part ;-)

Do VID3 buttons appropriately resize themselves to contain their 
text?  usually we have specify the size of the button now.

has something to do with the resizing algorithm in the new layout 
scheme

Never satisfied, Terry? ;-) 40+ was exagerrated too - various Linux 
flavors are just one OS. And remember, with R3 - who wants to port, 
can. REBOL.dll, the only closed part, is platform agnostic code, 
so in order for RT to port, all they need to do (theoretically), 
is to recompile .....

Oww.. oke... what I was refering to was (from the last Blog ..."But, 
now that's been said, if you have the expertise and knowledge to 
contribute to the project, and you really enjoy fine-tuned engines, 
please do not hesitate to contact Gabriele or myself."

If I misunderstood you and you were asking about the behavior of 
particular functions, you'll have to ask about them individually. 
Many are changing from mezzanine to native, others are changing from 
native to mezzanine or a hybrid of the two. Many are going to be 
able to do more.

Small R3 update:


We can do modal popup windows now and fully borderless windows. This 
should help in building a real popup menu that isn't limited to the 
size of the main window, like in R2.

I'm building VID3 tests so we can find bugs in the layout engine.

Alpha 81 was released yesterday.

332 bug reports in the tracker.

Soft font shadows are cool. :-)

About plug-in...I need to change my mindset about it. I always avoided 
thinking: "Nobody wants t have to download a plug in o use your site. 
But I find myself needing to do it all the time and some of these 
new technologies like silverlight, require a download of some sort. 
 Rebol plugin downloads so fast it really is a minor annoyance. WE 
just need it on more platforms and browsers.

btiffin, I agree. Clear and complete documentation is essential. 
Few people will take the time to study source code. No matter how 
great a language is, it is useless unless people can easily use it 
to do what they need to do.  An inferior language that is documented 
well is very likely going to attract more users than a great language 
that no one can figure out how to use.  Core is fairly well documented 
I think, but I have never been able to get past problems in View. 
 I'm really hoping that the docs for REBOL3 will fully explain View 
and give lots of examples, especially showing how to interface view 
with databases, etc.  But writing good docs is very difficult, because 
the creators of the language know it so well that it is difficult 
for them to put themselves into a beginners shoes.  It is easy for 
them to assume that the beginner already understands things that 
, in fact, he doesn't understand at all. Anyway, I have high hopes 
for R3.  And I can do more with R2 than I ever dreamed possible, 
so I really can't complain at all.  That doesn't lower my hopes for 
better view docs though. That is the way we humans are: the more 
we get the more we want.  :>)  They call that being spoiled.

Kaj, there is a lot of work being done. A lot needs to be finished 
before R3 can be useful for anything that R2 can't do outside benchmarking 
and a few demos. I wouldn't start planning thing until the first 
beta comes out.

I can understand your situation and it's an unfortunate thing. The 
only thing I can say that might help, is that there have been suggestions 
about a plan to extend the alpha to the users in this world, so experienced 
REBOLers can take a look at it and "kick the tires", so to speak.


The problem with doing that is that it creates talk. Lots of talk. 
"why is this there? why does this function do that? I don't like 
this!" We have had a TON of discussions over the design of VID3 on 
how to do this and that, and we're not done with that yet. It's very 
time consuming to do that, when one man (Gabriele) wants to sit quietly 
and work out the design on his own until it's ready. It's just faster 
that way in the long run. Every time a new guy comes in, 500 questions 
need to be answered and it's usually the same 500 questions as the 
last new guy. :-)


Ideally, no questions should be asked until after about a week of 
use and start testing it right away. If there is a problem or a bug, 
consult the bug tracker or the documentation database, look at the 
discussions and the design documents and keep out of particularly 
Carl's, Gabriele's and Cyphre's hair until they crawl out from their 
holes on their own.

Well, then you will have to use something else. I also have products 
in the pipeline that are impossible to do in R2. They will be done 
in R3 in about a year.

Since we're still in the alpha state, it'll probably be ignored. 
RT has no time to talk about R3 right now, so as a countermeasure, 
I and a few others do that.

I guess I'm more "fortunate". All my projects are R2 only and there 
is probably 2-3 years of work left if I would have the time and money 
to pursue them all. For me there are many things left to do with 
R2 that will be useful for R3 later, such as native Windows printing.

wait, 1st august was not "beta", it was "getting the alpha to a wider 
audience". it has been suggested that it would have been bad to do 
so, so in the end it wasn't done. the dates were not unrealisting, 
they were based on the idea of releasing "early". that idea was later 
on opposed and so it wasn't done. also, the august date was based 
on the fact that me and cyphre had to be away from r3 development 
for august and september, and so we thought it was better to release 
rather than delay two months.

I do see the other side. The other side caused me quite a lot of 
trouble on some projects. I'm not going to talk about it, but suffice 
it to say, it had to do with prematurely released deadlines.

it's the same thing with REBOL. "oh, I liked the language a lot, 
but I couldn't do XYZ." well, if you can do XYZ now, maybe you'll 
be interested again. I think most people who have left REBOL saw 
it as something with great potential and great fun to use. They won't 
forget that. It'll be easy to regain momentum with these people.

Now that's depressing... Ithink that Pekr's solution makes a lot 
of  sense: Use R2-Core's feature set as a first beta goal so that 
people can start using R3 for new projects without having to recode 
later. I do not know how practical or possible that would be interms 
of development though.

Pekr, you can say that about many things. There are many protocols. 
Which one should go in first? HTTP was logical here. Now which one 
goes next? If Gabriele spends time on FTP and not on VID, I can't 
work on skinning. It could be other things, but VID is far more important 
right now than FTP, because FTP is probably fairly trivial to do, 
but still a one-man project that should be done when Gabriele can 
be free to do that.

kaj: it's a toy because you can do whatever you want with it, but 
not put it in production, because you'll get no support at this point. 
well, of course, if you want to go into production with no support 
and knowing that the next release may break everything... of course 
you're free to do that, but don't complain to us then :)

I can tell them what is important to me, but I can't tell them slice 
core off first and then work on view - only they know enough to make 
those calls.

Ashley - sure we do - we want it all now.. *smile*

I do not have enough information to make an informed decision on 
something like that, part of why we need more visibility but also 
why we need to pull back from "telling" RT what should be done.

It sure sounds like it to me?  The frustrations put here are of the 
do this do that nature which I don't find as productive as they could 
be.

rgaither - stop taking excuses! :-) If RT can't manage it themselves, 
someone needs to tell them, what to do ...

I don't take it personally. I am just used to what I do with my daily 
job - define strategy, and path to lead the team to final result. 
I can quickly adapt to other solution, if it makes sense ...

I feel the discussion is straying away from the issue now. I, for 
one, do not want to tell RT what to do; I just want them to inform 
us what to do. I have full technical confidence in them, but the 
false promises must stop

The discussion about what developers and managers are unable to do 
is bogus and just stereotyping. This is an individual issue. There 
are great managers, and great developers who are perfectly capable 
of management

Nope it's a step toward an end I do believe.  I like it as it allows 
for padding and alignment, but it's not the real format dialect yet, 
afaik.

sqlab; I'm smiling as I type this, so...

Psst, don't complain too loud or I might get cut off from showing 
off non-production sanctioned versions of functions.  I don't think 
the wait is going to be much longer but I feel for rebol trenchers 
and think the community deserves to see some of what is going on, 
so I asked to release a few mezzanines.


I was hoping it might motivate a rebol or two to expand on it, and 
reinforce the belief that community involvement is not only going 
to be a good thing, but a great thing.  Plus it's a good function 
for what is does imho.