AltME groups: search

REBOL's installer hasn't worked at all since the 2.7 series, and 
it never worked correctly before that, though the 1.3 series improved 
directory usage. Fixing the installer is on the list for the next 
version.

Little bit more playing around, to see if +s was taking ... doesn't 
seem so.
rebol []
probe system/script
change-dir %..
list-dir
ask "waiting"

c:\tools\rebol\appdata\rebview +s testing.r

...
    words: none
]
waiting

** Script Error: list-dir expected dir argument of type: file url 
unset
** Near: list-dir
ask "waiting"
>>

The ask is evaluated before the list-dir error     And if  list-dir 
%.  is used, it lists the dir, without a security box.

That's natural. list-dir expects an argument.

We already have a list of priorities there.

Give me a little time to go over them, I should have a list by this 
evening. I'm at work today.

It's been broken for so long, I no longer have the computer where 
I originally wrote it back in 2000 and posted it to the mailing list. 
It's still in my head though, so I'll collect it by Tuesday evening 
and start working. In brief:

- I don't know about installation on platforms other than Windows. 
Someone else will have to chime in here. Too ambitious for 2.7.7.

- Windows 2000+ support is still broken. Multi-user support is broken 
(same thing, really).

- Folder usage was mostly fixed in 2.6.3, but the registry is still 
misused. Registry migration will be needed.

- Non-admin installation should be possible, including user-specific 
file associations.

- Installation was broken altogether in the 2.7.x series - it doesn't 
work at all, not even to 2.6.3 levels.

- No-install usage of View needs better support. This means UI support 
too, if need be. VIew should be able to be a portable app.

Keep in mind that portable app usage of directories is completely 
different than installed usage, and needs to be.

Right. So you need to use it in a set-word expression somewhere, 
or put it in the locals list manually.

Impressive list of changes.

There, the list is done for this release.

I put a full list of my changed and added features in the comments 
here: http://www.rebol.com/cgi-bin/blog.r?view=0447#comments

Once someone tells me where to put it I will put that information 
on the web.

yep.. I noticed that page too.. And based on that one, it looks like 
that level of control is not at Rebol.  


I did that port: open  thingy and then  ? port ... it gives a huge 
list of  parameters, but most of them seem to be more Ethernet/tcp 
related than Serial port..

Graham, the file management functions are still on the list to be 
included. I just didn't have the time for 2.7.7, so they'll be in 
2.7.8.

in theory, you could replace the main loop if you want, if we have 
callbacks in extensions, the main loop can be handled from an extension. 
although its not like having it close to the core, where it can be 
smarter...


