AltME groups: search

What I generaly do to get rid of viruses when AV fails is open Task 
Manager and just start googling for the process names.  If you can't 
find any information on the process then it is most likely something 
you don't want.  Dropping any Windows process into google will pull 
up a number of result pages that identify it as a windows process.

I agree with Allen.

I sent Carl a feedback last week to say such a form should be on 
the Altme mirror pages. So someone finding those pages is just a 
click away from requesting to join.

The Gripe:


Go here www.Rebol.org, then go here: http://www.ruby-lang.org/en/, 
then here: http://java.sun.com/, hell even go here, http://msdn.microsoft.com/vbasic/, 
now go back to www.Rebol.com


Even if you don't know what the language is or does, do you want 
to go to Rebol.org?  The main page looks like the last page in the 
basement of a website.  Almost like an "error page"

O There is no single location for all Rebol information.

O Rebol.net, Rebol.com, and Rebol.org are spread out and run by RT. 
O There is no pizzas!
O I don't "feel" community when I visit these sites.


I know I'm not talking to my audience when I say; "think of this 
like a night club" but this is what this is all about.  People want 
to "be where the fun is happening."  Even programmers.

My Suggestion:

O We need a site controlled by the developers.

O We need a forum where people can bitch and meet each other, and 
feel welcome.

O The site needs to have a consistent dynamic attractive template.

O The site needs to be a clearing house for all other sites.  Teach 
and directing people to all the resources.

O The site needs to paint a picture as opposed to describe everything 
with a thousand words.

What is entailed:


O Start a new site, I would propose "RebolCentral.com"  I'm willing 
to pay for it, but I don't want to be in charge of it, I suggest 
we make it a committee.


O The main page should cover every topic and reason anyone would 
come to the site.  This means we support every country and other 
site.  The idea here is a clearing house of centralized information. 


O News: The site needs to gather news worthy information and post 
that at the top.  The site is not alive unless people have a way 
to post their information.  This means that there needs to be at 
least one editor, if not several that share the task.  Every time 
a product is updated, the new features are mentioned.  When Carl 
updates his blog, it gets a single sentence directing people there, 
unless it is news of a release of something.  Etc.


O Product Reviews:   This is key.  Products need to be rated, reviewed, 
categorized, voted on.

O Video Archive: All the videos of all the talks ever given   


O Tutorials:  there are a lot of tutorials out there, but which are 
best?  We need to review the tutorials, rate them by Beginner, Intermediate, 
Advanced.  


O Forum: Start with major topics, and then break it down.  The forum 
needs to direct people to other countries, or support the other countries 
right in the forum.  Great simple forum: http://discussion.treocentral.com/index.php?styleid=1


O Respect the real estate.  The #1 mistake people make is treating 
their websites like just pages.  This is just like real estate, location 
location location.  We need to place the content based on where people 
are going.  So you build the basic site, watch it for a couple of 
weeks, then shift things around based on where people are actually 
going. 


O More art, more photos, more community.   It needs to feel inviting: 
http://msdn.microsoft.com/events/pdc/

Stone soup:


I will pay for, host, and supply a fast linux system (w/archive). 
 

I will help design the templates, and provide (and buy if needed) 
great art for the site.

I will not run the site, nor control the content, but I expect there 
to be in place all the items outlined above, set up in a manner that 
it a) runs itself, b) puts the power in the hands of the developers.

And the others get contact with rebol, because they can add guestbooks 
etc on their pages.

As far as I can tell, the main constraint on developing Rebol.org 
is the lack of people prepared to get involved and give their time. 
From my knowledge, Sunanda has single-handely maintained and developed 
Rebol.org for the last two years. (All in his spare time as he does 
it on a voluntary basis). (I'm definitely more of a hindrance than 
a help:-)).


Reichart is right, Rebol.org looks drab when compared with something 
like Ruby Garden FAQs. It doesn't appear friendly. Rebol.org lacks 
features though many that it has aren't used much(member home pages, 
forums for individual scripts, articles).


If I remember correctly, Sunanda has asked on a number of occasions 
for suggestions and help with the design/layout of the website. He's 
put in place most of the suggestions received which has resulted 
in some improvement in the look over the last couple of years.


What Rebol.org probably lacks is the clear focus and direction that 
creates a sense of purpose which will encourage people to volunteer. 
The may be a great part to the "paternal" relationship with RT which 
not only "fathered" the library system but continues to finance the 
server.


