World: r3wp

From the logs on curecode.org, both emails have been rejected by 
your email SMTP server. It seems like a SMTP issue (not sure yet 
from if it is from the server or client side). Anyway, I've validated 
your CC accounts, so you can log in.

Got one email now.. Thanks

Ah good, maybe it was just delayed by a SMTP greylisting protection.

Your SMTP server sends two 220 greetings lines instead of one which 
doesn't comply with RFC2821, so it is rejected by Cheyenne's MTA 
as an error. I'll improve the MTA to accept such protocol deviations.

what to do to be saved in logs/default-access.txt user-agent and 
referer ?

Thanks Doc for this debugging work.

You need to patch 'logging event in mod-static to save them. There's 
probably a standard format from Apache for that.

ok. thanks

You can also add a wish to CureCode for that feature if you want 
me to implement it. ;-)

has anyone used the localisation framework of cheyenne?

I digged into it a little and I don't know how to make it load other 
than default language en

<% 
locale/set-default-lang 'en
print say "test" 
probe locale

print "<hr/>"

locale/set-lang 'fr
print say "test" 
probe locale
%
this generates:

test make object! [ path: %www/cebelca.biz/lang/ lang: 'en current: 
make hash! ["lang" "test" ] default: make hash! ["lang" "test" ] 
......
<hr/>

test make object! [ path: %www/cebelca.biz/lang/ lang: 'en current: 
none default: make hash! ["lang" "test" ] ...
--

after I set lang to fr I have file in fr/fr.cat it says current: 
none (so it didn't load it)

if I reverse the fr and en in code in first case default and current 
are still en and in second they are both en.

It seems like it can't find fr/fr.cat in either of these cases

case = examples , the one up there and reverse

I suspect that directory lookup is different for default 'en and 
when you set-lang , set-default-lang

I found in source: ;--- Define the localization resources directory 
(relative to the webapp) .. now I moved the test to webapp, I had 
it on the frontend before but it behaves the same (I have binary 
release 0.9.19

I will try with the source version from SVN

same behaviour

file: join path [mold id slash mold id ".cat"]    ; current dir is 
in the webapp aleready so the path to file doesn't resolve
unless exists? file [return none]

I don't know what is the right solution in the global context, differentyl 
calculated path , different current dir .. so it's best you solve 
it :) .. I made a hack/fix so I can work on

great, it works.. also outside webapp

that static form for localised strings is a great idea #[...] 


does localisation effect performance much? I suppose it increases 
RAM usage since app holds the two hashtables in memory (which is 
needed I know for speed)

the #[..] is awesome idea. I have tons of javascript that would otherwise 
become an ugly mix of javascript and rebol

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'm not aware of issues wrt 'set-default-lang, but I must admit that 
I've never used it, I just switch the languages in my browser for 
testing.

Please add a ticket for that issue at http://curecode.org/si/view-tickets.rsp.

I agree that #[...] really makes things easier and cleaner. Performance 
impact is not significant, the overhead is just a string! PICK in 
a block with a static index as argument (that's one of the nice advantage 
of compiling RSP scripts). OTOH, the SAY function has to do a hash 
table lookup to get the right index (so a tiny little bit slower 
than the literal form).

Good. I have a lot of javascript so #[] really saved my day. I had 
started with >element.innerHTML = "<%= say "some text" %>" and element.innerHTML 
= "#[some text]" is 10x better :)

I will add a ticket, I need to use this function because I basically 
set language globaly for english / slovene version (not based on 
user preferences or anything, it's also different website).

Some texts (that are part of application) are a little longer. I 
was thinking of replacing all of them with "tags", like "add_now" 
instead of "Add now" and "warning_text" instead of "bla bla ........................" 
and having the default language as this tag language from which it 
is then translated to english, slovene, etc.. anyone has any thoughts 
about this?


I could also make a tool that would statically replace all the values 
in say "..." and #[...] if I decide to do so at one time. That's 
why I would preferr the same system for most of things.


I will probably have a separate files where the whole page is text 
, like the instructions.

Looks like a good idea to dig.

cheyenne does support mysql only? or can we use sqlite or sql server 
thru odbc?

you can use anything rebol can use. I am using sqlite also for example 
somewhere.

I have a webapp that uses captcha as part of the authentication. 
 But I need also to allow scripts in ... and so I had to disable 
the captcha.  Any other solutions?

I got the SVN version. How to proceed?

a) how can I get the SVN version to run on my server?
b) how can I create an encapped version of it?

do %cheyenne.r

there's an encap script that comes with the distro

Do I need to configure any paths to get it up & running without encapping?

AFAIR no unless you are using a webapp

is there any other configuration or something to use databases with 
cheyenne? I configured as it shown in web site but I always get the 
error:

##RSP Script Error: 
	URL  = /
	File = www/index.rsp
	** Access Error : Invalid port spec: odbc://test2
	** Where: do-sql 
	** Near:  [do-sql 'test2 "select * from table" 
__txt 62
] 

my rsp site is:
<%
	print do-sql 'test1 "select top 10 * from sec_log1"
%>

and the httpd.conf file:

databases [
	test1	mysql://[root-:-localhost]/test
	test2	odbc://test
]

typo, it should be: print do-sql 'test2 "select top 10 * from sec_log1"

In order to use the mysql protocol, you have to include it as a worker-lib, 
I guess.

Add %path/to/mysql-protocol.r to your WORKER-LIBS block in the %httpd.cfg, 
that should do the trick.

Endo, does opening the database directly from console work?
>> db: open odbc://test2


Also, check what REBOL kernel Cheyenne is running on, if you're using 
one of Cheyenne's binary releases, you won't have ODBC support (requires 
encapping with encmd).

I tried it with mysql also, but the result was same. So it is not 
an odbc issue I guess.

I'm using cheyenne-r40.exe on windows xp pro.

mysql.exe command-line works well.

I tried with cheyenne-r0919.exe binary version with mysql server 
on localhost, same error: 
** Access Error : Invalid port spec: mysql://[root-:-localhost]/test

cheyenne-r40.exe doesn't have ODBC driver.

Can you connect from REBOL console using : 
>> db: open mysql://[root-:-localhost]/test

??

db: open mysql://[root-:-localhost]/test gives same error on console, 
I'm using R2/View 2.7.7.3.1