but if a callback can see if some events are waiting on a list of 
event ports (something like event: wait [ port 0] ), then we could 
use whatever timer/window events and fire from there....  the rogle 
extension includes GLut which already has its own (precise?) timer 
internally, but it can't trigger rebol code *yet*. so right now I 
have to handle all events in the C side :-(

(oops strike disk from that list)

PPC to x86 transition. x86 to x64 transition. OpenGL emulation on 
old video cards that don't support new features. Instruction set 
independence for the iPhone. Objective-C support in the front end 
that can be integrated with their development tools without license 
restrictions. A development commuunity that will accept their patches. 
The list goes on.

Not the first thing on my list though (which is HTTP) so if you want 
to take a crack at it first, I can help with the extension/module 
model.

I saw that one, but it doesn't seem to be the right approach. Two 
reasons:

- .so and .dynlib aren't dynamicly linked library formats on Windows, 
.dll isn't on Linux, etc.

- It kind of defeats the purpose of extensions: making all of that 
platform-specific stuff go away.


Don't get me wrong, the current behavior also has the second problem. 
Extensions are imported like modules, and so the code that is asking 
for them has to specify the filename to load them. However, *that* 
code is supposed to be cross-platform, so putting a platform-specific 
filename in their Needs list is inappropriate.


What do you think of using a generic filename extension like .rx 
for extensions, then having LOAD translate to the native filename? 
Or on platforms that don't require a specific filename extension 
for their dynamic library loader (like Windows), you could use the 
.rx extension directly.

Graham: I got the message on protocols and it's on the list.

true, but objects can be nested. and a single small object, like 
in the above, may actually represent MANY draw commands.
 

for example... a single block of text strings... may actually represent 
all the items of a text list.  parsing that list to fit things within 
bounds. 

re-creating the whole AGG block as you scroll the list, forces you 
to possibly generate a few hundred draw items in a block.


but you have to build that block using intepreted code, which only 
ends up being an intermediate in order to pass the visuals to the 
rendering.


with an object, constructing that visual can all be handled on the 
native side and will save a lot of work on the interpreter and the 
GC.

the object will contain a few parameters and it represents the list... 
but rendering it will all be managed in the native side.

off the topic, 

Gobs are not specifically related to graphics if they are not rendered 
(showed)

Gobs could be used to implement some efficient data structures, like 
linked list or tree.

As far I tested, dealing with structures of gobs is faster than with 
standard objets.

A really cool feature is that when a gob is append as a child to 
a gob, it's removed from its current parent automaticly.

only if the commands are in the export list.

There's no unloading, but it's possible, however, very low on the 
todo list considering that most extensions are long-lived.  The locked 
DLL G refers to above is because the code segments are loaded. (That's 
more of an OS implementation issue, a poor one IMO.)

So, the next thing on the big todo list is: C-to-R callbacks.

Also, on the list is to add BrianH's change, in fact that probably 
should be A102 by itself.

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.

with a few polling function it could be really nice:


completed-bursts 'pic-renders  ; reports progress done on overall 
pic-renders for all shots.

cancel-bursts 'pic-renders ; stops all pic-renders and bursts which 
depend on them.

interrupt-bursts 'pic-rendrs ; puts bursts (and all depencies) into 
a wait list, to be restarted later.

Maybe we should make a list of candidate libraries and decide what 
is the best fit to our as yet unstated needs?

//I want: char **MagickQueryConfigureOptions(const char *pattern, 
unsigned long *number_options)
//I have:
            unsigned long *number_options;
            char *item;

            char **list = MagickQueryConfigureOptions("*",number_options);
      
            REBSER *b = RL_MAKE_BLOCK(*number_options);
            RXA_SERIES(frm, 1) = b;
            RXA_INDEX(frm, 1) = 0;
            RXA_TYPE(frm, 1) = RXT_BLOCK;

            int i,j;
            for(i=0; i<*number_options; ++i)    {
                item = list[i];
                REBSER *s = RL_MAKE_STRING(strlen(item), 0);
                for (j = 0; j < strlen(item); ++j)
                    RL_SET_CHAR(s, j, item[i]);
                RL_SET_VALUE(b, i, s, RXT_STRING);
            }

//I want: char **MagickQueryConfigureOptions(const char *pattern, 
unsigned long *number_options)
//I have:
            unsigned long *number_options;
            char *item;

            char **list = MagickQueryConfigureOptions("*",number_options);
      
            REBSER *b = RL_MAKE_BLOCK(*number_options);
            RXA_SERIES(frm, 1) = b;
            RXA_INDEX(frm, 1) = 0;
            RXA_TYPE(frm, 1) = RXT_BLOCK;

            int i,j;
            for(i=0; i<*number_options; ++i)    {
                RXIARG arg;
                item = list[i];
                REBSER *s = RL_MAKE_STRING(strlen(item), 0);
                for (j = 0; j < strlen(item); ++j)
                    RL_SET_CHAR(s, j, item[i]);
                RL_SET_VALUE(b, i, arg, RXT_STRING);
            }

//I want: char **MagickQueryConfigureOptions(const char *pattern, 
unsigned long *number_options)
//I have:
            unsigned long *number_options;
            char *item;

            char **list = MagickQueryConfigureOptions("*",number_options);
      
            REBSER *b = RL_MAKE_BLOCK(*number_options);
            RXA_SERIES(frm, 1) = b;
            RXA_INDEX(frm, 1) = 0;
            RXA_TYPE(frm, 1) = RXT_BLOCK;

            int i,j;
            for(i=0; i<*number_options; ++i)    {
                RXIARG arg;
                item = list[i];
                REBSER *s = RL_MAKE_STRING(strlen(item), 0);
                arg.series = s;
                for (j = 0; j < strlen(item); ++j)
                    RL_SET_CHAR(s, j, item[i]);
                RL_SET_VALUE(b, i, arg, RXT_STRING);
            }

