AltME groups: search

PNG can't scale, no? And I can be PNG file smaller than vectors transferred? 
The slowness of whole stuff is another thing.  Dunno if we can support 
SVG out-of-the-box. We are using AGG, while the rest of the world 
is using Cairo.

Remember this is free http://football.fantasysports.yahoo.com/f1/78924
  Even if we don't get the 14 teams then I will open it to yahoo 
public to fill the rest.

Two things:

= The subtle question = 


We have played with a lot of software, and ALL of them (that we have 
tried) have failed to produce a final product that works.  Meaning, 
all players (WMplayer, WinAmp, VLC, etc.) do not allow skipping, 
and, again, keep in mind, this is using Windows tools to Rip, and 
then encode (usually two products have to be used ).


I make this clear because I'm not questioning that this can be done 
correctly from Linux (or perhaps Mac even).


So my question is really "[are you sure] from windows you can produce 
a 700m avi from a DVD that allows skipping [keyframes] on Windows?"


Our search of forums tells us others have the same problem, and people 
eventually give up and go to linux.

(Warning, rant ahead) :)

= The law = 


First, we all have to recognize the laws are slightly different in 
each country.  Part of what makes this confusing is that America 
tends to set the "tone" for the rest of the world (since it makes 
the most profitable media in the first place.  Not the most media 
keep in mind, for example Iceland makes more books per person for 
example).  And what makes this really confusing is that America has 
state and local laws, which can conflict but will still be overruled 
by federal law.  Marijuana is a good example.  Some states say YES, 
and the Feds say NO.  So you are still committing a Fed crime if 
you use this stuff.


However in the case of copyright, it is the other way around.  Organizations 
say NO, and the Feds say YES!


But the REAL trick here is that software that cracks DVDs is illegal, 
but having the resultant backup is not.  How is that for confusing?


Bottom line, there is a fair use act, which stands, but another law 
that makes getting that fair use to work for you that is illegal. 
 I should probably blog this since I could not find a good example 
of this clear statement on the web. 


However, the best thing I could find was just the simple Wikipedia 
entry for the judge herself that both made the heavy blow, but also 
defended the other individual rights.  

http://en.wikipedia.org/wiki/Susan_Illston


Personally, she symbolizes to me the scariest type of person in power. 
 Which is, she became myopic and decided to just solve the one problem 
in front of her, as opposed to requiring that the issues be solved 
correctly higher up so that this small problem could be handled.


In other words, she saw a leaking toilet, and ruled that the water 
should be cut off to the bathroom.  Then turned around and said, 
but everyone has a "right" to use the bathroom.

It is people like this that allow tyrants to gain power.

(end of rant)

I think that your answer is too abstract :-) All that guys wanted 
was - any known rebol datatype should be recognised, and the rest 
should be assigned under junk! or similiarly named datatype. What 
is AI about that? :-)

any known rebol datatype should be recognised, and the rest should 
be assigned under junk! or similiarly named datatype. What is AI 
about that?

 Telling the different between a REBOL value and "the rest" is AI. 
 If you can without AI, then "the rest" is defined with a specific 
 parse rule... then you can just use string parsing, and it's not 
 a human language anymore but a specific language you just designed.

the point is not to replace REBOL's syntax, but allow REBOL to cope 
better with the rest of the world's data, IMHO.

And I could LOAD %cobol.cob  and do all kinds of super cool preprocessing. 
 Or at least wait for Sunanda to write a super cool preprocessor 
and live vicariously through rebol of the year candidates.  ;)


REBOL could be the JavaDoc, EpyDoc, Doxygen, ..., ReST besting documentation 
super tool of tomorrow.

who cares bad or good the only goal is to do teh trick, satisfy the 
client and get the monney the rest is useless

Naperville came first, then Chicago. Many of the suburbs started 
out as villiages or farming communities - the rest are filler. The 
grid is no more than 150 years old at most.

name of the group does not explain anything at all imo

 - it does for anybody being able to read. Your "post messages you 
 want Carl to read" is just twisting the meaning. There is no excuse 
 for you doing so ("I can see no Carl's original posting") since you 
 cannot deny you read the original posting. That would be just another 
 twist of reality (a lie) and you should know it as well as I do. 
 As far as the rest of your twisting logic is presented, I react with 
 "no comment".