A successful RebolCentral would probably give Rebol.org a renewed 
focus and probably won't divert any resources away from it.

how many 1000s of pages is that?

For anyone that needs a backlink to their REBOL related pages of 
their website, I offer a REBOL links thread here http://www.tretbase.com/forum/viewtopic.php?f=8&t=33

Good idea Paul.....

Another opportunity to present yourself to the world in a REBOL context 
is the members' pages at REBOL.org. Also highly friendly to Google 
and other search engines (No 1 in in Google for [I've tinkered with 
a lot of different languages] :-)
http://www.rebol.org/lmp-index.r

Sure he is free to publish anywhere he likes, but it is the first 
place to look at, for me and most of the people (beginners especially).

I have tons of dead links to REBOL pages & scripts moved somewhere 
else. And also it is more difficult to have new versions of those 
script not on rebol.org

For example BrianH's csv-tools.r is a great script, useful for most 
people. But I'm sure if it wasn't on the rebol.org many people would 
try to re-invent the wheel. Anyway, just an idea.

So we speak about different names/pages.

But, I see dropped packets even in web browsers these days... often 
leading to some strange looking pages (because for example, the CSS 
never loaded.)

One of the problems is that the format of web pages changes often. 
Web developers don't hand out any guarantee that the format of their 
data in a html page is going to be in the same place all the time. 
eg. I can' t always go to the second table inside the fourth row 
of the third outermost table to get my data, because after all that 
navigation, they might just rearrange the data into the third table 
of the second row of the second outermost table. Arg!

So, I would want some way to redefine temporarily the {  or } pair. 
 Eg use a pipe character instead .. hardly ever see those used in 
 web pages

BTW, I noticed that rebol.org serves pages in utf-8 encoding, but 
the scripts themselves are latin-1. This is not a problem for the 
code, but it is a problem for the comments, which may contain accented 
characters. For example, names of authors (hint: Robert Müench), 
and they consequently appear garbled. I'm not saying pages should 
be served as latin-1, on the contrary, I am an utf-8 enthusiast, 
I think rebol scripts themselves should be encoded as utf-8, (it 
is possible with python, for example). I hope Rebol3 will be an all 
encompassing utf-8 system (am I dreaming?).

here is a basic... http://box.lebeda.ws/~hmm/rebol/pgsql-db.rthis 
reads the postrge's file per pages... but I'm not sure what to do 
with the data inside and have to do something else now

Extract is in 2.7.5 also which is the one I was using.  Maybe that 
is why we are on different pages on that issue.

Then it did switch/default nextstep [ (various cases, pages long) 
] [ the default case ]

If you know the cookie, you can set it inside the cookies block, 
where are stored all cokies used for automated (transparent) sending. 
But I never used it. My clasic scenario is to simulate an user with 
the web browser. That means read page with login form, submit the 
form and do whatever like normal logged user. With some pages I can 
skip the first step, but there are pages which are giving you unike 
session ids in this step and don't let you login without this first 
step.

so it should be possible to create a local editor to edit mediawiki 
pages, or to upload series of pages generated locally.

Fixed length. Databases usually work in increments of disk pages 
because it is faster.

Varchars are slower in practice. You can minimize the overhead of 
disk page access by packing pages if you have to. The OS reads in 
pages anyways.

Pekr, Bacon has been doing good work, and the wiki is getting prettier 
:)  But there have been a few factual errors on those pages...

As for the Parse Proposals wiki, I'm afraid it will need some cleaning 
down. I kept trying to tell Peta the rules Carl set up, but Peta 
kept ignoring them and going into great detail about parse theory 
and such. Half of the contents of that page are going to have to 
be moved to other pages, and I'm probably going to have to summarize 
the best of the proposals to Carl if we want to convince him to implement 
them.

yes. The same went for my news-scroller. I just tried to outline 
it in REBOL, thinking someone should do it in some PITL environment. 
Then I saw my brother using it in PC Shop on his LCD TV. I asked 
him - hey, wait till someone makes final version, and he replied 
- it works, no? And then I thought to myself - can I regard 2 pages 
of code being actually an application? :-)

with-pop-do 'box get-pop-addr [
    pages: "something"
]

and define a variable/word "pages" in the block like I did .. this 
word changes the global binding probably? which is not very good 
because it might owerride some other binding ... am I correct and 
is there some elegant way to not introduce such negatiev side of 
this otherwise elegant pattern?

