AltME groups: search

Can anyone else confirm that on Windows (at least on Win 7 64 bit) 
the last r3.exe that Henrik posted a link to here, pops up a security 
dialog ("Open File - Security Warning")?  This isn't the UAC dialog 
that you get when you run an executable as administrator, btw. Other 
r3 executables that I had lying around don't do this.

This will have to be done anyway, or how are you supposed to display 
styles for REBOL IDE, which you can place on a form? Unless you are 
supposed to do it manually of course ...

Rebolek - those are details which could be corrected in 1 minute, 
and make the overall feel for the tester much better. The whole team 
is not even at the level of Carl's VID, not unless R3 GUI can do 
anything usefull. I don't care for look now, but correct system metrics, 
closer to typography rules, are always welcomed. The screen forms 
should look relaxed. E.g. I was lately suprised, that I tried some 
Air app, and it was unpleasant experience in that regard ...

The problem with original scroller is, that is was 'too smart', it 
was scrolling area it was attached too. That may seem like a good 
idea at first unless you don't need the scroller to do something 
different like instead of setting area's offset, you need to change 
e.g. text's scroll. So right now the scroller just returns value 
and the style needs to handle that value by itself.

OK, I can test personally. In the past I worked privately for Romano, 
Cyphre. We can concentrate upon some more concrete stuff. You can 
say just few points, like - new area, please test. And I will do. 
Recently Henrik releases new version without telling what has changes, 
just 21KB was added :-) That is really difficult to estimate what 
changes should be tested :-)

We release often and I think we should continue to do it but it helps 
a lot if we just focus on the stuff that is there, and not the stuff 
that is not there.

Petr, a lot of your points are valid and have been discussed several 
times. Nevertheless, we need to do it all.

How want to work with the RMA team on the R3-GUI? By work I mean, 
really getting something done. Writing code, styles etc. not discussing 
generic, high-level architecture stuff and future things to do.

It was decided a long time ago to do future projects in R3 as we 
felt that continuing to write testing tools, frameworks, etc. under 
R2 would give a big pile of work later, when converting that to R3.

Considering also that the result of that decision is that Carl is 
now in tight communication with RM Asset, I think it was a good decision, 
as we avoid the months of darkness without info. It gives RM Asset 
control in what direction to take the GUI and to work towards R3 
being a usable product as quickly as possible, when you have to answer 
to other companies and customers. SDK is also a requirement, that 
we hope can be pushed through as quickly as possible.

I do understand that you want to express the behavioural symmetry 
in PANELS and GROUPS. It's a bit like multiple inheritance: Inherit 
behaviour from PANEL or GROUP, inherit orientation from HORIZONTAL 
or VERTICAL. That's 4 possibilities, and any name chosen is likely 
to overemphasize one aspect over the other.

OK, why not to use parametrisation. The question is - do we want 
more names, or not? Or even - can the orientation of panel by changed 
programatically later? I know that during the runtime, corresponding 
"VID" code is not important, but if it can be e.g. changed, then 
it would be probably better to have them as parameters, e.g. PANEL 
#V [], but I understand why some ppl might not like it.

do we want more names, or not?

 - it's very simple actually. if the options are too comprehensive 
 or to unclear to set for a style, make a derivative style. so, work 
 it out from that.

re across, below: I'm afraid we have to be style specific here. Using 
the across, below we would end up with two big styles that are trying 
to do everything.

hmm, looks easy to do :-)

So, if you specify an H or V mode (and mindset), then when you're 
grouping your faces, do you think in terms of a FORSKIP look or a 
SPLIT model? And what makes it easy to add a new row or col?

Yes, I think tables are key here (tbl did spanning long before HTML 
I believe :-). Do H and V panels help that much, e.g. to reduce clutter? 
I imagine the team talked about that, and whether just a TABLE would 
be enough.

Do you want in Vpanel the second element to be below the first one, 
or to the right of it?

Myabe it's on my mind because I had to do some SQL recently, where 
the insert statement was one col per line, and lots of lines, followed 
by the values to insert, also one per line. :-\