Hi guys;
  Thanks for the input.


PeterWood & Anton:  I could have sworn that I tried both to-char 
and to-string.  It is the obvious answer, but I have been trying 
so many things in solving a parse problem that I missed it.  Now 
I remember, I did try them but at the time I complicated the character 
testing by using quotes and brackets and braces, or in the case of 
the hex string - not using the #{}.  Anyway, thanks for your time 
in answering. 


Gabriele:  As I was waking up this morning, I was thinking about 
modifying your CVS parser to make it work with (improperly) quoted 
strings.  That may be the simplier answer to my parsing problem.


MikeL: I started by not using the /binary but then the 'read' converts 
the #{0D0A} sequences to just #{0A} so I was going to try using the 
/binary option to preserve the original #{0D0A} and got sidetracked 
into changing the rest of the file back into a string.  Turns out 
that I will be going back to just using the 'read' without the /binary 
option and try modifying Gabriele's, CVS parser to handle improperly 
embedded quotes.

Hmm... I'm not sure. I think the problem is that of coding too many 
hours without rest.

Can you prepend the read with print to get the rest of the message?

so it thinks the rest is a big string inside the tags

Alan;  You can try  var: load/header/next   first var will be the 
header as object, second var will be the rest of the script as a 
string.   var/1/version should be your tuple!  (assuming you use 
tuple).  In terms of the evaluation it is deemed "light", values 
but not code.  So   version: 3.2.1 ok,  version: to tuple! [3 2 1] 
 won't be a tuple, var/1/version will be 'to   So Anton is correct.


Another thing to check out the mezzanines (from View)  load-thru 
  read-thru  and the source for exists-thru?  These may have some 
hints for what you want.

Pavel, I've done various things for IPC. There is no standard REBOL 
solution I know of though. How best to do it depends on the rest 
of your app, it's design, and what you mean by "event marshaller". 
Simple TCP has worked well for me in the past.

("what follows it" could be all the rest ...)

It's a strange situation, you have Fork, that I don't understand 
completely, but you can do this:

>> f: func [v] [to-lit-word v]
>> reduce [y: 'x switch f y ['x [print "Hello"]]]
Hello
== [x unset]


You get "Hello" printed, and the result of the reduce is a block 
containing x (from y: 'x) and unset (from print, which returns unset). 
I suggest, you move on and use REBOL some more, then after a while 
go back and look at this problem again. You might then see it with 
new eyes. I had programmed in many languages in many years before 
REBOL. It typical took me a week or so to "get" a new language, to 
understand it more or less completely. It was different with REBOL. 
It took me more than a year to really "get it". That's normal, because 
REBOL is so different from most of the rest.

The weird part Henrik;  most rebols are talent.  Or they'd be C coders 
and rely on mickey soft visual studio products.  But I'll agree. 
 Superstar rebols can drag the rest us along quite nicely.  :)   
(Note I said rely on ... not dissing anyone that uses studio ... 
just dissing those that use it a crutch to pretend to program.)

It appears to see a broken path and sees the rest of the path as 
an argument.  Not sure where it is checking yet to get this information.

The rest is understood that it should work they way it should be 
cause of the manner of words in REBOL.  But the function of lit-word? 
is what to me seems inconsistent.

There are a few functions that were originally written by Carl - 
7 of the 67 are slight tweaks to functions Carl wrote, the rest mine.

Or as Carl put it in the "Tech News" group on the 19-Sep: 

I say: Push forward and ignore the noise, recruit newbies, use the 
great ideas, dump the rest.

BTW, I'm trying to make it blend in as good as I can with the rest 
of VID by using the same keywords and functions.

MS had to disable the NS-compatible plugins by court order - some 
jerk (EOLAS) patented the idea of a plugin in a browser, and the 
overloaded US patent office didn't notice the prior art, much of 
which predated the Internet. Still pending, but MS preemptively dropped 
the patented method (the EMBED tag). EOLAS is waiting to see how 
this turns out before suing the rest of the world.

first infunction::
  at-ref: at at: get in system/words 'at
and the rest can stay the same. not elegant, but..