Something like this?

use [pages] [
	with-pop-do 'box get-pop-addr [
		pages: "something"
	]
]

I am changing to using a context now for all words that are defined 
outside functions on rps pages to make them local to that pageload

btw, I have successfull had Carl add a nav bar at the bottom of the 
quickstart tutorial...  he will propagate it to the other pages as 
well...

Thanks for your input guys. I am not constrained that much. Our kiosk 
PCs do have 256MB of memory, being older PCs, some Duron 1.2 or so, 
WinXP. It runs presentation in full mode, local Apache based. Plenty 
of photos, simply kiosk presenation, not ordinary web pages. Dunno 
how IE is memory hungry. My script, which will run in background, 
easily eats some 39MB memory. I did some unsets, recycles, so while 
in wait mode, script goes down to some 24MB. It is that I was just 
curious how to aproach that ...

Pekr,  I need the other VID guide for the REBOL2 DocBase pages but 
the only one I have found is a VIEW guide http://www.rebol.com/docs/view-system.html.
Are you sure another and updated VID guide exists ?

Well, many web pages actually do an ok job of it.

Re browser inside  I'd like to see that;  I've been playing with 
w3m -dump to get formatted text out of pages into a View app.

Brian;  Some work has been done on BiDi


And this post got pushed up from Core yesterday.     REBOL is an 
awesome Webhosting language today.


Brian; Look to Cheyenne...  It's a showcase REBOL product.  Using 
its embed technology, in theory, a website with server can be a single 
REBOL script.  It's a Go Doc Go! example of where skilled REBOL really 
shines. 

http://softinnov.org/cheyenne.shtmlbut look to the !Cheyenne group 
here for  updates http://softinnov.org/tmp/cheyenne-r0918.zip


Just so ya know, I'm a real Go Doc Go! fan of Cheyenne.  Running 
on GNU/Linux ... webhosting from anywhere ... just nice.   Go Doc 
Go!   :)

One aspect of the new "reality" is that your computer always has 
a web browser running, it has to.  So any comparison of REBOL and 
a web browser you have to do is to run REBOL * in addition to* the 
browser.  Not fair, just true.  Performance-wise, how quickly the 
app starts up or not doesn't matter anymore... you've paid the startup 
cost for Firefox (or whatever), you've got the code pages in, they're 
there you have to live with it.

If you view the browser as OS, then you also have to take the bad 
with the good. Both FF and IE shut down a lot more than my OS, bad 
pages cause problems, PDFs opening can hang things, memory consumption 
makes me restrt them, etc.

that means if you have 4 pages, you create 4 separate layouts and 
call to-postscript 4 times.

...to to-postscript to generate multiple pages in one go.

one postscript file but multiple pages

My method is because I have a single document that goes over many 
pages

we don't have finer type setting features, but I can live with that, 
as long as I have a simple and quick way to build postscript pages.

but because of the async calls, the Rebol micro-webserver can't serve 
the pages correctly.

thanks for the links.  I do have that list-view, I was trying to 
find a smaller way out.  It was missing one or two features I was 
wanting last I checked, and didn't feel like pouring over the source 
code.  about 100 pages.  My brain would take quite a few months to 
understand it.   Excellent software though.  I'll give it some more 
thought, and thanks again for the vid-notes link.  It looks very 
clean.

The quines in the library are string-based. That is not how the scripts 
in Rebol should look, as the documentation suggests. There were other 
sources of REBOL quines, I remember putting a couple of quines somewhere 
too, but it seems, that the corresponding pages have been either 
taken down or "cleaned" by some zealot.

and rebol, as a language is extremely easy to search on the net... 
you start any search on google with the word REBOL  and you'll end 
up with mailing list chats, altme pages, scripts on rebol.org, etc.

http://www.rebol.net/wiki/Table_Of_Contents
http://www.rebol.net/wiki/Parse_Project

Someone was reorganizing the wiki recently with no understanding 
of the REBOL language, so a lot of pages were lost in the shuffle. 
I don't know where things are now. The price of being open, I guess. 
The new PARSE documentation hasn't yet been converted from an improvement 
project to documentation. Have at it :)

