AltME groups: search

You're right ... just tried it with some quoted text from a Pages 
document:

	ÒQuotes are the main culpritÓ

yeah even with it my eyes are on fire because it's too small ... 
and when my eyes hurts I'm not in a good mood for anything less reading 
tons of pages of those tiny fonts texts

Extensions for R3 : simple TTS, Matlab extension, Windows Api extension, 

pages updated with the new versions (binaries and sources) compatibles 
a110 :

http://www.colineau.fr/rebol/R3_extensions.html

Sorry. I was just adding the information from the last time the subject 
was discussed, and factors that weren't considered. No offence was 
intended. I'll stay out of this one if you prefer. The old pages 
are still there for reference.

Some new pages.

(btw, that's 15 pages of documentation, for the first release...)

Rebol plugin: 
you can visit: http://www.maxvessi.net/rebsite/plugin/index.html

to test if it works, tha pages contain some scripts. If you want, 
I can adder more...

Web-Site updated. See: http://saphirion.com/development/


- the rm-asset.com site is no longer valid, the company was terminated

- we use a web-font please let me know if you see any screwed up 
pages
- this R3-GUI release is a huge one, see history

Any comments and feedback welcome.

I think I'll leave it for this page for now. We can split it in multiple 
pages later. Our discussions seem to criss-cross between DRAW and 
View anyway.

Seems I continue to have the need for basic authentication to allow 
3rd party resources access pages.

I need to get my web sites up quickly for a few projects, so this 
is a priority thing... I expect to have the first few quality pages 
functioning within a week.


with a few REBOL projects (some still unheard of) to share with all 
of you guys on one of those sites.  :-)

I am thinking of building a session server for remark. an uber simple 
multi-tcp port server which implements liquid-net and synchronises 
the remark handlers, in a lazy way.  so unless the users are actually 
calling for pages.... no network traffic occurs between processes.

Has anyone made any tool yet that would process cheyennes logs and 
create some usage statistics? even if very simple ones (I removed 
statcounter because I have full https now, but now after I released 
it I would want to see more detailed and realtime stats (basically 
to just see who came in and visited what pages) than google analytics

The ws://localhost/ws.rsp URL is hardcoded in example pages. Just 
change the JS code to point to the adequate domain of your server 
to be reachable from the LAN.

http://web.syllable.org/pages/index.html#id-2010-01-02-22-16

Another handy html 5 api..  Web pages can determine if the client 
is online. (returns boolean)

var online = navigator.onLine;
alert(online);

huh, I have to comment something.. I went looking what curecode looks 
like .. and founc this one http://curecode.org/rebol3/view-tickets.rsp
.. when I am clicking links the page reloaded so quickly that I couldn't 
determine if you are doing an ayax call or the whole page is reloading 
and I can't see it.. I also noticed this on my cheyenne projects. 


I don't get how you managed to do this. There are numerous servers 
outthere and rebol is not the fastest language and I haven't seen 
something like that anywhere?!?!? I mean I think also the static 
pages that you load from some webserver take some more time.. ?

I don't recall anyone using the localization framework besides me 
and now you. :-) This framework is still experimental, it might be 
not suitable for a big application as it relies on a single namespace 
(using same words in differents pages will give you the same translation, 
this is not always desirable).

I use nginx as a frontend server and cheyenne as a backend where 
Cheyenne ca cretate static pages served by nginx... My motto for 
thic combo is: where west meets east as its American-Russian connection:)

I had a quick look at the first few pages and it seems to use framing, 
with only one frame type defined at present.

I use websockets for passing javascript and JSON to a static page. 
 The pages start off with a single javascript function, then i use 
websockets to lazy load.


Here's  pseudo for an email client using Cy (shorting Cheyenne to 
Cy from C.. keep confusing myself)


- Start with a blank page with the websocket function. No HTML, No 
css.. link to Jquery only  .. this page is under 1k

- Send an initial message to Cy with the page name, Cy responds by 
pushing the necessary HTML (simple email form), CSS and JS (a single 
function to send back the form results to Cy) to the DOM