unsigned long number_options;
            char *item;

            char **list = MagickQueryConfigureOptions("*",&number_options);
      
            REBSER *b = RL_MAKE_BLOCK(number_options);
            RXA_SERIES(frm, 1) = b;
            RXA_INDEX(frm, 1) = 0;
            RXA_TYPE(frm, 1) = RXT_BLOCK;

            int i,j;
            for(i=0; i<number_options; ++i)    {
                RXIARG arg;
                item = list[i];
                REBSER *s = RL_MAKE_STRING(strlen(item), 0);
                arg.series = s;
                for (j = 0; j < strlen(item); ++j)
                    RL_SET_CHAR(s, j, item[i]);
                RL_SET_VALUE(b, i, arg, RXT_STRING);
            }

I'd start by printing the length of item... just to be sure its not 
the input which is the problem.

RL_Print("%d, %s", i, list[i]);

add a little newline there...

RL_Print("%d, %s\n", i, list[i]);

I can say, that the **list is filed correctly because when I for 
example use at the tail:
            REBSER *s = RL_MAKE_STRING(strlen(list[2]), 0);
            for (c = 0;  c< strlen(list[2]); ++c)
                RL_SET_CHAR(s, c, list[2][c]);
            RXA_SERIES(frm, 1) = s;
            RXA_INDEX(frm, 1)  = 0;
            RXA_TYPE(frm, 1)   = RXT_STRING;
            return RXR_VALUE;
I get the correct list[2] value.

that only works when you use the types within the argument list... 
when you are creating things and passing them over to functions, 
you must always pass the type as well as the data.

you are only working against the argument list.  I use args outside 
of the commands in other functions which manipulate rebol values.

R3 is cross-platform, and cURL is cross-platform, but both require 
a little work to make the platform distinctions go away. POSIX helps 
with this on POSIX platforms, but that's not everything. You can 
do a little extra work in your extension to make it work the same 
externally, so R3 code can't tell the difference, but if you want 
that to extend to filenames then you have to pick a cross-platform 
filename standard. Once the extension is loaded, embedded or delayed 
it can be referred to by module name. We don't want IMPORT to grab 
extensions in its module-paths lookup because that would make it 
possible to load an extension when you were looking for a safe module, 
so .rx and .so files aren't going to be in the search list unless 
your program sets system/options/default-suffix to .rx or .so, with 
the same security implications.

Oldes, Pekr, I don't know whether extensions can be unloaded. Last 
time I checked it was considered unsafe to do so, because the import 
process doesn't isolate things. In theory you could clean up after 
a module, remove it from the system modules list, remove all references 
to it from all other modules (that you have tracked), and then let 
the module be collected by the garbage collector, but I don't know 
if extensions are unloaded when they are collected.

Maybe I'm doing something wrong...

R3 current version: 2.100.110.3.1
It was released on: 2-Nov-2010/3:55:04.875

Your version is current.
>> do %r3-gui.r3

Script: "R3 GUI - load and start" Version: $Id: $ Date: 9-Dec-2010/10:32:04+1:00

>> change-dir %test-framework
== %test-framework

>> list-dir

core-tests.r   cpl_2_100_110_3_1.log         docs/          flags.r	test-framework.r
>> do %test-framework.r
Script: "Untitled" Version: none Date: 16-Jul-2010/13:05:26+2:00
Testing...
file: core-tests.r
LOAD/next removed. Use TRANSCODE.

Done, see the log file: /C/Documents and Settings/striker/Bureau/R3/test-framework/cpl_2_100_110_3_1.log
Total: 1 Succeeded: 0 Failed: 1


Log file :

file: core-tests.r

failed, file parsing unsuccessful
Total: 1 Succeeded: 0 Failed: 1

Why ?

Could style browser be updated too? It basically crashes with any 
click I tried to the style's list-box ...

Pekr, that's list-box (text-list) style problem. This style is currently 
updated to support more columns than one (called text-table) and 
text-list will be only sub-case of text-table.

The new distribution channel may bring problems like this for regural 
users, at least before BETA is reached. Some developers prefer to 
put changes to SVN only when everything is ready, other developers 
prefer to push changes more often, it might temporarily broke functionality, 
but  it's much more crash-proof strategy.