Give me one thing - decent keyboard support, add tree-view, better 
grid to Rebgui, redesign widgets to visually support in-focus state, 
and you are done! Then go and look at your "app" source - very nice 
dialect - you will NOT find anything like that anywhere. Very nice 
and readable code. The problem is, VID stopped 80% on its way to 
success - the rest, those missing 20% ruined it.

Each scanline has to be mapped onto the original image to find the 
colours. If such a mapping is made with straight lines, I predict 
the result to look ok with nice rectangle-like figures. But if one 
corner is far away from the rest, or moved in between the others, 
the result might be awful. A better way could be to map the scanlines 
as Bezier-curves on the original image. Could be interesting to know, 
how AGG does it, now that AGG's result is so good.

yeah, but when showing the face, would that affect the rest of the 
layout?

or .... such group should produce UI guidelines for others to see 
... that would be even better, so the rest of us - ready-to-test-hungry-rebol3-ers, 
could be sure, everything is under control :-))

There isnt much different to plain faces. There is a block /init 
which is called after all arguments are loaded by 'layout. Arguments 
are put in the appropriate facets, if there are some of the same 
type, they are put in a block instead. so two colors go into /colors. 
There is some magic with keywords, which needs more space to explain. 
but for quick things you can pass args in 'with. Styles have their 
own source in /facets, so you can look there. Best with deskop/tools/vid-style-tree. 
Start fresh things with 'image or 'box,  examine things by with[probe 
self]. The rest is the same as plain faces, and there are some docs 
now.

I want to take an existing paper form .. prefill it with some default 
values that vary for each user... get the user to fill in the rest 
and then print.

Ok, I've traced the problem to 'clear-fields. How can I protect this 
particular field so that it is not cleared by 'clear-fields with 
all the rest of the fields upon save?

I would just like to put the panes I don't want to be cleared into 
a block; all the rest would be cleared.

the porting effort for RT should be easy - they will keep closed 
source "only" the platform neutral rebol library .... the rest should 
be open source ...

Gabriele: I think that what we need is just to be able to display 
unicode characters in View. I don't think, it is such a problem. 
The rest is almost done or can be done by us.

Chinese! :-) Cool! To better see the character, you can make it larger 
with this:

view layout [
	box 4 * 128x128 black effect [draw [
	scale 4.0 4.0
	anti-alias on
... followed by the rest of Jerry's program.

Pekr has an aesthetic argument against the idea that the platform 
of the future would have lots of bloated javascript powering its 
behavior.  I am just being more practical, and don't understand why 
I would care about how much javascript is implementing the UI any 
more than I'd care how big the windows GDI DLLs are.  What matters 
is the dialect... the rest is platform I'm willing to ignore how 
it's done.

My biggest problem right now is the coordinate system, vertical positioning 
of text and text wrapping. The rest is almost in place.

The 3rd party ones (the last two) are pre-done. The rest are done 
with R2.

Can I see a demo of your technique, Steeve?

I wanted transparent events along with transparent regions of a face 
(eg. a face with rounded corners, the events should pass through 
the corner regions, but the rest should land on the face).
It just couldn't be done properly - see my file
http://anton.wildit.net.au/rebol/gui/transparent-events.r

Thank you.  After a rest and some more digging I found a few ways 
to fix.  The most obvious - which I overlooked - was a prompt during 
the installation.   I like everything in one root folder.  Much easier 
to sync between home/work/laptop etc.  Just to be extra safe, I added 
the code you proposed.  Thanks again.

It's all the "meat" that comes after using the dialect to generate 
the face tree. There just isn't enough functions to manipulate the 
face tree. VID is almost a misnomer in this sense, because the dialect 
only performs the very first part of controlling the UI. The rest 
is up to the meat.

I don't want to give up dynamic GUIs, and I think we have a perception 
that everything should be as easy as VID, or at least not too much 
harder. We are missing some key ingredients, which makes things much 
harder, but if you ever tried to develop a custom Windows control 
in the early 90s, you might not say REBOL makes it too hard. Then 
again, you might. :-) Entire companies were built around, and devoted 
to, providing small sets of custom controls, sometimes just one. 
TrueGrid comes to mind.


Great things have been done, even without docs or all the right pieces 
to make it work well. If R3 can provide the necessary hooks, events, 
and docs, I think we can do the rest. Honestly, at this point, I 
would be happy to have RT *just* provide the core pieces. If Henrik, 
Gab, Ashley, Cyphre, and a few others can agree on what to tell Carl 
they need, all Carl has to do is be willing to give their work an 
official blessing.

I'm trying to extract info from faces in a panel but I can't get 
it...


I can see the objects! with mypanel/pane but what is the rest of 
the path to get to say a buttons "data:" field?

the SAT (Separating Axis Theorem) algorithm is even optimised so 
it only manages the edges facing each other.

the result will be several times faster since we end up only comparing 
(at a maximum) half the edges of each polygon ( for two boxes this 
ends up being 2^2+2^2 (8) as opposed to 4^2+4^2 (32)comparisons. 
 for a triangle and a box, it could even end up being as little as 
1^2+2^2 (5)  instead of 3^2+4^2 (25).


the advantage of the SAT algorithm is that its reasonably fast and 
is an early opt-out loop, so the moment we find a single comparison 
which is negative, we can positively ignore all the rest.   this 
means that it scales pretty well, when polygons aren't close to each 
other or when they are small.

If you cut part of an image out, the rest of the image collapses 
in.

henrik, try typing on a (small) touchscreen when shacking, its even 
worse, this device doesn't need to be precise, which is the point.


now one thing they don't mention is that our brain has an internal 
"rest position" hard-wired, and that is where the center dot is very 
well tought.  whenever you move any part of you body, the moment 
you stop thinking about it, it goes back to its rest position by 
itself.  this is very obvious when you swipe you mouse quickly, you 
hand will go back to its original position by reflex.


so using this in a shacky environment, where I can squeeze the device 
in my hand will, IMHO, be much easier to use quickly.  its obvious 
it takes a little bit of time for your brain to associate the letters 
to direction and rotation amount, but since doing the next letter 
is just a question of going back to the rest position, I feel its 
very fast and easy to get used to.

Is there a way to scale an image using effect [draw [image pic]] 
without giving coordinates as in effect [ draw [image pic 0x0 200x200]]


I believe the coordinates are for location on in the frame and I 
just want it rendered inline with the rest of the vid objects

Carl used show2.r while the 'rest' use 'show.r'...I think.

I believe, Robert was the only one on powerpoint

I think the lesson for next year would be "hold it someplace where 
you know you can get to the outside world," because the rest of us 
get a little cranky :-)

about all the rest: i think we could arrange sessions here on altme 
to have discussions.

imo plug-in should be developed for mozilla, as there is general 
cross-browser plus vendors agreement on that - new type of plug-in, 
supported by "the rest", and then and only then to look at IE crap.

Judging from the activity on rebol3,  it realy looks like it recharged 
the batteries of everyone present ... and thanks for including the 
rest of the community with the videos.

http://www.wavemaker.com/product/screencasts.html...open source 
java ide for building web sites incorporating REST/SOAP etc

The protocol is the Tech News. All the rest of the complaints about 
Google are not related to this Tech News.

Pekr, you do realize that Google's Native Client is a browser extension, 
right? And it's for use within HTML, which will usually be served 
up from a server? And that it won't run outside of a browser? Google 
has been advocating the rich client for years, but the rich client 
that it has been advocating is the web browser. This is just them 
acknowledging that Javascript sucks for some purposes - they still 
want you to use the rest of the web stuff.

that's not communautary work... that's not the way a community should 
work you think the guys in blender, gtk+ the gimp etc... work without 
exchanging informations each on their corners and that's how their 
projects goes on? We are not alot so we need to be more focused than 
any other and creating distansions and oposing the gurus to the rest 
of the world isn't the right path. But as yuri said on another forum 
lesson 1 rebol is a bobbistic language, it's the hobby of Carl and 
the hobby of most of us and that's why when it sucks people disapears 
to do other things.

I managed to build one, which is simple. Sending commands to the 
printer, I had to give up and chose to build postscript files for 
an adobe postscript driver instead and let it handle the rest.

Most of the Ruby programmers I know have Mac laptops because they 
make electronic music on the side, and picked Ruby because of its 
OSX support. The rest run Linux on the desktop. Some do both.

It could be interesting to compare prices of electricity around the 
world. Also the prices, Reichart and Max give, are they total prices 
incl. all vat, tax and distribution?


In Denmark, where I live, we pay around DKK 2.00 in total per kWh, 
that's USD 0.39 per kWh. 1/5 of that is vat (danish: "moms"), almost 
half is a special tax on electricity, and the rest is split in actual 
price of electricity and its distribution. See pie diagram here:

http://www.dongenergy.dk/privat/El/omelprisen/Pages/om elprisen.aspx


In Denmark 25% of our electricity comes from wind mills, many located 
in the ocean. If some of you pay 0.075/kWh, that seems very cheap.

Neither has 99.9% of the rest of the world - totally crazy

wrt printer, yeah, I REALLY hope he gets the plans out, I'll build 
one for sure.  my dad has a commercial machine shop with milling 
machine and all the rest.

Sounds reasonable, the rest is just bureaucracy.

The theorists who know what that are talking about will have a lot 
of fun with that evidence, Graham.


The rest of us can make things up -- like perhaps neutrinos are the 
only things that actually travel in a straight-line at a quantum 
level; photons take a longer path because they are bouncing around 
a bit.

I would prefer that RT would work on the foundation, rather than 
something quick and sloppy that tries barely to cover everything 
like VID does. We'll help with the upper layers of GUI element design. 
That's not design by commitee, but simply compartmentalizing who 
does what. With R3, I had expected the goal to have as small and 
efficient a core as possible, with the rest being open source. Carry 
that philosophy through with the GUI as well, so RT can do a fast 
and efficient basis for a GUI and let actual artists and GUI designers 
work on the GUI.


This way, if some of us want a serious GUI system, we can build that 
and if we want something very fancy and artistic, we can build that 
too and both will not compete with eachother, but supplement eachother 
instead. I hate to see double work done in such a small community.

Maxim - whatever, but my undestanding is, that Carl really does not 
want all your technology. Start a dialect - start closed group of 
few named persons and at least outline solution - publish agreed 
or problematic bullets .... the rest will add opinion ... meet once 
again, close design doc, ---> implement

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

Maybe I'm more patient than the rest of you? :-)

As most ppl from here are already in alpha world, I suggest releasing 
for the rest of this world. I could even imagine voluntarily prepare 
some summary of tests/opinions/bugs in special channel here, so that 
Gabriele or others could bring it to alpha world, to prevent flooding 
main testing group with lots of chat ....

Brian, that wouldn't be too bad would it .. if you got cut off .. 
you'd just be like the rest of us!

I'll +1 on Kaj's remarks.  I'd like to see Gabriele be allowed to 
apply some genius to VID3 then drag the rest (most) of us up to where 
we should be.  Chris and Henrik and Robert and Maarten et al will 
then produce all the cool code we've come to expect, but from a higher 
view point and perhaps from a slightly different slant than we are 
used to. imho.  And I do hope that VID3 work will be as shareable 
as the best of the library functions, umm, we don't really have yet. 
 :)

ASCII characters fit in one byte, the rest take some more. It can 
progress up to 5 bytes but those are rare.

All;  I'm the volunteer for the new VID 3 documentation.  (And don't 
really feel that worthy, but that can't be an excuse to make it complete, 
concise and a nice read ... anyway ...)  It's only just in initial 
draft still (my bad), but it's all to save Gabriele and the rest 
of the core team time so they can get to the important bits.  