- User fills out form, and submits.. pushing an array (JSON, string.. 
whatever) with the message details to Cy
- Cy sends the message via rebol mail

... but then 


.. Cy polls the users pop mail acount on a regular basis, and upon 
finding a new message, sends <i> sends a javascript function</i> 
to the page, that gets EVAL 'd . This could do some animation in 
a canvas tag, push some message to the browser's chrome.. whatever.
 

All using the same tiny webpage. When you look at the source, you 
see 20 lines of code.

but if you are only serving static pages, its not an issue.

is there any work about running encrypted rsp pages on cheyenne? 
just like zend encoder for php?

and I use it also on the R2 and R3 pages for GUI images, that I serve 
locally, as you have seen.

Have you got any examples for the pages on your sites?

I've looked at some php pages with js , sql etc and it just looks 
like a nightmare to maintain

As long as you have just simple pages, it's fine. You can use this 
with RSP easily as well.. but if you want to look at "hard to maintain" 
PHP code.. and have good nerves..just download Magento's sources 
and try to figure out what's going on.

so say your library updates . .you have to update all the pages that 
use the js libraries

Graham: so say your library updates . .you have to update all the 
pages that use the js libraries" . The answer is yes. The html file 
would generally behave as any other html file that is not backed 
up by any server side.

SVN r105

FEAT: debug mode can now be restricted to a given client IP address: 
debug/options [ip: 1.2.3.4]
FIX: debug menu now inserted only in pages with HTML content-type

FIX: (regression) debug menu and RSP errors now displayed even if 
response/buffer is empty

FIX: inlined colors for debug trace window (to avoid CSS overloading)

FIX: bad log filename generation when using a virtual host definition 
that includes a port-id
FIX: Cheyenne logo updated for default test pages

That sucks then ... RT's attitude is - do it yourself, as it is 12 
pages of C code, and we don't care about having R3 doing at least 
the same stuff as was possible with R2. I described the syndrome 
here:


http://rebol.net/wiki/What_makes_a_good_beta#Wrong_attitude_towards_finishind_R3.3F

RT's attitude is - do it yourself, as it is 12 pages of C code, and 
we don't care about having R3 doing at least the same stuff as was 
possible with R2. I described the syndrome here


From what Carl told me, producing that code took an enormous amount 
of resources of several of his best coders at the time it was made, 
because there is a lot of trickery involved. It took a lot of research 
and he is therefore probably not inclined to do it again that way 
for R3. Maybe a smarter method will come up, but would you rather 
have him dive into that for 3 months or finish R3?

RSP is a template system. Magic! generates pages from REBOL dialects

Graham, if you're concerned about performances and scalability, I 
don't understand why you're considering a CGI-based solution? AFAICT, 
Cheyenne/RSP is the most scalable solution for running REBOL code 
on server-side. If a single Cheyenne instance is not enough, you 
can use a nginx front-end to server static content and dispatch the 
load over several Cheyenne instances.


Our biggest online web-app has ~800 users, with several hundreds 
logging in each day, accessing a 400MB RDBMS with millions of records 
served by a single Cheyenne instance, with 8 workers (each taking 
15 to 25MB of RAM) running on a 2.2Ghz DualCore CPU with 2GB of RAM. 
Average Cheyenne load is 2 req/s with peaks up to 100 req/s (usually 
caused by web scanners or attacks). The webapp is still performing 
well under these conditions, and we have plenty of space to improve 
performances when it will be required (with faster hw and more instances).


Also, a key factor is optimizing webapp's code, especially for the 
most used RSP pages. Btw, a profiler would be a good addition to 
Cheyenne/RSP framework.

Or, you can include the r2/forward package in your RSP pages

It works fine for me
I have in my RSP pages

Print json-data

Longshot here .. but has anyone written a code formatter for RSP 
pages .. so that it correctly indents HTML, JS, and Rebol all on 
the same page??

Graham:  I am happy using Andrew's ML.r with Cheyenne to implement 
Don't Repeat Yourself on the few pages that I do. <%

 include %ml.inc  ; does [%pop.r %push.r %build-tag.r %ml.r] which 
 can be pre-loaded 
	print ml compose/deep [
		h1 "Heading"
		p {Text paragraph}
		p (now)
	]