It's a question to debate if every submit should be a release, or 
if only some special versions should be released, with first option, 
you will get latest release, that may be broken because of we're 
still in alfa-phase, with second option you will get more or less 
working release, but you're definitly going to complain that it's 
not updated too often (even if my estimate of 1-2x week is hit.)

Just throwing something out here (as I'm not actively involved in 
R3 and mostly lurk):  I see "-of" as a "what" or "what are" type 
of question, while "?" more like "what is" (and all the rest) type 
of question.
(does it) exist?
(what is the) length?
(what is the) size?
(when was it) modified?
vs
(what are the) faces-of
(what are the) values-of

Then of course, minimum-of and maximum-of break this idea:
(what is the) minimum-of
But this works just as well IMO:
(what is the) minimum?


So looking at that, I'd consider the "?" or "-of" question to not 
so much be based on logic values, but whether it returns a single 
value, or a list of values.

What informs about a single value or a list is the use of plural 
in the name.

It seems that the memory can't be recalled back. I just watch task 
list, and I can see that running R3 takes some 2.4 MB, doing an %R3-gui.r3 
goes to some 4.8 MB, doing %panels-21.r3 starts at 7.9, but slowly 
grows to 8.8 MB, pressing some buttons/tabbing/resizing, grows the 
memory consumption to 11.2MB (why? ), closing the window does not 
return the memory back (maybe correct, as the window is just "hidden", 
but still interanlly exists?)


I wonder, if there would be any possibility to "unload" window (layout) 
and/or even to unload the gui?

Guys, time to crank up the volume and build a concrete roadmap for 
the GUI. I have a suggestion to further accelerate the development 
of the GUI: RM Asset will over time require some specific, but complex 
styles, that the community will need as well. We are developing a 
SCRUM tool, which you will need to use as a basis for discussions 
and development of these styles. Consider it also training to become 
a good style developer. For any needs, Cyphre, Bolek, Ladislav and 
I will be available to extend the UI base as needed to create the 
styles mentioned below. We also provide examples, training and help.


Many of these styles are focused for development of particular types 
of applications that open many, small windows inside a large work 
area for flexible construction of data analysis tools and other traditional 
Windows or Linux applications.


It could be a combination of how graphics shader networks are built 
(though without the need for zooming), to regular multi-document 
management. The ultimate goal is to build styles that allow a highly 
user configurable multi-document GUI to be described, using only 
the R3 GUI dialect and some helper functions that we already have.

These styles are generic enough to be usable in plenty of apps.

Inspirations for window arrangements:


http://houdini.dreamerzstudio.net/wp-content/uploads/2010/05/reflectiveShaderNetwork.jpg
http://www.codeproject.com/KB/docview/TabbedMDI/TabbedMDI.gif

Inspiration for segmented area management:


http://www.solidsmack.com/wp-content/uploads/2010/12/modo_501_RayGL_sample_002.jpg
http://jedit.sourceforge.net/jedit-snap-12.png

A list of general styles that definitely are needed:


- Style for doing multi-document window management, using various 
arrangements, window linking features, as borrowed from apps like 
Photoshop.

- Style for segmented area management, editable by users, for arranging 
tool areas, view areas. Segments are adjustable in size. Inspiration 
is JEdit and Modo.
- Multi-document window style, for use in window management style
- Tool window style, for use in window management style

- Tear-off style for toolbars and tool windows, for use in window 
management style

- Regular Windows-style menu bar with submenus, also for right-click 
popup menus.

More specific styles that will be needed later:


- High-performance style for graphing points and curves in a coordinate 
system, with zooming and panning.
- Gannt chart style: http://en.wikipedia.org/wiki/Gannt_Chart
- Harvey Ball style: http://en.wikipedia.org/wiki/Harvey_Balls
- Year calendar style
- Month calendar style
- Week calendar style
- Day calendar style

- MacOSX style tag field: http://kitara.nl/wp-content/uploads/2010/05/31.png

- Console style for input and listing results. This could eventually 
grow into the base for a View based R3 console.

- Highly ergonomic numeric input styles, that support unit conversion, 
inline math.

The question is where to start and what fits with you.


The time table is simply ASAP, and preferrably want some results 
within the next 2 months.