Reichart, we have already answered the question of openness by providing 
both: One wiki that is open, for community management, and one wiki 
that is "official", for accuracy. You have to demonstrate a certain 
level of cluefulness to make changes to the official manual. We could 
modify the official wiki so that it links to the community wiki for 
comments, but history has proven that an open wiki can't be counted 
on to have a consistent structure, so we can't count on the pages 
we're linking to to be there. We may do that anyways, since it's 
a good idea (from you).

Petr, if someone ruined the wiki, why aren't the pages being rolled 
back?

Reichart's idea of each function having a page is a good start.  
But I also think there should be pages for cross-cutting topics that 
are linked to liberally when an issue of one of those functions touches 
upon it.

I am new to Rebol and have been a lurker for a little while. I used 
R2 to do some work with HTML pages and was sold on its power and 
simple syntax.

Hmm.. Couple questions.. 


A) Where/how/who to report a error (typo) on web page?  I know that 
rebol3 errors goes to curecode, but what about pages of R3? (page 
in question) http://www.rebol.com/r3/alpha-intro.html


B) Where I can find latest info on some particular part of Rebol 
3 project.. Like for example current status of  Unicode support? 
I found one web page, that has been 'in progress' for nearly 2 years 
so I don't think it's up to date. http://www.rebol.net/wiki/Unicode

A) Those pages are wikified. I guess it's a matter of getting access 
to edit them.

I'm just curious Jack, did you project REALLY need a database at 
all?

I find that "most" places where people use a database, a few pages 
of code that can insert and delete stuff from a simple text list 
would work just fine (AltME does this for example, there is no database 
behind this).

@Geomol  I now understand the syntax of function arguments, function 
refinements and THEIR arguments. Endo summarized it well. However, 
I still think that the REBOL Help sub-system should reflect EXACTLY 
how the function should be written. Thta should be the programmer's 
first line of help. Like the Unix man pages. So, assuming that the 
* char indicates optional syntax, IMHO, ?copy should say:
USAGE: 
    COPY */part, /deep* VALUE */deep range* 


To me, that tells me exactly the order in which the optional refinements, 
the required function argument, and the optional refinement argument 
should be written. To me this makes more sense. :D

Is it possible to open a web page and fill in username, password 
and press send? It is a POST form. I'm thinking of using it to check 
if some (of my own) web pages work and it is possible to login. I've 
tried read URL.

aha, I remeber I learned a lot from that green page too.. thanks 
for links so far , I will read the pages and hopefully I will find 
something related to the problems I have

kib... because in concrete I think I need *complex rules* not just 
1 string for it to work .. it has to work on all sorts of pages written 
by anyone.. you will see once I show you real example .. right now

I can't just use {<meta name="keywords content="} as rule because 
that would work just on some pages that use exactly one space and 
"

You are right.. but if you use it with browser, it works.. web is 
full of not validate pages:).. But I agree, that it was not good 
example.

parse is a part of rebol which needs a complete book to be written 
about it.   To go from zero to hero it could easily span 100 or more 
pages.

I looked for a previous report on this bug but couldn't find it .. 
4 pages of bugs with parse in them.  I wonder if they can be filtered 
to only show active bugs