If you have anything that needs clarification, discoveries, how-to, 
complaints, well anything; please drop a note to this group, the 
btiffin user chat or please feel free to update the discussions page 
from http://rebol.net/wiki/VID_User_Guideand we'll try and keep 
some of the flotsam and jetsom noise out of Carl, Gabriele, Richard 
and Henrik's way while they finalize the REBOL 3 VID.   (And being 
a wiki, feel free to update the actual doc for that matter; keeping 
in mind that consistent style and tone is also one of the goals.).

Thanks and cheers.

A small status update for those interested: VID3 work is commencing. 
Gabriele is building a dialect to make it simpler to build VID3 styles, 
lots of discussions coming from that. The rest of the team are commenting 
this code.


Carl is still busy with Unicode. In fact there is so much to be changed 
due to Unicode, that we had a discussion yesterday seriously, whether 
R3 would still be called REBOL afterwards. The conclusion was that 
it was not a good idea to rename REBOL to something else. :-)

A couple of bugs reports have been made, but nothing crazy yet.

Ingo;  I would say dig in.  If only to blaze trail for the rest of 
us.  :)

Gabriele;  ???  NOOO!   Sorry you read my cheerleading that way. 
 I was diss'in me not you.  It was my lame attempt to explain why 
some the VID3 docs aren't up to the snuff that they should be.   
As I've said before ... keep on writing the mondo complex stuff so 
the rest of don't have to.  :)