If you are planning R3 apps soon, it would be a good idea to have 
a look at the list to see where you may be able to contribute, as 
the GUI moves to beta status. RM Asset needs to spend time building 
end-user apps for R3 and the GUI is becoming ready, except for the 
above mentioned styles.

Henrik - when I scroll above, you created the list of windowing and 
more advanced styles needed. Could we get the list, which will be 
delivered with initial release? E.g. we know, that Cyphre was working 
on some grid engine, etc., so that devs can know, what they don't 
need to focus on?

from the page of RM-Asset.com we can read and I quote:

What's special about RM-Asset?

We are very productive. This is good 
for you because we need less time than you might have thought.

We 
are very efficient. Internally we joke and say 
All good software fits onto a floppy-disk!"


We keep things simple. Our solutions are simple, easy to install, 
maintain and use. Most solutions are designed to complicated. We 
have streamlined designs making us faster while resulting in higher 
quality."


Fine but since you took over this proect we don't even have a prospective 
documentation (list of the widgets you want in it, the condition 
of this project, the stepstones on the road)or an api documentation 
etc... this means 0 lines of code. you claim to be the best to work 
fast to be serious. I just ask you to prove it.

Aha ... and is there any list of "should work well" styles?

are there any accessor functions, how to easily list face, pane, 
style etc. structure? I mean without references? I would like to 
see (e.g. in docs, or by query) the ability to list face, gob, style 
structure ...

Or I have something wrong in the demo code, not yet fully adapted:

view-sub-panel: funct [
	index
	main-pan
	desc
][
	set 'current-panel index
	set-face desc form pick test-notes index
	pan: pick test-panels index
	unless pan [

  pan: make-face 'vpanel [columns: 1 content: pick test-blocks index]
;		insert-panel-content pan pick test-blocks index
		poke test-panels index pan
	]

	set-panel-content main-pan pan
;	switch-panel main-pan pan 'fly-right
]

view [
	title "R3 GUI Tests"
	text (reform ["R3 V" system/version "of" system/build])
	bar
	hgroup [

		; List of test sections:
		text-list test-sections do [view-sub-panel value main-pan desc]

		; Panel for showing test results:
		vgroup  [
			desc: text-area "Please read the instructions below."
			options [
				max-size: 2000x40
				text-style: 'bold
			]

			main-pan: vpanel [
				text "test" ;doc instructions
			] options [columns: 1 init-size: 280x380]

			hgroup [
				button "Source" do [
					either current-panel [
						view-code trim/head mold/only pick test-blocks 
current-panel
					][
						request "Note:" "Pick a test first."
					]
				]
				button "Halt" leaf close halt
				button "Quit" maroon quit
				check "Debug"  do [guie/debug: if value [[all]]]
				check "Remind" guie/remind do [guie/remind: value]
			]
		]
	]
;	when [enter] do [
;		if quick-start [
;			if spot: find test-sections quick-start [

;				view-sub-panel index? spot main-pan desc  ; for faster testing
;			]
;		]
;		;[request "Alert" instructions]
;	]
]
;[reactors: [[moved [save %win-xy.r face/gob/offset]]]]

when a concept of default size is there, that is usually what you 
want the pair to be.  when it goes beyon min or max bounds, usually 
you want to push these to at least match the default size...   the 
developper is expressly asking for an adjustment to the default.


the thing is that when a widget is in an auto-resizing layout, asking 
for 100x100 might not actually give you that size, because all the 
widgets are subject to the layout in which they are displayed.  in 
row/columns, you will be subject to equalizing other lateral sizes 
in the list and may be given more space in the longitudinal size, 
such that in fact, your button may be larger than what you asked 
for.


the only way to force a 100x100 button is for the gui to support 
static sizing within a dynamic layout, or support max-size and set 
it to the exact same as default size effectively making it a static 
sized button.

Robert - I can't see any subsystems ready, other than proper resizing 
(which is really nice), and focusing system. How can you say 2-3 
styles are enough to judge the design? I would not call non-working 
styles being an eye-candy :-) This is all about architecture -  when 
porting demo, I meet the case when I am able to easily change e.g. 
color of the scroller with Carl's GUI, which does not seems to be 
a case with RMA's GUI, or I just don't know how to do it. As I did 
not want to bether you here with such simple stupid thing, I tried 
to study material-system myself. But - I can tell one thing - if 
those things are not simple on the surface, it is either - missing 
docs, or very wrong architecture.