I just tried logging in as robert from XP using FF, works without 
a problem (Opera didn't seem to work correctly). Make sure that after 
clicking the "Login" link and entering your username and password 
that the red "Login" link changes to black text reading "logged in 
as robert". All Wiki pages are then editable.

I have the Ashton Tate Advanced Programmer's guide which describes 
it, but I'll have to find a scanner and scan the pages in.

It's just an HTML alternative ( HTML+CSS+JavaScript )

I was once an OS.2 Zealot and a Prolog Zealot.  I love Rebol, but 
it will not make me either a Rebol bigot or a Rebol zealot.  Even 
a good advocate should not come across as either ...  Curl is not 
server-side; it is just client-side.  If what you have is a 'layout', 
why transform to HTML just to get a page into a browser while waiting 
(6+ mo)  for a Rebol plug-in ?  Curl is a web content language.  
It's good for that.  And it has great sliding panes and all just 
like scriptaculous but a s simple and consistent as good Rebol code. 
 Think of it as Scheme/Dylan for web pages instesad of HTML.

His company pages are still up http://www.whywire.net/contactUs.html

it's to be like the search fields you see on web pages .. click on 
it .. and the existing text disappears allowing you to enter your 
search term.

Sometimes a killer app is an app like any other, just taking up 1/10th 
of the space, has much fewer bugs and was designed and programmed 
much quicker than competing apps by fewer developers. Such apps have 
a better chance to grow into something big, because REBOL offers 
real leverage in programming and deployment. It can make you deliver 
and you can even do it cheaper. A lot of the Java folks, I talk to, 
often have these problems. It just takes too long to do something 
simple and it costs money.

I think this is why many projects run up in millions of dollars, 
are buggy and delayed. Leverage is wildly important if you want to 
deliver.


I haven't worked with AJAX, but I've coded up javascript RPC systems 
and have been working on building web pages that feel more like apps 
than web pages. It's a nightmare, because a web browser isn't really 
built for apps. It's built for document viewing and browsing, and 
by adding a ton of APIs and technologies, it's now possible to build 
something that can perform slightly like a real application, but 
is much slower and much harder to develop. I'm done with that. It 
gives me absolutely no leverage.

Andreas helped me today to debug the vanilla issue that was causing 
a server error for most pages ...

yeah, All of Brett's pages are awesome.

I use officelive which is awesome. http://home.officelive.com/Settings/Pages/Home.aspx

The biggest issue with Facebook is, that you don't have to visit 
the FB page, but you are still visible as more and more pages add 
the small facebook webparts like the "I like" buttons etc.  So FB 
can see what pages do you visit, what articles in newspapers do you 
read and other, for most people invisible informations. You don't 
even don't need FB accout. The only way how to avoid it is to block 
the FB's javascripts.

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.

Depixelizing Pixel Art: Upscaling Retro 8-bit Games http://www.extremetech.com/article2/0,2845,2385811,00.asp

(unfortunately, original pages and also mirros seems to be down at 
this moment)

I agree, Pekr. I use Wikipedia a lot the same way. To get a quick 
overview, and as Reichart say, to be able to begin to ask the right 
questions.


I also often use the external links and references at the bottom 
of most pages.

I really don't undersant why there is so many people crying... I 
have Uniserve runing for several months without problems, parsing 
about 50 pages two times per day to provide culture informations 
in the city I live, I use Rebol to build PHP sites, Flash apps, as 
a proxy server as, a clasic system console and for so many every 
day scripting and I really cannot imagine I would use something else 
than Rebol for such a job. And if you still think that you cannot 
do anything in R2 and have to wait for R3 to start, you can take 
a look for other technology. With computer languages it's same like 
with normal languages - the more languages you know, the better you 
are.

The browser as the launch platform for applications has always been 
an interesting idea. The fundamental problem of the sheer complexity 
of it can be solved with R3. If done right, it can completely wipe 
the floor with browsers and AJAX. I think the problem is that we 
haven't been speaking in a language that people can understand, such 
as "browser", "web2.0" and "webserver", but instead "dialects", "VID", 
"Viewtop" and "X Internet" and people go "huh?".

Some things I believe are needed to do this right:


- Browser form factor. People are used to browsers, not Viewtops. 
What's always the first thing a complete newbie computer user uses, 
when wanting to do anything on the internet? A webbrowser. I don't 
want a desktop inside my desktop. There are tens of solutions for 
such things and they are almost all forgotten. Carl is doing the 
REBOL browser. When you fire up R3, you will get what looks like 
a webbrowser and acts like one. The concept has to work equally well 
for people like us, as well as 5-year-olds and 95-year-olds.


- Do apps that are similar to webapps, like GMail. That's a quick 
way to compare. Don't you think a 50k GMail look-a-like inside a 
REBOL browser running at native speeds would be _slightly_ impressive? 
Remember to say that you can serve 5 times more users with the same 
bandwidth. REBOL can help make raw numbers look better without much 
effort. Google would have to use it as a content platform. They have 
no other choice. :-) Chrome? What's that?


- Plugins suddenly are very flexible. You don't have plugins as in 
Firefox, but helper scripts that can enhance/change your browsing 
experience. 15k full screen document reader that prettifies plain 
text files? Sure thing. Blog posts presented in that would be much 
nicer to read. Out goes the PDF reader.


- Do apps that are completely out of the league of AJAX, such as 
multithreaded P2P systems. In fact, why not build P2P capabilities 
right in? Have different instances of the browser allow users to 
connect and chat, when they are visiting the same "Rebsite". It's 
sort of like going into a physical store and chatting with the other 
customers and you decide to exchange business cards. Initial contact 
without needing email. Do the same thing with chat support for an 
article that you bought at that  "rebsite". Current websites are 
almost completely anonymous. You don't feel you are entering a live 
community. Coded in REBOL/Services.