rest of US don't have to.

your design process is very short. it's very different for a system 
like VID3. the rest is implementation, which is more trivial.

The main block to View being opened is not DevBase, it is that the 
core design of View isn't done yet. REBOL has a lead designer - we 
don't do design by committee. The rest of us refine the design and 
make really cool stuff based on the foundations, but the lead architect 
is still Carl.

Right now Carl has an idea about REBOL that he is working through. 
The rest of us who are working on R3 are also busy, so overall we 
are letting him do it with little complaint, while we are getting 
stuff out of the way for the next push (AFAICT).

Brian: sure, user defined types are interesting features, but do 
you seriously think that such low-level feature would be implemented 
(and finished) before 2010 if high-level features like VID take precedence 
? What would be the next priority, View's Desktop ? Looking at how 
R3 has evolved since the first alpha in june 2007, I see that only 
very few core vital features have been finished, like ports, and 
the rest of the time has been spent on less important things like 
unicode support (which is a *very* valuable addition, but not vital, 
because anyone can implement it at mezz level if required). Features 
that nobody, except Carl, can add to the language (because it's closed) 
like modules, threading, rebcode, user-types,... are still pending.

a stronger link betwin 

networking" and "visual" modules ??? hum that's like if Carl was 
preteneding we can't already do that !!??"


I haven't mentioned this, because I was afraid I would get it wrong 
and Carl would bash me for it. :-) What I'm writing here below is 
one of the reasons to switch to a webbrowser mentality. It was also 
one of the the reasons for dumping VID3.


Webbrowser mentality helps building infrastructure, very quickly. 
There is allegedly a stronger link now between VID and networking 
in the same way as there is a link between HTML and HTTP. When you 
create a link in a webpage, it takes only a few tags in one line 
of code (even inline) to do that. You don't do anything else but 
provide the link. The browser takes care of the rest, and you can 
build an entire infrastructure with hyperlinks. You don't have to 
worry about TCP ports or wait for acknowledge from the server. The 
basic philosophy that goes behind hyperlinking is its extreme simplicity, 
which is why it's so widespread. It's easy to grasp and easy to code.

When you for example write in a forum, you are often capable of providing 
hyperlinks. As a result, hyperlinking is available to any users, 
who have just the basic knowledge of coding, which to them is "typing 
funny chars to make a link".

Carl wants the same thing in VID3.4, where you must currently work 
with ports, store things in words and do something with the words 
in order to get where you need to go. You need to do some programming 
and make complex decisions. That level of detail must not go away 
of course, but there is a simplifying element that's missing, and 
that is to use buttons directly as hyperlinks. If successful, anyone 
could code simple VID GUIs.


I'm still sure I'm getting it a bit wrong, so there's not much point 
discussing it right now. He emphasized very strongly about building 
infrastructure through very simple methods that most people can understand 
and use. He talked about this more than about VID itself.

The rest of the world would believe it wasn't real if we claimed 
to find it.  ;-)

I was thinking that if I could do that, then reimplement the rest 
of REBOL in that dialect, I could write a REBOL compiler to JavaScript. 
At the very least I could write a JavaScript compiler to REBOL. Or 
for that matter, a compiler for a subset of REBOL to JavaScript. 
Semantic equivalency is what would matter here, not syntax. Syntax 
is irrelevant.

In the DocBase page for GUI_Panels, Carl wrote


A group has no backdrop or border and arranges horizontally by default.


I feel this is ambiguous; do groups have no backdrop or border ever 
or only by default?