You should really remember, why Carl decided to rework the GUI - 
to be the pleasure to use, kind like of Amiga AMOS Basic, yet still 
allowing more complicated designs. If that aspect will not be pursued, 
ppl will not like the GUI. And what is the system good for, if not 
liked to be used by ppl?


OK, at this point, with 2-3 styles in focus, I might postpone port 
of the demo, no? As the demo is surely done with more than 2-3 styles 
:-) I will soon finish it to the state, when clicking the left side 
list items will not crash the demo. Non working stuff will be commented 
out. Then others might try to get more complicated set-ups running 
...

1) Anyone yet has to prove to me, that having centralised skin/material 
storage will be practically usefull. What tool on Earth will you 
use to visually edit them? Imo none - we will have to come up with 
own REBOL based tool, which might understand all those draw defnitions 
imo


2) Having materials stored in the style (being part of stylize) means 
you can internally do whatever you want with it. In fact - what material 
system does in on-init style phase is, that it physically stores 
the material object into face/material. You could work even the opposite 
way - knowing the list of styles, you can collect all materials, 
if you need them to have in one place - what for, I don't know, maybe 
for some visual tool, where you will be able to tweak them ... one 
day ... maybe ... as surely Photoshop is not usable ...


The fact is, that having materials stored centrally is correct design-wise. 
But having to deal with styles, and based upon practical merits, 
having definitions scattered around lowers usability of the system, 
and easiness of understanding of system internals ...

Brian, thank you for your clear recap and action list.

Seems ok.
Mayby a link to the page with the changes list ?

Following few things:


- why is "custom" include needed? We should either user R3 native 
facilities, or include an include as a standard into R3 :-) (this 
is no real question, just a remark that if we find it usefull, then 
why notto make it part of R3?)

- RMA does not work with CureCode tickets. It would be good to either 
dismiss/close or resolve them? E.g. I find renaming of do-style and 
do-face to do-action, do-reaction a good tip to implement


- we should resolve the size of buttons vs scroller vs tabs. In Carl's 
GUI, button is 28 pixels tall, and it feels OK. Our's here is 22, 
I have no preference here, but could be those 28 pixels. Scroller 
is only 16pix - not acceptable imo. It should be of the size of the 
progress. Tabs are proportionally too tall.

- tabs should have line removed for actual tab. I suspect it might 
be more difficult to draw the container then.

- there seems to be someone at RMA liking Old aqua interface of MacOS. 
Tabs, buttons and scrollers are a good example ... of how to not 
do visuals anymore :-)

- area - enter few lines, go to bottom, and try to hilite the text 
by keyboard (shift plus arrow-up). It always hilites only actual 
line

- info areas, labes, etc., should prohibit display of caret, maybe 
allow hilighting, but allowing to have caret in "disabled" area is 
not looking nice

- text-table buttons are Excel filter inspired, but looking strange 
- some more thoughts needed
- select-an-option does not allow keyboard navigation

- text-list does not scroll, when navigated by keyboard, ditto text-table

- tabbing feels strange for text table. I alway said, that we need 
nested tabbing. I can imagine tab stopping on table, but next tab 
moving away, not actually going into tabbing in terms of the hilited 
widget. Enter should enter the more complex style, escape move away. 
That is not typical also at OS level, but then - everybody has it 
wrong :-)

- between the text-list and text-table, I have to press tab three 
times -visually I am not sure, "where" hilite disappears

- is text-table a compound style? What sense does it have to have 
buttons hilighted, not being able to enter the action? Why are not 
arrows tabbable? Table headers cells should be one style, not two.

- text-table is the weakest "grid" we ever had. Comparing to Cyphre's 
style pack, and rebgui grid. This is like 5% of functionality, not 
thought out style, useless for any serious data. I want to see the 
display of infiinte amount of data, proper caching.

- tab should be tabbable, ctrl-tab allowed to switch between the 
tabs  


I find the styles/gui inconsistent. There should be someone defining 
the styles, their behaviour to keyboard navigation, tabbing, etc. 
So far it seems like style being put together with no deeper thought 
about the end result of the whole GUI.