%>

very nice download pages.  probably one of the most conscice page 
of this kind I've ever been to  :-)

It depends on the definition, but that's the direction I'm moving 
in. The structure is roughly MVC, and I have a method of updating 
web pages without the browser having to know what it means

I have mutiple users using a web app on different ports.  Each has 
their own vhost, and their own pages but to keep things simple, each 
web app is the same.  I include a config file each time a rsp page 
is loaded with the db definition instead of in the app-init.r where 
it did not work

'debug keyword is producing error pages.

any example how do u test pages behind a session?

im trying curl -D- -d 'login=test&pass=letmein' -c jar http://localhost:8080/app/login.rsp

but subsequent curl -D- -c jar http://localhost:8080/app/some.html 
still gives me 302 to login.rsp

any example how do u test pages behind a session?

 You shouldn't use AUTH keyword if you don't want the redirection 
 to a login page.

GrahamC: I think it should be explained in the new wiki pages.

onetom: sorry, I am not fluent in curl, I need to look for man pages 
for every options...Can't you use REBOL http client for testing?

A couple of pages I guess

Oldes: serving a non minified 300kb javascript framework doesnt sounds 
like a "stream server" scenario.

on the other hand, cheyenne is doing the streaming in 2kb chucks 
something, iirc.
it also does compression on rsp generated pages.
i don't really understand what is all this resistance...

I'm getting a *very* weird problem launching cheyenne from win7.


using a clean download of the latest build sources, if I try to start 
up the cheyenne.r by double-clicking on it in windows, it fails. 
 

no tray icon appears, the rebol process is running buts its dead 
(no pages are served, and no workers are launched).


if I try to run it a second time, I get the console which tells me 
it can't open the rconsole and logger ports (so cheyenne actually 
did start)., but the "no response" flag appears on the window title 
and its as dead as the first instance (I even get the busy mouse 
cursor treatment). 


but if I start it from the command-line, using the exact same command-line 
that I see in the task manager, I have no problem!


to make this even more strange, dragging the cheyenne.r script icon 
on the rebol.exe icon, launches cheyenne without any issues!

launching it from my editor's automated script launching setups also 
works without issues.

all of these show the exact same command-line in the task-manager 
(which includes the -qs rebol flags).

note, I am *not* running cheyenne as a service.

Questions:
1) can any one else replicate this (am I going mad ?  ;-)
2) why does this happen?
2) can this be solved?

I have tried to use the testapp on Dockimbels request, but it serves 
only non-functioning rsp pages on http://hmkdesign.dk.

Unfortunately that woud take a while to pick apart as I have other 
pages running on that server.

Cheyenne-server.org is taking a long while to serve the wiki pages.

You could create a hyperlink for each of your new functions to the 
manual pages :)

Might be useful if r2 docs could be given their own pages as well 
...

Do we need to do aliases, or generate from a common set of data? 
Perhaps common pages for common functions, since R2 people might 
be interested in R3 compatibility notes.

common pages .. split for r2 and r3 use?

A model with some shared data can be more memory-friendly on small 
devices too. While the native code can just use shared pages, the 
mezzanine code needs to be per-process. And from a memory standpoint, 
mezzanine code takes up a lot more room than native code. Shared-nothing 
would kill R3 on portable devices.

License note:


This software is licensed under the Spread Open Source License. This 
license is SIMILAR BUT NOT IDENTICAL to the BSD license. Specifically, 
the license includes the requirement that all advertising materials 
(including web pages) mentioning software that uses Spread display 
a specific acknowledgement.

Having had a look to the extension pages of the R3 documentation, 
I see that the use of make-ext.r to generate the init_block is no 
more relevant.

pages updated with the new versions (binaries and sources) compatibles 
a110 :
http://www.colineau.fr/rebol/R3_extensions.html

in any case I want to build a single script which does all the tests, 
statistics, and eventually graphics and html pages of all results 
in one (VERY) long process.

so I can better control how the tests are done and prevent automated 
test creation as I am doing now.

