AltME groups: search

Francois, don't forget to post update notices to the Announce group 
as well.

CREATED this group to comment 2.7.xx releases instead of jumping 
around core and view groups.

Here is the group for discussing R2 releases and plans.

Question for the group: where is the best "home" for discussion of 
R2 release?

If people can get on the R2-Beta world and start discussing things 
by end of Tuesday pacific time, we can use that, otherwise all discussions 
will have to be here in this group. If that turns out to be the case, 
please keep the discussion on topic. During the next release period 
we can properly switch to the community development infrastructure 
we use to make R3. Yes, that includes R3 chat.

Whoops, wrong group.

Doc in the Core group: "this could be a really great addition to 
R3 (or even R2)"


Policy: Additions of new globally defined functions to new R2 releases 
almost always must get put in R3 first, go through consensus, testing 
and the REBOL optimizer, then be backported to R2 (usually through 
R2/Forward). Enhancements of existing functions in comparable areas 
of the code (not ports, View or library) also go through the R3 gauntlet 
first. If you want R2 /Core enhanced, get to work on R3.


Change to the semantic model of R2 isn't going to happen: No new 
port model, no new View, no extensions or host code - use R3 if you 
need those. New (real) R2 datatypes are unlikely, though faked backports 
of R3 datatypes are OK and have already made it into 2.7.7, with 
more to come. Natives that can be fixed without changing the semantic 
model or adding new datatypes are fair game though.


Bug fixes will be done though as long as code (that we can't fix) 
doesn't depend on the bug (no fix to PICK, POKE and AT's off-by-one 
error, for instance), as will backwards-compatible enhancements to 
R2-specific areas, like the port model, View/VID and library support. 
Backwards-compatible means we also test it against existing code, 
so if you want to test it against your favorite code, please do so 
and tell us what you find.


These fixes are coming, at least in theory - someone has to do the 
work. If you have a favorite bug you need fixed or enhancement you 
need, do the work yourself or pay someone to do the work (REBOL Consulting, 
perhaps). Changes go in as they are made, and they are made by people 
with priorities. If you have priorities too, act on them :)

Delete the old group.

Hey, can you move this to Core, JavaScript or Parse? This group is 
for discussing R2 releases.

Yeah, we're trying to keep this group on topic. We haven't written 
a DevBase chat client for R2 yet, so the development discussions 
of R2 releases are often in this group. Some people don't like to 
use chat, even if not using it limits the extent to which they can 
participate in R2 development (they can't submit changes directly, 
for instance).

will post the link saturday into the db group.

Bring it up with Carl for R3, or suggest it in CureCode. This is 
all a little off-topic for this group anyways - we should be in Core.

Still really off-topic for this group. We're trying to keep this 
group on-topic for the discussion of R2 releases, so valuable information 
doesn't get buried in the torrent.

The is not like the !REBOL3 group, where anything R3-related is on-topic.

This belongs in rebol school group

BrianH wants to keep this group to discuss 2.7.8

And back in the Core group - we're trying to keep this group on its 
topic of R2 releases. We don't want to lose such discussions in the 
middle of discussions of semantics. The only reason this group was 
created is because some of the people working on the development 
of R2 don't want to use chat yet. This group is *only* a replacement 
for the R2-Beta world.

This is not the R2 equivalent of the !REBOL3 group. Please don't 
abuse the fact that we can't move messages in AltME :(