text-table: This is a very good and powerful style already. It solves 
80% of all use-cases in commercial apps. It's lean, fast and supports 
some advanced features out of the box. Speed of implementaiton is 
focus here, not configurability. The auto-filters are XLS inspired 
but the semantics are extended. You see all available values divided 
into from current shown list (above divider) and from all data (below 
the divider).

(good feature list. We should keep this.)

The feature list is not complete, we miss - 5a. ordering of faces 
for tabbing purpose

There is a slight discrepancy in the syntax of stylize and view.
 - there should be, since they are not the same at all:

stylize: func [
	"Create one or more styles (with simple style dialect)."
	list [block!] "Format: name: [def], name: parent [def]"
...

I'm thinking about a style that is basically a fancy text list with 
the specific purpose of using it as a panel switcher. But specifically 
the animation part, it may be better to have some kind of actor (on-switch?) 
where the animation is handled and can be specified separately.

For me, the differences in the two words is quite sublte. The word 
contents gives the impression of something more tangible than content. 
As an example, I would say the content of the book to refer to the 
overall meaning of the book. I would refer to the contents of the 
book as the list of chapters.

My understanding is that content refers to what is inside, contents 
refers to a list of the content

in a contents sale, one can list each item ...

it'll be up on the site, once Robert gets around to it. I just didn't 
want to spam this group with a list.

list of the *CONTENT functions (current names):

SET-PANEL-CONTENT
CLEAR-PANEL-CONTENT
INSERT-PANEL-CONTENT
APPEND-PANEL-CONTENT
CHANGE-PANEL-CONTENT
REMOVE-PANEL-CONTENT

A terminology problem related to the ATTACH keyword. Every face should 
have an attribute listing the items attached to it, and an attribute 
listing the items to which it was attached. One (let's call it 'extra 
long') alternative might be ITEMS-ATTACHED-TO-THIS and ITEMS-TO-WHICH-THIS-IS-ATTACHED. 
To show you an example, let's have faces A and B, and suppose, that 
the user attached B to A. Then:

1) for A, the ITEMS-ATTACHED-TO-THIS list shall contain B
2) for B, the ITEMS-TO-WHICH-THIS-WAS-ATTACHED shall contain A


The problem is, that the above two attribute names probably aren't 
the best possible (or, are they?). Any "ideal" attribute names you 
prefer?

Screenshot of the UI? Your last Twitter message towards the gui was 
related to creating new skin? I expect it was not high priority on 
your list though?

If I make a patch file that fixes the mezz problems, including the 
module-related ones, will that work? For now (when the module list 
isn't really protected yet) this is doable...

I have a list of fixes and improvements in mind, so I'll see if there's 
some time by the end of this week to put together a patch file. I'm 
sorry that I haven't documented the module system well enough to 
make it practical for anyone other than me to patch it at runtime. 
Improving its documentation is on my todo list, though I've been 
a bit busy at work lately.

We did a simple address list as an example, even preconverting it 
to plain text. It took all afternoon to discover all exceptions and 
fix them, so in most cases, it isn't worth it

My approach was, instead of doing what many others do (try to remove 
things from the HTML that are known to be "bad", eg. use regexps 
to remove anything that starts with "javascript:" or anything between 
<script>...</script> etc.), was to only pass what was known to be 
good, and ignore everything else. This is a bit more limiting but 
I consider it to be safer (you don't have to play a game with attacker 
where every time they find a new vector, you have to add it to the 
"bad" list).

Carl, what version of GCC are you using on OSX?
What happens if instead of
  

  gcc -dynamiclib -exported_symbols_list exported -o a.lib a.o b.o

you do

  gcc -dynamiclib -Wl,-x -o a.lib a.o b.o

Pushed a few of my straight-forward A110 patches, mostly about mildly 
re-structuring the build. to https://github.com/earl/R3A110.

Here's a chronological list of commit summaries:

8ed0b68 Rename about.txt to README
45bf64d Temporarily remove unmaintained build projects
f7237b4 Move libs to platform-specific subdirectories
f8eb7e6 Move makefile to platform-specific subdirectory
5072f47 Remove reb-to.h and pass TO_<target> as compiler flag
2401c40 Minor makefile cleanups
333edad Linux: fix bug#1658: link binaries against libdl
3f1fd7d Linux: improve linkage to libr3
635f228 Win32: add makefile

4f57323 Win32: raise the stack size limit in the resulting binaries
048678b OSX: add makefile for osx-intel (untested)

For more details, see the full commit messages, or just ask me :)