That's a big topic. One we should move elsewhere, because it's likely 
to be many pages long.

Geomol, the manual was converted from the Core 2.3 manual, and most 
of the pages still reflect that. For types where the semantics have 
changed, the manual pages usually aren't updated until the semantic 
changes are finalized. This is not the case with money! yet, so the 
page hasn't been updated.

HTML refers to this as "inline" (and the line may wrap).
I used 
grid-face/LAYOUT-DIRECTION: 1x1  and  
grid-face/MOVE-FIRST: 'horizontal
in my old GRID style.
	do http://anton.wildit.net.au/rebol/gui/demo-grid.r

But the parameters needs to be clarified some more.

Academic papers published as PDFs often have two columns of text.

That means a single line of text wraps horizontally, vertically, 
and horizontally again.

Eg. The line of text first wraps (horizontal) when the right hand 
edge of the first column is reached,

then, after many rows are similarly wrapped, when the bottom of the 
first column is reached (vertical wrap).

All of that occurs again for the second column (and perhaps more 
columns) until there is no more room on the page,
so the final level of wrapping is horizontal. 

So I would have 
	face/WRAP: [horiz vert horiz]

which specifies three levels of wrapping, horizontal for chars, vertical 
for lines of text, horizontal again for columns (so that the next 
page is underneath the first one).

To put pages horizontally, you would just have 
	face/WRAP: [horiz vert vert]


Or you could specify an extra level of wrapping, eg. so that you 
could have groups of two pages shown horizontally
	face/WRAP: [horiz vert vert horiz]


The direction for each level of layout should be specified to correspond, 
eg.
	face/LAYOUT-DIRECTION: [1 1 1 1]
which would give left-to-right and top-to-bottom.
(Use -1 for right-to-left  and bottom-to-top directions.)

Hey guys, don't be so picky ;) about the test text strings. I only 
cut'n'pasted random chars from some of these pages http://www.alanwood.net/unicode/#links
that's all.

I personally don't plan to spend time on all the 'unicode normalization' 
and other tricky stuff and details. It seems there is enough linguistic 
experts even for tibetan script! So I'll kindly left that part as 
an exercise to the comunity :-P

There is no charset selection. You just provide valid UTF-8 codes 
for the appropriate unicode chars, thats all. Also ofcourse you need 
to have font that contains that chars. I was using 'Arial Unicode 
MS' font in the test screens which is a huge font containing big 
chunk from all the unicode pages.

that is the resize bug mentioned a couple of pages back, also in 
the queue.

No, they aren't gone. If you rely on the implemented 'browser sizing' 
you'll see lot of problems. I don't talk about static pages.

I have not intention right now to burry deep into CSS, as I think 
I know enough to understand consequences. Your "you are wrong here" 
does not work for me :-) Wrong in what aspect? I still think, that 
I do understand how you style html pages :-)

From R3 chat it sounds like Graham can edit, but I wonder if he means 
the general pages or just the manual.

I think the point is that we should be able to edit those pages too, 
but it seems not to be the case right now.

Priorities page now shows all secondary pages processed.

right now flushing out (finishing) the extensions is actually the 
most enabling.  so: 


1.  Releasing the view host-kit with improved extensions would be 
the first step into finishing WHAT the first R3 beta will be, in 
terms of architecture. Right now, there are a lot of datatypes missing, 
and a proper REBOL callback mechanism *** with return value***  is 
probably the most frustrating issue with R3 extensibility.  image 
and vector types are critical to extensions... please they have to 
be part of next extensions.


2. Schemes!!!   with a lot of work ALREADY done,  plus willing and 
able helpers, Carl, you should REALLY look into this and orient the 
spontaneous team that is dying to get your attention so they can 
proceed FOR YOU.


3. Documentation ... I'd say.. .TWO complete and final pages a day... 
no need to do more.   At that rate, the documentation will be much 
more helpfull within weeks.  But sections of it will start to be 
worthy of being called documentation... right now... I'd call it 
the "sprawled notes" part of the site.

It's harder for me to get the proportion of Meijeru's tickets - I 
have to count tickets rather than pages.