I'm sorry, I don't want to be a jerk about this. This group is used 
as a reference when we do new R2 releases. It's of less value as 
a reference if off-topic stuff is overwhelming the release discussions. 
Please be nice to the R2 release manager :(

sorry to add junk, but I *really* think this group should be renamed 
(this is On Topic :-)  

probably !REBOL2-release or something like that.


its too easy to mistake right now with !REBOL3 being such an active 
group.

There are group policy settings that can make it so that programs 
can only be run from certain directories, and security settings to 
make it so only administrators can write to those directories. And 
the only reason that they have to do things so drastically is because 
of developers like you who insist on writing Win9x apps and trying 
to run them on Win2k+. Apps like AltME.

We have been discussing things in the open here in this group instead 
of the R2-Beta world (which is why this group is not web-public.

so it's apport from rebol3 ?

is it still usefull to have a R2-Beta world or move into a group 
of rebol3 ?
How to join R2-Beta ?

So a new group group in rebol3 world ?

I think that Carl, Gabriele or BrianH can give you R2-beta access. 
If you need to report R2 bug, you can use any (not R3 related) group 
here and submit it into Rambo.

It might come to that, but I am hoping to keep using this group as 
long as possible to manage the R2 release discussions.

(Whoops, wrong group)

This is from August in the SDK group


Trying to see if .net is installed but this gives me an empty block 


 foreach key keys: list-reg/HKLM "SOFTWARE\Microsoft\Windows\CurrentVersion\Internet 
 Settings\5.0\User Agent\Post Platform" [
                print key
 ]

even though I can see it full of keys in the registry ...

continued from REBOL3! group.


they where not listed in RAMBO... I was just lucky to be online with 
Carl and it got fixed in a beta version of 2.7.7 in one afternoon 
with cyphre giving a more robust fix the day after.


 He also had the fix to another annoying issue which makes first item 
 to follow a space in a text to affect the transparency.  the more 
 spaces the darker it gets.  his even affects other items in a text 
 ends with spaces ! 

though I wonder if that ended up in the 2.7.8 release ' :-/

This group here is where cross-platform starts going away.

(sorry to spoil the extensions group for my question, but it might 
be similar)

If the latter, this question is better suited for the !REBOL3 Host 
Kit group.

Thanks! I've been using R2/Command to do the database access and 
R3 to process the data. All in the same script, using a trick I'll 
post to the Windows group.

how will one name - frame - cover all tight, group, panel?

I mean - what we are after is having tight, panel, and group being 
just displayed in a different way, no other change of functionality, 
no?

I don't know if it is a bad idea, because the combinations would 
be fewer for what kinds of frames you want and you avoid cluttering 
GROUP and PANEL styles. You could say that FRAME supports only one 
face inside it to avoid deciding on flow.

re "I thought that you might find a way of how to do it in terms 
of just one panel" - it is possible to do it in "just one group". 
Do not forget, that R3-GUI H/Vgroups are more similar to R2 layouts 
than R3-GUI (H/V)panels.

yes, class in html is just an 'group-id'

I suggest that classes in the R3 GUI is not useful for the reason 
that it interferes with the "intelligence" layer, where we already 
have:


1. tags to identify state and capability of a face, such as finding 
the default button in the window or whether the button is disabled.
2. name to identify a specific face

3. style name to identify the style and to create a distinct appearance
4. the ability to group faces by panels

5. have information about the ordering of faces stored in the face 
tree

6. use specific policies on how to act on a particular face with 
particular tags

I will be glad, if we have system, where I can easily style elements, 
and configure their parameters. I'll wait how you resolve the FRAME 
style or simply borderless PANEL, GROUP, etc.

Yes, I indeed meant "actually set that way", but, probably, will 
use the method just for panel/group columns/rows. Whether I should 
cater for the dimensions of all objects as well is not decided yet, 
since the problem actually occurred for column width in a panel.

Doh! I should pay attention to the group name. :-\ Must be time to 
sleep.

If we can't come up with something better (which is beyond my imagination 
and the "proper" way would require to come up with xy alternate names 
for all panel/group combinations), I am definitely at least not sure 
about the facet (property) name. Does drawing the surounding frame 
(or simply parametrisation of one of style visual) has anything to 
do with the term "box model"?


I would probably use draw-mode name, but not sure it would not be 
confused with draw frames then? What do you think? Forget the syntax, 
we can't do any better here imo, but what about the name?

but how would you define, what layout engine should be used? We have 
two, no? panel, and group ... and their respective vertical vs horizontal 
variants ...

I very much respect Robert's explanation - this is not a democrary, 
this is RMA's business, and i have no problem with that. I just really 
don't understand, why when I put explanation to why I mistakenly 
marked panels-26.r3 demo as incorrectly behaving here, Rebolek comments 
that I am resisting something. I just put it here, because the group 
is searchable, and my reply contains explanation, which might be 
helpfull to others ...

Some comments:

-the TEXT style in the release has incorrect resizing settings so 
it makes layouts that are being resized ugly. We'll fix that.