Brian - could you describe the phases we run thru? I mean - first 
you "include" a module, extension, it (maybe) gets into module list 
(catalogue), but still not loaded ... and now - what happens next? 
Is there anything like loading a module, but still not binding it 
for e.g.? And if so, what advantage does such phase have? Maybe it 
would be handy to have a process diagram of how modules work ...

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.

So far, my guess is that

- Premade modules can't be delayed since their code blocks and side 
effects have already been executed.

- Delayed modules can't be added unless they have at least the version 
of an existing delayed module, or more than an existing imported 
module.

- Premade modules can't be added unless they have at least the version 
of an existing delayed module, or more than an existing imported 
module.

- If a overriding module is added and the existing module is delayed, 
the existing reference should be replaced, not overriden.

- If a overriding module is added and the existing module is already 
imported, the new module overrides the old but the old reference 
is still there.

- If a delayed module is a mixin, the module is made and returned, 
but the stage-two delayed source is kept in the list.
- I'm missing something.

Bundle the modules as what Carl now calls "optionally included". 
Also keep a list of scheme prefix to module name, and just auto-import 
the module from this list when a scheme is used in on of the scheme 
action functions (READ, OPEN, ...).

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.

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?

What about the mailing list outage?

The first REBOL mailing list outage happened because the server rebooted. 
The REBOL process that was running the mailing list had been started 
manually, and just kept running. They forgot to add the startup code 
for the mailing list to the init code for the server. But noone knew 
this because the process just kept running for more than 3 years. 
It took a UPS failure to stop the list.

Ah yes, the legendary REBOL mailing list script.

In order to be fully imported into the system, a module needs a name 
that the system can use to refer to it by in the modules list. If 
it doesn't have a name then it can't be reused or referred to later, 
so subsequent imports will reload the module source and create a 
new module. And all unnamed modules import privately, meaning that 
they import into the local context only, not into the system runtime 
library. This means no variable sharing.

GitHub hides the address and replaces it with your user name on the 
site... if you have one registered.  But anyone who clones the repository 
will have access to the address you list.

Rebol is not the only language where file extension issues come up, 
but they're trying to take the sort of Apple philosophy of "we'll 
figure it out" as opposed to there being a web of settings.  It's 
just not high on their priority list to "sense" whether a file is 
Rebol or not.

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`

BTW, for AltME, created an R3 divider for the user list.

Let me reformat the above in the hope of making it more readable:

1. edit /etc/apt/sources.list, add the following line:

  deb http://ppa.launchpad.net/git-core/ppa/ubuntulucid main

2. apt-get update
3. apt-get install git-core

Yes, that's what I did. Only part of that older package list is valid... 
the rest 404's.

Has a list of download links on http://www.git-scm.com/download

But I didn't yet confirm this. Someone who installed with this option 
could do so by looking at the output of "git config --list".

Andreas? Learning git is still on my todo list for this week.

Lad you are well placed to know that iterating over ANY random data 
list in ERBOL will require special cases in EVERY single algorythm 
you can think of.  every datatype has its own idiosyncracies.  


in a way, this is the point of datatypes in REBOL. They aren't generic. 
 so I don't expect them to behave so in the first place.

remove-duplicates, extract-duplicates, remove-same, prefix?, suffix?, 
etc   the list is long.

In the next release of glass, in the TO DO file, I list a few measurse 
to increase performance and decrease ram use by concentrating on 
using as much persistent data than throw away recycling.  but that 
means a complete overhaul of liquid and glob (the rendering engine 
over liquid).

Went through the Parse Proposals list and tweaked the Priorities 
section to double as a status list. Unfortunately, some of the rejected 
proposals must have at some point been removed from the proposals 
page. We wanted to document them and why they were rejected, so they 
don't get proposed again. I may have to go the history and find the 
rejected proposals that were deleted and restore them to the page, 
so they can be rejected explicitly with explanations.