I'd like to edit the wiki to make this more clear but I can't tell 
 from the rest of the page whether a panel can have backdrops and 
borders. Can anybody with access to R3 clarify this?

Part of the fun is when code patterns in the UI suggest possible 
improvements to the core REBOL semantics. Carl's GUI work is coming 
with lots of goodies for the rest of us, whether you are doing GUIs 
or not.

there has to be a few exemplars for the rest of us :)

custom widget? All apps I can see provide kind of split window ... 
even AltME :-) I think that solution might be to allow one of four 
sides of panel to be resizable in certain direction. The rest will 
be handled by resizing model ...

Please keep asking questions. As long as you are patient the questions 
can act like a Plato-style dialectic discussion, providing valuable 
information for the rest of the community. If you don't ask, we won't 
know what people want to know.

Graham, in case you missed it: The BBS gave a good range of bugs 
to fix. It was probably built in half a day. The rest of the time 
was (and still is) spent fixing bugs in the core and my skin. We 
are not "wasting time".

if a user will ever need to enter an IPV6 address directly, there 
should probably be support for that, but other than that, the rest 
is up to the OS.

Robert - discussion of you, networking gurus is needed. I don't know, 
where is the distinction of transport and service layer in LNS. If 
LNS is mostly services layer, which can be used over whatever transport, 
well then. But if not, why not to go with some multiplexing engine 
like Uniserve, which, via plug-ins, dynamically can "syndicate" (interconnect) 
us with the rest of the world - IRC, Jabber, ICQ, http, SOAP, webservices, 
whatever ...

It allows you to skip the rest of a while loop for example when the 
conditions are met.

A continue should skip the rest of a loop cycle and advance the loop 
to the next cycle based on the condition of the loop.  This means 
it is far more efficient than our current methods.

We are at a point in the development of R3 where we need the help 
of the rest of the REBOL community. This is why I think complaints 
from people impatient for R3's release are silly: Noone needs this 
release more that the people who are already working on R3. We will 
be releasing soon because we need to asap. The only delays to release 
now are practical ones, and not many, and we are focusing exclusively 
on fixing those problems right now (sorry Steeve, we'll get to the 
concerns you have been expressing recently, after release).

Most uses of hash! are replaced by map!, the rest by block!. The 
only use of list! that couldn't be done with block! was found to 
be so obscure that no code was found that used that technique.

If the block needs to be expanded because there isn't enough allocated 
the system does a block copy. If there *is* enough allocated, as 
when you preallocate using make block!, then the system doesn't have 
to do a block copy. That is R2 and R3.


What is new in R3 is that the "head" pointer of a block doesn't have 
to point to the beginning of  the allocated memory, just like the 
"tail" pointer in R2. This means a remove from the head of the block 
just shifts the pointer over one in R3, while in R2 you had to copy 
over the rest of the block contents to shift it towards the head 
of the allocated memory. Preallocated memory can also exist before 
the head of the block contents in R3. This means that there is no 
difference in overhead between inserts at the head or the tail of 
a block in R3.


In theory, inserts inside the block in the first half could be more 
efficient because you would only have to shift from the nearest end, 
not the tail. I don't know whether this optimization has been implemented.


Block operations in general could be faster because with no list! 
type we wouldn't have to special-case as much code, so we could make 
our code much faster through more aggressive optimization.


Btw, I submitted a tweak to DP to make it more accurate by subtracting 
its own overhead. It still has some variance though - have to tweak 
the native to fix that. Plus there is the extreme variance caused 
by Windows.

I was only disputing "huge", not the rest.

Petr, I have been proposing that new PICKZ and POKEZ functions be 
added to do a 0-based PICK/POKE, instead of having vector! be 0-based. 
This would give us 0-based referencing abilities for all series, 
not just vectors, then we could make vectors 1-based like the rest. 
There are real advantages to 0-based indexing so it would be good 
to have it, but consistency is better here.


Carl was not proposing to make a change to PICK and POKE in his blog: 
he already (half) made the change. He was asking us in his blog if 
he should change it  *back* to the old, buggy R2 behavior. I think 
he should finish fixing PICK, POKE and AT instead.


Henrik, INDEX? returns a 1-based index from the *head* of the series 
- that's why it's always positive.