-regarding the introduced and discussed:  options [box-model: 'some-word] 

The defined word! symbol should specifiy box-model preset. By 'box-model 
preset' we mean group of facets attributes that affect the box-model 
settings of the specific face/style. So this option is IMO correctly 
named.

Currently the box-model option was added as temporary solution to 
the PANEL style only. But in the next release it will be possible 
to set it on any face in the layout or style definiton. Also we'll 
add basic set of such box-model presets that will be part of the 
system by default.


-ALIGN vs. HALIGN: yes, we borrowed the terms ALIGN/VALIGN from HTML(but 
note, it is used also in R2 font object and in R3 para object) . 
As people today are familliar with it and have it 'wired' in their 
heads using the same name could avoid silly bugs in their code.

I presonally don't think this must be consistent with names of styles 
but if majority people insist of such kind of consistency we would 
probably need to unify also the align word in the PARA object as 
well.

Why not leave panel and hpanel as synonyms, and group/hgroup ?


It's entirely possible, but would that not make layout code harder 
to read/understand?

But - jokes aside, I am starting to like the idea of having PANEL/VPANEL, 
and GROUP/VGROUP .....

If I understand Graham correctly, he suggest to have default a horizontal 
alignment = compatible with underlying align/valign. Hence what he 
imo proposes (and I agree with), is to remove "H" letter from PANEL/GROUP

Graham:

Why not leave panel and hpanel as synonyms, and group/hgroup ?

Pekr:


I am starting to like the idea of having PANEL/VPANEL, and GROUP/VGROUP 
.....

so, you have to agree on the flow direction. :-)

I was saying that group & hgroup are to be synonyms

Hi, guys

Once again, congratulations for the excellent work done.

As Rebolek suggested in ALTME, I have some modifications to submit 
(of course, to check from your side) for the next r3-gui release.


I must first mention that I just realized this morning that the r3.exe 
 pre-compiled version of march 11th was not working properly, bugging 
with some very simple text displays (probably an old version). That's 
the reason why I did not update the demo with the most recent r3-gui 
file. By the way, the  build date displayed by the exe remains the 
same whatever the real building date. I don't know how we could have 
an automatic update of the build version.


Rebuilding from your sources (march 11th) allowed the demo to work 
properly apart from some appearence differences (I have even seen 
some bugs solved compared to my demo version). However, I will wait 
for your next weekly release ;-) to update my demo.

Coming back to the propositions of modifications :


It seems that there are definitions problems, or incompatibilities
in r3-gui (around line 66)        
;-- circle: [pair! | number! | number!]    
circle: [pair! | pair! |number! | number!]

in r3-gui (around line 1729) 
;-- scale: [decimal! decimal!]  
scale: [pair!]

also, I overload the drawing style by this code :
stylize [
    drawing: sensor [
        about: "Simple scalar vector draw block. Can be clicked."
        tags: [input tab]
        facets: [
            init-size: 100x100
        ]
        options: [
            drawing: [block!]
            init-size: [pair!]
        ]

        actors: [
            on-make: [
            ;    if block? drw: face/facets/drawing [
            ;       bind face/gob/draw: copy drw face/facets]

            ]
            ;-- JC
            on-draw: [face/facets/drawing]
        ]
    ]
]


Concerning the discussion of this morning on groups and panels, I 
would also prefer to have a default horizontal arrangement, and only 
precise when vertical: group, panel, vgroup, vpanel. A side effect 
is that it would remain compatible with Carl's doc.

By the way, it seems that tight is vtight. Logically, it should be 
htight.


That's all for the moment. When debugging the last demos, I may find 
other issues.

My notes to the HPANEL versus PANEL issue:

* Carl appears to prefer PANEL

* unfortunately, the situation is not as easy as it looks at the 
first look, since Carl's documentation uses the word 'panel' it yet 
another sense, every style able to contain faces, such as a group, 
etc. is called "a panel" in Carl's documentation, which would immediately 
lead to confusions, requring rewrite

* e.g. the INSERT-PANEL-CONTENT, or some other function names would 
be confusing because of the above mentioned issue, since the function 
in fact inserts content to any "face containing style", not just 
to HPANELs


So, the amount of rewriting both the code and the documentation would 
be quite big.

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.

2-2 - comment - if we stay with align valign, then let's go panel 
vpanel, group vgroup. I think that vertical option will not be used 
so often, and so the code will be nicely readable with just panel, 
group?

Suggestion: If you have user-defined styles, then why not just go 
with a very basic set of styles to begin with, like only panel, group, 
etc. And then you could make an advanced version of the GUI (by including 
some script with styles), where you give users vpanel, vgroup, etc.

et-panel-content
clear-panel-content
insert-panel-content
append-panel-content
change-panel-content
remove-panel-content

set-content
clear-content
insert-content
append-content
change-content
remove-content