I'm going to rephrase my idea: In general it could be possible to 
use blocks of blocks inside the layout. This would make it easier 
to generate layouts and not care about style argument lengths:

view [[button button] [field field]]


Of course you can't split a style in two blocks, but this wouldn't 
be needed anyway:

view [[button] [do [something]]]


This is similar to how gradients can be put in blocks inside DRAW. 
Is there anything that would conflict with that?

i like the idea of having a really simple way to look at rebol app 
and then you can edit part of it add new boxes with crazy new stuff 
etc.... it's somehow what we do in text based coding 

but on heavy fragmented project it's hard to have an over view to 
it ...

it goes beyond that... at the purely language level R2 was really 
limiting many things I wanted to do.  view and AGG limitations where 
also very present in my tests.

hahahaahaha  .... i hate to be forced to C program to do rebol i'm 
interrested in rebol the other languages juste bore me to the infinite 
point ...

maxim the idea is that i don't want to do the box in the box in the 
box in the box  effect ... i want 2 kind of boxes tools and box mainly 
tools are scripted set of rebol function or rebol functions from 
teh rebol standard dictionary

although that specifically implies that you actively need to do some 
specific work to activate undo. I don't like that.

take the case of a system where the undo crosses the lifespan of 
a window (or a few) how do you undo that?  re-open a new window which 
isn't connected to anything?

it basically has to be built with undo actions at the center.


each action has to be able to handle any gui issues gracefully... 
the gui itself cannot manage that unless its an uber simple gui.

another optimisation is that when you create a document you will 
obviously do alot of insert action so the idea is to regroupe the 
insert actions betwin  insert space
For example:


insert "a", insert "b"', insert "c"; insert " " -> trigger of the 
sorting algorithm insert "abc" [line1-:-0] (this optimisation can be 
seen in OpenOffice 3.2)
 

Would be better if instead of registery the action done by the user 
you register the mirror action to be apply to reverse it
then you have

delete "a", delete "b", delete "c"; delete " " -> trigger concatenation 
algorythm delete "abc"@line1:0, delete "space"@line1:3 (position 
here is set as line number followed by the caracters to pass in the 
line before reaching the character can speed up rendering if you 
are able to use remove index stuff in my opinion)

New r3-gui.r3 released at above location.


New feature: Now allows reactors to be run after a specific actor 
in the style. If your style runs ON-DRAG, a block of reactors after 
an ON-DRAG keyword will be run afterwards. This opens up a lot of 
new possibilities.