- Webpages are now REBOL scripts. In R3, scripts can be closed and 
encrypted, so you can't read the source and you can sell scripts 
and have them signed. The best you can do right now is some kind 
of code obfuscation.

- Windows, MacOSX and Linux version.


- "A webbrowser that directly supports OpenGL without obscure/limited 
3rd party plugins." Say that again in your head.


- It's very important that the public get to see that creating REBOL 
scripts for the browser is very similar to creating plain HTML pages. 
REBOL scripts can be served off a plain webserver. All the infrastructure 
is already there. Or how about serving scripts from the browser itself? 
AltME can both be a client and a server. It's that P2P thing again.

- Browser would run wherever R3 runs.


- Market it as Web 4.0. Market it as a direct competition to current 
webbrowsing.


- Browser would be a 500-600 kb downloadable exe that starts immediately 
without installation. From deciding to get it, to be using it to 
browse "Rebpages", it should not take more than 30-45 seconds.

- We need AltME in that browser (Altissimo?) as well as QTask.

For developers:


- It's easy to create an HTML file in notepad and display it in your 
favourite browser. It's going to be equally easy to create a REBOL 
script in notepad and see it running in your REBOL browser. A 5-year-old 
who has just learned to type, should be able to create a script and 
display it.

- One language for everything.


- Everything is free. You can start out with notepad. The barrier 
for creating content is about as low as it can get.


- You wanna code slow web 2.0 apps or fast web 4.0 apps? Hard choice, 
I know.

Henrik: "When you fire up R3, you will get what looks like a webbrowser 
and acts like one." - not just that, I want R3 not just to look like 
a webbrowser and act like a webbroser but actually TO BE a webbrowser 
- download R3 (few hunderts kB), run it and be able to browse REBOL 
pages - and if you enter *.html - just show some window that says 
"downloading" and download some REBOL plugin that can display webpages 
(being based on Gecko, Webkit, whatever) - it will be few megs download, 
but people are used to it. This is definitely possible - it's possible 
to display OpenGL etc in View window so I believe there are some 
libraries to do this ("somebody" just needs to make an interface 
to them ;)'


The thing is that R3 browser (and just a R3 browser) will be once 
again a great platform without apps (Be Inc etc...). If R3 browser 
can display classic HTML+JS+CSS+DOM+XML+AJAX+WHATEVER combo it's 
win-win situation. Lots of apps available and we can improve them 
one after one to show it can be done much easier and faster.

They would switch for the added benifits rebol pages would provide 
but they would still be able to accesshtml until those sites cought 
up to speed...

There are finally a couple of signs of life with R3 GUI; 2 new pages 
in DocBase.

Pekr, I don't know what it will look like, when handling thick-skins. 
I would personally like to see some that are downloadable from RT 
(official skins) and then provide simple tools for letting you create 
skins to inspire people to create their own. This will be important 
for pages, where people want to get their own look.

One of the saddest tricks nowadays is to divide a small 2-300 word 
article on a news site into several pages, so they get more ad-visits.

Pound is similar over many code pages: more diverse -- ½ -- Mac: 
omega; Win/west: 1/2; Win/east: right-smart quote.

REBOL.org shows a ? because if blindly emits all Alte pages as charset=utf-8.

If (this works in Firefox....You change your default for the page 
-- view/character encoding / western iso-8859-1) then:
-- Peter's post shows a GBP [for his char 163]
-- Chris' post shows a 1/2 [for his char 189]

http://development.syllable.org/pages/index.html

The only way I can think of to keep the memory contiguous is advanced 
use of the hardware MMU, which would lead to partially used memory 
pages at the start and end of each block

The panel system let's you swap in different pages if you have more 
complex apps - see the demo code.

this would be really cool  just like searching the man pages in unix... 
the easiest way to find a shell command when you can't remember it. 
 :-)

WTF .... while sitting in a pub, having my 3rd good Czech beer, I 
plugged my USB pen in, started R3 and run Demo. I looked at what 
it does so many times, but never looked at the source. While VID 
3.4 contains only basic styles, when looking at various panels, I 
always thought - the code for this screen has to be some 5 pages 
long. WTFonce again - 10 - 15 lines of code with such a functionality? 
Awesome .... I think I will become even more REBOL fanatic ;-) ... 
Cheers :-)

I'm updating DocBase GUI docs.