; Disadvantage of following group is, that it does not relate to 
the content, and hence we are reserving/blocking those names for 
our particular purpose.
set-in
clear-in
insert-into
append-into
change-in
remove-from

Think about them in the usage scenario,e .g.:

insert-content my-panel [content here]
insert-into my-panel [content here]

A post to keep you informed about what the ELICA LOGO can do relative 
to 3D graphics, animation an GUI (under windows only) - all their 
libraries are open source and I thought you would like to know about 
- see the link in the OPEN GL group. Hope it can be useful in some 
way or another. Regards, Gerard

Robert - I think that it is not accurate, that noone is interested 
in the R3 GUI. IMO we all are, it is just that each of us is busy 
elsewhere. If you look into the past of this group, or in the old 
GUI (Carl's one) old days, it was mostly me and 1-2 users to do some 
comments, studying code, etc. It is about the general lack of man-power. 
E.g. shadwolf claimed, he can do tree view in few hours, but is refusing 
to, and you better don't read the long blog chat. It is also about 
lost confidence of many rebollers into R3 in general. Or just maybe 
- ppl being in wait mode, untill Carl reappears?

(This should be in the !REBOL3 Graphics group, where it will b e 
useful)

All of those changes where discussed (mostly in the "R3 Source Control" 
group) back in November before Carl went incommunicado in this AltME 
world.

Do we need a RED group .. like the Boron group?  Doc, where are you! 
 ?

if RED is becoming serious attempt at REBOL similar languages/clones, 
then we need new group.

We're a bit OT here, don't want to hijack the group.

well, the group purpose is completed!

ok, should move this to boron group...

Yes, we had a discussion about this in the Core group recently. See 
posts around 13-May.

Sorry, my last post here was an answer to something in the !REBOL3 
group.

From group Core-old:


A: the PATH action is what the interpreter uses to evaluate VALUE/selector 
expressions for each datatype. It is an internal action and has no 
external purpose in programs. These kinds of words often appear as 
a sort of 

side-effect" from how REBOL is structured.  Datatypes are implemented 
as a sort of object class, where the interpreter "sends messages" 
to the class to evaluate expressions. The PATH action is a message 
that tells the datatype to perform a pick-like or poke-like internal 
function."

It seems to original come from a post in group "RT Q&A" dated 11-Dec-05.

This is about the HTTP scheme, but I can't find a group for R2 schemes.


Does anyone have a patch for the HTTP scheme that handles 204 (No 
Content) responses where no headers are returned? The standard scheme 
throws an error as there are no headers to parse. Here is the 'success 
case handler:

        success: [
            headers: make string! 500

            while [(line: pick port/sub-port 1) <> ""] [append headers join line 
            "^/"]

            port/locals/headers: headers: Parse-Header HTTP-Header headers
            port/size: 0

            if querying [if headers/Content-Length [port/size: load headers/Content-Length]]

            if error? try [port/date: parse-header-date headers/Last-Modified] 
            [port/date: none]

            port/status: 'file
    ]


For anyone familiar with the scheme, would the proper behavior be 
to set all related 'port fields to zero or none? e.g.

            port/locals/headers: headers: none
            port/size: 0
            port/date: none
            port/status: none

The data exchange dialect is a good point to have constructs. Then 
my logic goes:


REBOL values can be divided in two groups, 1. the ones with a non-ambigious 
lexical representation and 2. the ones without such lexical representation. 
Datatypes of values in the second group include:


unset! none! logic! bitset! image! map! datatype! typeset! native! 
action! routine! op! function! object! library! error! port! event!

and maybe a few more depending on what version of REBOL. The rest 
is in the first group.


It would make sense to have constructs for the values in the 2nd 
group. Then I look at some examples of constructs:

#[string! "abc"] #[email! "[abc-:-d]"]


Those are not necessary. If it's because all values can be represented 
as constructs, then why doesn't this work?

>> #[integer! 1]
** Syntax Error: Invalid construct -- #[


And how would values of type native!, action!, op!, etc. be represented 
as constructs?

I'm not convinced.

(Notice this is the "Core" group, not the "!REBOL3" group, and I'm 
talking R2.)

John, it sounds like where you get confused, or think of things as 
bugs or design flaws, is when having your REBOL "That's funny!" moments, 
borne of deep tinkering. Aside from the "copy series in funcs" behavior, 
which I think bites many people at some point, your issues don't 
come from writing application code in REBOL and bumping up against 
REBOL's behavior. Rather, it seems that REBOL's implementation and 
design don't match your expecations in these cases, and you really 
want it to. :-)