I expect that it is just some adhoc function that Carl rigged up 
in order to be able to generate the examples on the error pages.

trick is to find a way to parse just a subset... you might want to 
chat with steeve and shadwolf, their rebol editor was pretty responsive 
even with big files, so I guess they have an optimisation that lets 
them just token what is visible, with some form of caching for before 
and after pages of data.

Each of those pages needs to point to a page on rebol.net's wiki 
so we can edit them

Each of those pages should have something like:

Lead: ..
Members:
Completion Status: ...
Discussions: altme web link
Repository: ..

or similar

The purpose of a summary page is to allow people to get a quick overview 
without having to go to the detail pages if they don't need to.

Yes, because they're different sites and different people.  We know 
Carl is the only one with access to rebol.com pages and history tells 
us he can't maintain them.

We know that Carl being the only one with access to rebol.com pages 
is considered by Carl to be a bug in the permissions system of the 
rebol.com site, and that he is working on it.

People with sufficient rank in DevBase are supposed to be able to 
edit some pages.

I should use this for my web pages ...

HTML of new R3 doc pages has similar problems on most pages due to 
no urlencode of ampersand in urls and invald <th> declarations using 
old <tr> attrib values for vertical-align in a <th> element.  I would 
gladly fix ad hoc and you can fix your page gen tools (?) later

I can confirm that I am able to edit pages in the rebol.com wiki.

I used to be able to edit the pages .. so looks like the limit was 
raised to above my rating.  Phew .. less work for me

And it was an objective, from way back when we did the first round 
of PARSE proposals. At the time I had been following the development 
of Perl 6, especially their rules enhancements. Some of the PARSE 
proposals were based on trying to catch up with or show up Perl 6, 
and others came from tricks that other parser generators like ANTLR 
could do (like IF). To be fair, it was an unstated objective, at 
least on the pages. Peta had different objectives of course, like 
better matching the PEG theoretical model, and those were also good.

I would suggest adding a charset in the header of source code pages, 
this one for example http://www.rebol.it/power-mezz/mezz/html-to-text.r
I get this line:

break-at: complement charset [#"0" - #"9" #"A" - #"Z" #"a" - #"z" 
{"'#$%&([^{@} #"" - #""]   <- last 2 chars are ?

There is a lot of pages about 'parse' on net... for example this 
one: http://www.rebol.com/docs/core23/rebolcore-15.html

Yeah, there's some tipping point in parsing web pages and such. When 
the pages are consistent and the data you want to scrape is simple, 
I use PARSE, too, or even just string processing

For you, but my business partner wants to scrape web pages, and I 
don't think he would understand how to do it with parse

Again... it's easier to do manual changes to parse malformed pages 
if you do string parsing where you don't care about 99% of the page 
content.

I've done quite a few html analysers and with a bit of experience 
I have found that going with a brute force parse on pages ends-up 
being very effective.  I did a font downloading script for www.acidfonts.com 
a few years ago and it took more time to actually download all the 
pages than build the script.  :-)

some servers are anti-indexing and its in these cases where the brute 
parse is most effective.  I've even had to cater an oracle web server 
which didn't have ANY css, type, or id fields in all pages which 
are driven by form.  all urls can only be read once, and every page 
read is a redirect.   


only parse allowed me to cope in such a drastic anti-robot  environment. 
 it still took a day to build the robot.  and in the end, it even 
had an auto-user-creationg step at each 200 pages which created a 
google gmail account for the next batch.  :-)

in those cases, parse is king.

This *had* to work with *any* HTML (think about the stuff that comes 
out of Outlook, or the stuff you get as spam, or newsletters, and 
all that). You can't imagine how bad that can be. That had to be 
turned into something that would not break our own HTML pages.

well yes there is... RUnit... but its very easy to make your own 
in two pages or rebol.

In most cases there will be one columns only texts and complete paragraph 
indentation is used very often. At least in web pages.

scanning: reading back a few pages...

I saw links to all past devcons on qtask today. too bad there are 
no videos available on pages any more. If someone has them and hosting 
is a problem I can putt them on some of my servers.

(Other parts of the /r3/ pages are, with the two-step login you describe.)