1. Changing the links at the bottom of each of the pages to point 
to a single template so that they are automically updated across 
all pages by changing one document.
2. Adding [[Category:GUI]] to each of them.

3. If I have time I'll start working on a VID2 to 3 document that 
describes what changed.  Things like face/parent-face is now parent-face? 
face.

AFAIK unicode -> ascii is possible in R3 but don't know how... not 
having done it myself.  IIRC its on the R3 wiki or docs pages somehow.... 
googling it should give you some clues.

I think it would be hard to find it on Google between all the cca 
62000000 other "zen" pages

There is also more than 10000000 "Zen language" pages

Some technical issues in getting it to work; and the apparent lack 
of willing in Rt to fix these problems....There are under six pages 
of tutorial, so it is easy to get to.

there are a few of those on the list of function pages to remove

Cool. Tell Carl though - he's the one who knows how to remove pages 
in that wiki.

There is probably still going to be a lot of bugs and missing refinements. 
I noticed that some functions aren't written properly in the summary, 
and of course there are obsolete and missing pages.

PeterWood, I just checked the history on those pages and they haven't 
been modified since the initial import from the Core 2.3 manual. 
Thanks for flagging these for revision - I'll see about marking them 
as such.

I use apache2-MPM as a reverse proxy in front of Cheyenne for the 
same reasons (static serving, ssl), works flawlessly, but now is 
time to move to nginx. Looking at MacPorts variants for nginx, there 
are many options that I see interestings:
root/trunk/build alpha% port variants nginx
nginx has the variants:
	dav: Add WebDAV support to server
	flv: Add FLV (Flash Video) streaming support to server
	mail: Add IMAP4/POP3 mail proxy support

 ssl: Add SSL (HTTPS) support to the server, and also to the mail 
 proxy if that is enabled
	status: Add /nginx_status support to the server

 perl5: Add perl support to the server directly within nginx and call 
 perl via SSI
	realip: Using nginx as a backend
	addition: Append text to pages
	substitution: Replace text in pages

 gzip_static: Avoids compressing the same file each time it is requested

 google_perftools: Enable Google Performance Tools profiling for workers

 upload: Enable Valery Kholodkov's upload module (http://grid.net.ru/nginx/upload.en.html)
	universal: Build for multiple architectures

I guess what I really want is the feature of virtual-root for a webapp, 
but just for plain RSP pages.

Henrik, trying to answer your questions/issues :


to serve multiple document roots on the same site without having 
separate domain names

 => Use sub-domains for such isolation. Everything that's under one 
 domain can be accessed with /.. parent syntax. I think that you can 
 hack it around with ALIAS, custom webapps on-page-start event  handler, 
 but there aren't clean solutions. Use sub-domains for such isolation.

I think webapps require a bit more than static pages?

 => Just to make it clear, webapps are REBOL applications interfaced 
 with external world using RSP scripts. Webapp are not meant to be 
 container for *only* static pages (HTML/CSS/JS/images).


attempt [load join request/config/root-dir %/app-init.r] ; TBD: report 
errors !!! [...] 
RSP: error in events from %app-init.r now logged. 
That's from the change log. That's not correct.

 => Yes it is. What's being logged so far is the errors caught at 
 runtime in event functions declared in app-init. What need to be 
 logged is the LOAD %app-init.r process (syntax errors at boot time).


after a lot of experimentation, the latest encapped version was the 
only one that worked properly.

 Both encap and sources versions works well on Win/Mac/Unix. The issues 
 you have are related to running a rebol app as daemon in console 
 mode on a remote Unix server (without a UI desktop). Cheyenne can 
 work in source mode on such server, but it's much easier and pratical 
 to use it in binary form in such case (typical remote linux server 
 case).

so, now app-init.r works for whatever reason. at least I can observe 
that changes to app-init.r only take into effect after restarting 
Cheyenne.

 => Webapp are persistent application in memory. RSP pages will be 
 reloaded on modification but %app-init.r can't without "restarting" 
 the whole application. As there's no clean/reliable way to completly 
 "unload" a Rebol app from a Rebol session, it requires to restart 
 the whole processes (all the worker background processes that may 
 have run your webapp). This can be achieved either by restarting 
 the whole server, or better, by using the "Restart Workers" feature 
 (documented in the changelog file). For unix: kill -USR1 <pid> (where 
 <pid> is Cheyenne main process id).