view [field on-drag [do [probe 'dragging]]]

This needs a lot of testing.

last used tab, last focused item. there are a few things to save, 
but as long as they can be retrieved and set in code, it should be 
possible to do.

Well, I have several hundred screens in my app ... not sure what 
else I can do to organize them

I have a very basic question, that I have already asked to Carl : 
how to get a working gui.r version ? when doing load-gui, I get the 
following error message : ** Script error: size-text has no value. 
It seems to me that this point should be definitely fixed, as it 
prevents anybody to do view tests (for instance the ones given in 
the reference doc http://www.rebol.com/r3/docs/gui/guide.html) I 
think that this should be done quickly and independently of any improvement 
and evolution of the gui styles and functions.

This won't start until sometime later though, so it's going to look 
like this for a while. I'd hate to do too many rewrites, if I were 
to start now.

Pekr, if you think Carl's version is more complete, then you can 
use it...AFAIK Carls version is simply incompatible with current 
R3 and doesn't work ;)

We are fighting on all fronts to get our stuff in better shape everyday. 
I must also note we are working on other things that needs to be 
done. The system is in final phase of stabilizing its internal parts. 
We are now focusing on a good way how to do automatic testing before 
we start doing more styles...

As always, you can wait for our stuff or be active on your own, use 
what we gave to the comunity and make everything better, faster, 
longer, stronger and quicker!

What's left (not necessarily in order):

- test framework for GUI
- dialogs
- form validation, which meshes with dialogs
- help system, which meshes with form validation
- database record management, which meshes with form validation
- actor documentation parsing

- better View function that supports initial states for forms and 
dialogs
- some issues with resizing
- work on text editor core
- general style work
- skin comes last


Of course over time we get new ideas or stumble into design issues 
that need to be solved, before we can move on. That's necessary to 
make sure that some future feature is going to be simple to do.


All this is of course separate from hostkit, font rendering, and 
DRAW enhancements.

Pekr, what is the reason you don't help either by:

* wring tests for Parse
* writing test for Mold

* writing tests for CureCode tickets that don't have tests in the 
core-tests suite yet
* writing some GUI styles

* responding to user polls, letting us know what your preferences 
are

* reading the documentation and/or new proposals pointing out at 
the problems you are having with them
* doing other useful work to help R3?


That is not complaint nor is it any kind of attack. It is just that 
I thought you needed R3? And, from my point of view there is no obstacle 
you could not do any of the above? However, you have still a lot 
of stuff you can pick and help to make R3 better. Do you still not 
feel like wanting to do something? Simply put, there is enough oportunities 
for you to pick from, and the quantity is getting bigger over time. 
Or, is it still too early, and any effort from you can be expected 
only when none will be needed?

I would probably agree, if I didn't have other experience with the 
VID Extension Kit. The trick is to make the focusing mechanism flexible 
enough to handle all situations. We are not building a GUI that handles 
specialized situations. We are building a GUI for large business 
applications with dozens of windows, hundreds of widgets and tons 
of forms. We absolutely do not want to have something like focusing 
being a special case per style as other than a special option.

If the style designer wants to make confusing widgets, there's nothing 
we can do about it other than providing some style guide lines.

Anyway, right now I prefer to do this in style's on-focus actor. 
After few more styles are done we can check for repeating patterns 
and try to make it more general.

I'm not against central processing in draw-face. I'm just right now 
not sure what's the best way in our current box model. I need to 
do more tests before implementing this so I don't have to rewrite 
it later because of bad design.

Ok, that will do. We just don't want to end up in a situation where 
a central mechanism for rendering the focus ring becomes impossible 
to do. we will have a similar situation with help bubbles. Perhaps 
it's best to have a general mechanism for generating a gob near any 
face. We can use that in the help system as well.

if you do that, you're 80% done. that leaves a few problems to solve, 
but that can be done down the road.

Just tried to run the style-browser.r3 on Amiga and hit the following 
problem
>> do %r3-gui.r3

Script: "Untitled" Version: none Date: none

>> do %style-browser.r3

 Script: "R3 GUI Style Browser" Version: $Id: style-browser.r3 1179 
 2010-11-19 18:11:46Z Rebolek $ Date: none
** Script error: cannot 
 MAKE/TO image! from: make gob! [offset: 0x0 size: 400x300 alpha: 
 0 draw: [clip 0x0 400x300 anti-alias false pen false fill-pen 192.192.192 
 box 1x1 399x299 0 fill-pen false pen 64.64.64 line-cap square line-width 
 1.0 variable line [0x0.5 399x0.5] line-cap square line-width 1.0 
 variable line [0.5x0 0.5x299] line-cap square line-width 1.0 variable 
 line [0x299.5 399x299.5] line-cap square line-width 1.0 variable 
 line [399.5x0 399.5x299] clip 6x6 394x294 translate 6x6 line-width 
 1.0 variable pen 255.255.255 fill-pen false anti-alias true clip 
 0x0 0x0 pen false line-width 0.0 variable grad-pen linear normal 
 1x1 0x2...

Any ideas?

Actually, when it's in-style, you do not have to take care of box 
model - that's problem only with universal solution.

a small glitch with style browser - I do mouse over of preview tab, 
it crashes. In console I do unview none, but consecutive start of 
style browser fails. Ditto when I try to re-do r3-gui.r3

Dunno if it would be good concept (it might be confusing for user), 
but some time ago I was thinking about nested tab system. What I 
mean is - most of tabbing systems do work in a flat way. It is kind 
of primitive. But - sometimes you might want to use the same navigational 
keys for more complex styles, typically subpanels, grids.


What we recently got (and can be seen with e.g. style browser) is, 
that e.g. tab panel can be tabbed. Then arrow keys do switch between 
tabs. What I had in mind was to be able to press enter, to nest the 
tabbing, so that you "enter" the subpanel, and esc to escape back 
to the upper level (this part might be tricky for users, not sure 
about it - they might feel being locked inside of some style).

Any ideas?

I expect it being possible. The question is - do we want rebol app 
to behave in OS native way, or just the same thru all platforms? 
I am for the former ....

if we do that, there might be a need to define a behavioral model 
as part of the skin, but I'm not sure how much it encompasses. There 
are some little details that I expect to work in a specific way in 
OSX, which don't work in Windows, and vice versa. This means that 
styles may not implement these behaviors directly, but that is probably 
difficult to avoid.

as we get a better arrangement on how to do that properly, yes. I 
think we can do this by pushing nightly from the server.

Of course that would depend on what native plugins are allowed to 
do on Android. I haven't even heard of a fully native GUI app for 
Android (they might exist but I haven't heard of it), only CLI apps.

Order entry apps seem like the kind of thing that the existing Android 
GUI would be able to do easily.

I figured that direct use of REBOL wouldn't be something you could 
do now for your project. But it could be useful eventually to someone 
else in your situation, so it is worth discussing :)

Android can do SDL, so it should be able to do the host kit and AGG, 
in several ways

Whether you reimplement in Java or port the host kit, you would need 
the same mapping from the Java semantic model to the REBOL semantic 
model; they have little in common. That will probably be the hardest 
part to get right, especially if we do a native r3lib port and just 
rewrite the host.

If you were to port it the same way as SDL, you would have very little 
to do with the Java subsystem

It looks like you might be able to use a combination of the standard 
NDK and a third-party cross-compiler to make fully native GUI apps. 
You would get the libraries from the NDK, including SGL (that's Skia 
Graphics Library, not SDL, it owns the framebuffer). I haven't seen 
anyone try to do this yet but since it may be possible then it might 
have been done already by someone.

Am I missing something really basic......Here's my first attempt 
in many months to play with the R3 GUI.
New console session, R3-a110.exe:
    >> load-gui
    Fetching GUI...
    GUI Version: 0.2.1
    (Developer test GUI theme)
    ** Script error: size-text has no value

    ** Where: font-char-size? make make-text-style parse fontize do do 
    either load-gui
    ** Near: font-char-size? self

Henrik - public channels are all dead though. Twitter, blogs, and 
even R3 Chat last login is 15 Nov. Hopefully Carl is taking a break 
to refresh, and to do some beta decisions ....

These docs don't yet include the real subtleties of when to use IMPORT, 
when to use DO and when to use Needs. In particular, they don't say 
when *not* to use IMPORT directly and why, what the difference is 
between named and unnamed modules, or any kind of hints about overall 
program structure. This is partly because the docs were written (by 
Carl) before the module system was finished (by me) so that info 
simply wasn't known at the time, and partly because I could use some 
help with writing docs about those issues that don't read like a 
CS paper.

Ladislav, right now the best documentation of mixins is the source 
of the DO-NEEDS and MAKE-MODULE functions in DevBase. There are also 
the CureCode tickets related to them. But there aren't that many 
docs for them, and the behavior might be yet be tweaked. If you have 
any questions ask here, and I will answer as I can. But I'm going 
to be busy this month, so patience would serve you well here.

Hidden words can't be exported, because the export process has to 
see the words to export their values. This means that the 'export 
and 'hidden keywords will conflict. I can resolve that conflict by 
having one take precedence over the other, but that just seems like 
a hidden gotcha. It seems to me that triggering an error if both 
keywords try to modify a word would be the best approach. What do 
you think?

I could screen for it in DO-NEEDS, but that wouldn't help with everywhere 
else the modules list is accessed. It would really be better to not 
have any optional keyword at all, but there's that backwards-compatibility 
thing. We'll have to resolve this before we have a real R3 release.

If you are adding a module to the module list, and there is an existing 
module of that name, then the new module either overrides it, replaces 
it, or doesn't get added (possibly with an error triggered, but so 
far not). The question is which one to do in the particular circumstances. 
The factors are whether it is the same module, for whatever "same" 
means here considering it might be reloaded or still source; whether 
the versions are the same or greater; whether the existing module 
has already been made or is still source, and the same for the module 
to be added.

The questions I have are:

1. What do we do when a module is not added due to a policy issue? 
Currently the add accessor returns none if it is a version issue, 
and triggers an error for a checksum violation.

2. How do we determine (officially) that two modules are to be considered 
the same? Name and version?

2. Can we safely LOAD-EXTENSION more than once with the same extension?

3. Does LOAD-EXTENSION on an embedded extension have any side-effects 
beyond creating an object?

4. ... return the same source each time, or different copies of the 
same source? Testable by SAME?

5. Is is safe to delay the object returned by LOAD-EXTENSION instead 
of the source?

Excellent.  I'm looking for guru-level docs.  


If I'm reading this correctly, I will finally have everything I asked 
Carl for (in regards to Object! enhancements) at the '04 Devcon. 
 I'm going to spend some time stubbing out the functions I will need 
to do the advanced IDE tricks I've been wanting to do.  I'll have 
some questions for you once I get some of that done...

You don't necessarily need to explicitly import regular modules in 
order to use them, but you do need to do so for mixins. Mixins are 
like the modules in Maxim's or Gabriele's module systems, more or 
less. As such, mixins will only be used by the kind of advanced programmers 
that already need to write modular code. Regular programmers won't 
need them.

With alpha 109 we got some significant usability revisions to the 
design of the module system, relative to alpha 108:

- The return of unnamed modules. They are now changed to private 
modules (mixins) which aren't stored in the system modules list.

- IMPORT now effectively works a lot like the Needs header in user 
scripts. Most users won't be able to tell the difference.

- The return value of IMPORT block is now a block of the modules 
you imported (but not the modules *they* imported).

- The refinements of IMPORT have been renamed and their behavior 
tweaked to be nicer and more useful - the first API change since 
Carl's original.
  - /no-share: The previous /isolate option. Same behavior.

  - /no-lib: Don't export to the runtime library. Private modules don't 
  do this anyways. Also, don't add to the system modules list.

  - /no-user: Don't export to the user context, even as a private module. 
  When importing to a module, /no-user applies.

- The old /only option was split into /no-lib and /no-user, for more 
control. Specify both if you don't want IMPORT to export anything.

Alpha 110 should bring these changes:

- The above will work properly. With a bunch of specs and charts 
that define what "properly" means. With a full test suite to make 
sure.

For the sake of completeness, here are the highlights of the alpha 
108 changes:

- Script headers can have an options block, a simple block of flag 
words. User extensible.

- The standard script header now has a lot fewer words in it. More 
stuff is optional or in the options block.

- Script compression, either binary and base 64 binary! encoded. 
Automatic, transparent.

- Script checksums, both to verify the script and for IMPORT to compare 
with. Applies to decompressed source.

- An optional script length header field (like http's Content-Length). 
This allows binary script embedding.

- Internal support for getting the end of an embedded script, so 
a multi-loader is possible.

- The 'content and 'isolate header fields are changed to option words. 
The content is still saved to a 'content header field.

- The 'content field, if set, is set to the start position of the 
script proper, even if there is stuff before it.

- The whole system/contexts/system concept is gone, as part of the 
system restructuring. Now we have SYS.

- The system/contexts/exports concept is gone too, replaced by a 
not-module-specific runtime library called LIB.

- The old type: 'extension is now the 'extension header option word. 
The only module type is 'module. And it's optional for most code.

- Mixins are now called "private modules", and are flagged by the 
'private option word. And they can have names.

- Private modules can be added to the system modules list (because 
of the names). This lets them be reused without being reloaded.

- Unnamed modules are now prohibited (until alpha 109, where they 
become private modules that reload every time).

- Delayed modules, which can be partially loaded and then not fully 
made until they are imported. Use the 'delay option word.

- A HIDDEN module source keyword, which applies PROTECT/hide to a 
word or words. Acts like the EXPORT keyword.

- Better errors are triggered when the bad things happen. Including 
new error codes.

- DO and MAKE--MODULE intrinsics are now in sys, as DO* and MAKE-MODULE*. 
No more system/intrinsics.

- DO-NEEDS is no longer exported (it's in sys). IMPORT block is a 
public alias for DO-NEEDS anyways.

- MODULE now makes modules that act more like those in script files. 
And has /mixin support too.

- A whole bunch of changes and fixes to native functions to support 
the above stuff.

Shadwolf's "used by 3 guys around the world" comment brings to mind 
one of the more ironic things about the module system:


Most user code for R3 will be written in "scripts", not "modules". 
This will be even more the case once we get more of concurrency working, 
because "script" code works in the user context, which will be task-local. 
We are going out of our way to make it extremely easy to just use 
"scripts" and not have to bother with "modules".


The ironic part is that "scripts" are just another kind of module, 
one of the three including regular and isolated modules. In particular, 
user scripts are a kind of module that we try to make as non-module-like 
as it is possible to be (given that they run in a module system). 
The entire module system structure is built around the challenge 
of making the module system apparently disappear, or at least be 
something that you can be almost completely ignorant of. The module 
system is built for script programmers, to let people do PITS on 
a systerm that they don't even have to know is capable of the most 
advanced PITL.


So the module system we are discussing here will be used by *everyone 
who programs in R3*, whether they know it or not :)

(I am politely assuming that Shadwolf was not referring to the entire 
REBOL community when he said "3 guys".)

We plan to do encryption and signing. We aren't far enough along 
in the plan to know how we will do these.

Certificate use is something R3 doesn't do well yet, afaik (which 
isn't far). We will likely have to do a lot of infrastructure work 
before we can do encryption or signing.

Nonetheless, this is something we want (need?) to do, so the crypto 
infrastructure work will need to be done.

My hope is to never, ever come across a "do %..." that "loads" utility 
functions again (in R3).

Of course, headers let you do all sorts of tricks that you can't 
do without them. In addition to the above stuff, header settings 
let you:

- Embed scripts in text or binary files, even if it's just documentation 
before the script header.
- Aggregate multiple scripts/modules in one file.
- Save and verify a script/module checksum.
- Compress scripts/modules.

Part of exporting is copying the values to another context, where 
it is used. You don't normally get any references to the original 
module words. And part of importing is copying those words again 
to your own context (for isolated modules and for scripts), or binding 
to the runtime library. So in practice, the only known contexts that 
you can update the values in are your own, the runtime library, and 
the current task's user context. To upgrade other contexts they would 
need to register with you, and you would have to do them one at a 
time.

REBOL processes tend to run for years, if they don't have bugs and 
don't use a buggy REBOL. Do you remember the first mailing list outage?

Do you want him to write import 'module or do you want him to write 
REBOL [name: 'module] or both?

I've not read the entire discussion... but let's roll back a little.


Andreas, simple things should be simple. A REBOL rule. So some points 
on modules:


1. We've used objects as "a type of module" for many years. Pretty 
easy.


2. The first thing you do is give them a new datatype, calling it 
module!  But, still basically an object. Easy.


3. Next, you make it clear what is exported... with the EXPORT word 
or EXPORTS block in the spec. Still easy.


4. Next, you want the runtime system to help keep track of the module. 
To do that, the module needs at least a name to identify it. Not 
difficult.


From there, you can imagine many other features you might want: versions, 
checksums, compression, dependencies (needs). You can add quite a 
lot. But, the more you add, the more likely it's going to get complicated... 
and few users will understand it, etc. So, for R3, Brian and I agree 
to a design that provided quite a few features without too much code, 
but also kept simple things simple.

Technical reason = because one has a name and the other doesn't. 
I'm not dumbing it down, it really is that simple.


Say you are a module, and I want to import you. It's rather straightforward, 
I just add your exported words to my collection (how I do that depends 
on what I am, but that's a story for another time). And then I can 
use those words, no problem.


But what if I don't know whether you have been imported already? 
Or what if I know you have been imported by someone else, but I want 
to use you in particular instead of someone who just looks like you? 
Or what if you have data that you want to share, or resources that 
can't be used more than once at the same time? Or what if you want 
to know if a previous version of you was imported already, so you 
can get that guy's data or resources and take over for him?


To do all of these things, you need a way for others to refer to 
you, a name. If you have a name, I can put you in a collection with 
other modules and then others can look in that collection for a module 
of that name and if they find one they can know that it's you. Simply 
having some way to find you in a crowd makes all of that stuff possible. 
It really is that simple.

Another trick that I can do if I have a name for you is to just put 
you in a box and then import you later: delayed modules. If you don't 
have a name, I can't find you in that box, you look just like all 
the other delayed modules.

Time to show examples of all of what it can do... and get developers 
using some of this good stuff.

So, do we have a good place to put this? Google code?

So, how do we want to go about doing this?

I.e. a 'Linux" repository and a "Win32" repository where you manually 
do merges (or copy/paste) in between will only lead to trouble.

The details of those latter parts are not particularly exciting, 
as they are easy to do in a variety of ways.

I think using Git is the way to god for a new project.   every big 
project I see that is changing VCS is goint Git.  it seems to be 
the most powerfull VCS right now.  do you agree Andreas?

I'd be willing to do that.

What do you think about soliciting a few inputs from other developers 
regarding choice of rev control and related issues... because we'll 
want them to use it?

Github is a good site, but there are a few issues, such as how they 
do not acknowledge the .r extension as Rebol.  I've gotten them to 
do .r2 .r3 and .rebol however.

Pekr, that's simply a snapshot, which takes a minute to do, thanks 
to our build system.

its easier to do a grid of different setups. not just a linear sequence 
of versions.

rebol in and of itself already does most of the low-level OS stuff... 
just two days ago... I used R2 as a delete function in order to polish 
a windows GCC script.  this strikes me as a similar situation where 
rebol could be used to probably replace a sizeable portion of the 
msys stuff... though it might not be as fast and optimised... that 
I do concede.

But you do not get that if you just clone someone else's repository 
in a read-only fashion... i.e. with the clone command " git clone 
git://github.com/rebolsource/r3-hostkit.git ".  It's easy enough 
to fix later, but you can do it up front by starting with a fork 
if you know you are planning on making changes and sending them back 
to the project.

A word of advice: On Windows, you might not want to use the Tortoise 
extensions. Tortoise* slows down Explorer's file and directory access 
even when you don't have any repositories or relevant file hierarchies. 
If you do a lot of file management you might want to stick to the 
CLI tools.

Also do not miss doing the git config to set up your email and name 
information in the commits.  Otherwise it will swipe that from your 
local machine name / localhost: http://help.github.com/git-email-settings/

There'll certainly be things you want changed and improved, and I 
think the best way to do that is to insinuate Rebol into the predominant 
toolchain rather than see it as its own completely parallel universe. 
 Github itself is based on Ruby on Rails, but they're using a python 
syntax colorizer.  If a tool is good, it can get slipstreamed in... 
and Rebol is so small that it could do the same, if it just mellowed 
out and became a little less prickly...

I saw the .reb thing.  They would probably do that.  They've already 
given Rebol .r2, .r3, and .rebol ... tekkub and I seem to have a 
little bit of a rapport now so I could probably ask him to do .reb 
too

They were talking about recognizing the rebol header, that's what 
they want to do, they just don't have the priority.

another (possibly simpler) option for recent git on ubuntu is to 
use third-party packages. just add 
deb http://ppa.launchpad.net/git-core/ppa/ubuntulucid main

to /etc/apt/sources.list, replacing "lucid" with the name or your 
distro. then do an `apt-get update` and `apt-get install git-core`

Do the CRLF-local, LF-repo on Windows; LF local and repo on Linux. 
Then line endings will be normalized. Only applies to text files 
of course.

Brian, the only trouble with letting git do the line ending normalisation 
is that it is a bit troublesome. It's generally easier to just have 
git not touch the line endings at all and use a properly set-up editor 
instead.

Yes, and I want to make sure that the R3 Git Guide that we'll post 
shows that this is very simple to do.