The reason I asked about consequences is because you may want a change 
that affects other users negatively. Imagine REBOLers as being in 
one of two groups. Group A is the gurus. They have internalized REBOLs 
design, understand it deeply, and use BIND and recursive PARSE rules 
without fear. That group is very small. Group C contains everybody 
else, which includes people that don't know about using /local with 
funcs, and suggest REBOL should use  = for "assignment". They have 
never used USE, BIND, or many other functions, because they aren't 
sure how they work. Some of them know a little about series references, 
so they always use COPY to be safe. (Yes, group B exists too, but 
they are much more like C than A).


If REBOL were meant only for A users, it would be very different. 
As a designer, it seems pragmatic to make it so things work well 
for the B and C users who, when they hit a problem that requires 
advanced understanding, will work around issues with the bits they 
understand (and adding many COPY calls), no matter how inelegant. 
Group A users may suffer at their expense, but I'm OK with that, 
because I'm not one of them.

I am not sure which group to choose for this poll for REBOL preprocessing 
directives. I hope this one can be used, but wait for a moment before 
going ahead to allow for objections.

What I mean, regarding %localize.r, is that any script that defines 
directives (one or more) could use the naming convention. And it 
makes perfect sense to group related directives in a script.

BrianH, if I deliver an application to a client and he says to my 
face... why does it jerk every 2 seconds?


I really don't care about if the GC might change.  right now I can't 
do anything to help it.


if it changes, I will adapt my code to it again.   This is platform 
tuning and it is inherently "close to the metal", but in the real 
life, such things are usefull to do... 

just look at the 1 second boot linux machine in that other group.

I just realized where really in the wrong group ;-)

[new group for R3 parse discussions, as requested]

Btw, if there are other bugs in R3's PARSE that need to be discussed 
before being submitted to CureCode, this seems like a good group 
to do so.

This group is for discussion related to DocKimbel's (SoftInnov) Red 
language.

whoever created this group .. check your spelling!

Red's web forum now opened : http://groups.google.com/group/red-lang?hl=en

Maxim: see http://groups.google.com/group/red-lang?hl=enfor the 
anwser to that question.

yeah, I thought the news group was the intended method of communication

Would need to make this group web-public first :-)

If you have some technical questions about Red, please use preferably 
the official channel at Google Groups: http://groups.google.com/group/red-lang?hl=en

Thanks.

Graham: I've posted a short reply to your code bubbles question here: 
http://groups.google.com/group/red-lang/browse_thread/thread/8ecea42063ee4e14/6f7364ebadc7291d?hl=en#6f7364ebadc7291d

Can't find any settings in Google Group allowing to change the default 
threshold for word wrapping...I find it too low when reading messages 
from the web.

Characters range: yes I need to change that, PeterAWood posted a 
note about it too: http://groups.google.com/group/red-lang/browse_thread/thread/99e14e44fbf69abf?hl=en

Same with the bit!, bitset!, logic! group. Bits and bitsels are storage 
types, but logic values are what conditional expressions work with. 
This also has the benefit of letting the compiler avoid putting in 
if 0 checks all over the place and just go by condition codes instead, 
especially for inlined control flow code.

Thanks guys for the insights and propositions. I found it a bit difficult 
to follow in realtime, I'm not sure that AltME is the best tool for 
such conversations. Maybe we should give a try to the Red web forum 
next time: http://groups.google.com/group/red-lang?

Anonymous posting is supposed to be possible now on the Red Google 
group, but I can't

Posting anonymous comments on the RED blog is now possible. It is 
not possible to post comments anonymously on the Red Google group.

This article was an influence in the decision to request people to 
register to the Google Group - http://ejohn.org/blog/google-groups-is-dead/

I'm curious what Reichart is thinking about such improvements to 
AltME (preferably in the !AltME group).

http://groups.google.com/group/red-lang/feeds

I guess you wanted to post that to ~Vent group and posted that here 
by mistake?

Peter changed the topic when he said "I don't believe it is GPL because 
of that just as all Java code is not GPL because Java is GPL.", and 
that is what needed clarification. Unfortunately, I couldn't move 
that message to the Licensing group, or edit my responses to be more 
clear (stupid AltME).

[New group to replace the old one that was somehow causing AltME 
resync problems]
Previous postings are here:
    http://www.rebol.org/aga-display-posts.r?post=r3wp439x1