AltME groups: search

this would simplify my life a lot.  I will have 4 servers to keep 
in sync and their setup will be mostly the same but their environments 
will be different.


A lot of the information is spread out in differrent tools and things... 
it would be nice if they could all share (loading) a single file 
when they start and I know I have just one "site" administration 
file to edit to contextualize all the configs of all my rebol-based 
tools.

Petr: I need the access to work when connecting to a Windows domain 
or using a resource from a Windows domain.   I don't know if NTLM 
covers this adequately when wikipedia's article says "Starting with 
Windows Vista, and also with Windows Server 2008, both LM and NTLM 
are deprecated by default."  IIS allows directories to be defined 
to use Integrated Windows Authentication (I misteakenly referred 
to it as Windows Integrated Auth earlier).

LN and NTLM are deprecated in favor of NTLM2 ....

if you create an application (this requires some knowledge on how 
to do that) you shouldn't need to do that other than during the startup 
sequence, and then close the connection again during close of the 
application.

In addition to Henrik's answers, database access can be used in two 
ways, either "manually", opening and closing connection yourself 
from a CGI or RSP script (READ mysql:// prefered in that case), or 
by relying on the RSP webapp API to manage persistent connections 
(see DO-SQL function in RSP API doc).


In both cases, you need to load mysql-protocol.r. The best place 
for that is in the config file in GLOBALS section, just add :

worker-libs [
    %<path-to-mysql-file>/mysql-protocol.r
]


Usually, I define a %libs/ sub-folder in Cheyenne's folder and store 
there all the libraries used by all my RSP or CGI scripts.

Max: there's no built-in support for that currently. Correct me if 
I'm wrong, but what you ask for is a preprocessor for the config 
file, no? I guess you could define a unique template config file 
where you could use, for example, issue! values to spot all the parameters. 
Something like: root-dir #root-path-var#.


You could then manage that template from your main location/tool, 
preprocess it and then emit a working file for a given server instance 
when needed.

Thanks Doc, that's what I was looking for and that's what I suspected. 
Has SQlite.r been tested at all?

Hey doc, how can we handle loops in within do-task/on-done ?
Anything i try seems to block and cause port issues.

I haven't yet looked at websocket stuff in cheyenne so I have no 
idea .. in general in async server also all your communications to 
other services if needed is async, that means you are using callbacks 
and similar methods, you don't wait 1 but probably some timer that 
will invoke you after 1 second

doc, not really.  Thing is I have different computers with different 
OS / HW / Install environments.

but the systmems they are running are the same but under different 
paths or using different ports, domains, and stuff like that.  


since all of this is done via shell, its very tedious to xfer,  manage 
& edit the data properly for a few apps.  I can easily have a single 
configuration file which just stores values, but let all the apps 
use those values in the same setups.

maybe we could add support for the get-word datatype (:word) in the 
config dialect ?  the values of those words would be substituted 
when they are encountered.  this way I could just add a keyword (or 
load it directly in the cheyenne script) which loads external data 
files and use the values in the config files.

Would you put a timer in the do-task/on-done func?


Not sure what you want to achieve precisely there. In your "READ 
quotes from remote server and send them every sec" scenario, I wouldn't 
use do-task, but async HTTP (much more efficient and scalable). I 
think I definitely need to add a few async schemes and make an example 
app.

Max: " the values of those words would be substituted when they are 
encountered."


I don't get where and how precisely this is supposed to happen (at 
Cheyenne boot time in %cheyenne.r like a preprocessor or at services 
install time in %misc/conf-parser.r as a dialect feature, and what 
could be substituted and what not, etc...). This does raise a lot 
of design questions and roughly looking, doesn't seem very different 
from what I was proposing. It seems that you'ld like the preprocessing 
occurs inside Cheyenne while I was more in favour of an external 
preprocessor script as I'm not sure how often users will need such 
feature.

I was thinking that it could be added within the dialect... I might 
look how to add it myself and I could give you an example... maybe 
not now cause I have a lot of things on my plate, but the next time 
I go deep into cheyenne's guts (next time I work on mod-remark).

I suppose having non-blocking async http and ssl, coupled with timers 
could make for a nice distributed system via ws:// . Could have clusters 
of Cheyenne :)

Tried this.. it's not very ws:// 

broadcast" friendly" : I don't see why it wouldn't be? You send the 
READ job using DO-TASK and broacast the result from the ON-DONE handler.

Max: adding support for get-word! for the most common config keywords 
should be easy, just patch the config words definition in mod-static.r 
(and in other mods if required). But as you can see in mod-static 
defintions, the processing part for each keyword may not work with 
a get-word!. For example, 'root-dir expects a file! and will check 
for the trailing slash.

what can be done is to substitute the value directly in the data 
by using change on the series and then moving one step back.  then 
the nnormal parsing will occur and the loaded value's datatype would 
be used normally  :-)

It seems Rebol is causing the problem with the last word getting 
cut off..  I use a read/binary - write/binary of an .ogg file and 
the last bit is cut somehow?

Try this with FF and Chrome

http://shinyrockets.com/delme.html

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.. ?

No AJAX calls, nor other tricks. It's very fast for several reasons 
:
- almost no images.

- no JS lib to load and no JS code to execute when page is loaded.
- server is far from being overloaded.

- MySQL backend is very fast for read accesses (MySQL has a very 
efficient caching system for queries).

- Cheyenne RSP engine *is* fast (RSP scripts are compiled to REBOL 
code and generated code is cached in memory)

hm.. maybe it's the combination of vary fast app server with everything 
in ram and caching and also unbloated web development which rebol 
programmers maybe practice more than the regular webdevs

yes, with curecode I also had to account the fact that it's querying 
the database and it's still so fast.. anyway .. it's very good feeling 
to have responsive webapps

my cebelca,biz app is also quite big and "fancy" and uses only 1 
14x14 image file (icon for filters) :) ..

curecode is also visually full while very clear and clean

but it's not only that, I made apps like this in php and python before 
but they still loaded normally .. the fast loading in my cheyenne 
apps vas also noticed by others with comments "how come it's loading 
THAT fast" ? .. I just said "wasn't me :)"

Is there anything stopping a R3 uniserve and cheyenne?

i was wondering the other day about memcache and Cheyenne

The only thing I touch in %my.cnf is skip-networking (when uncommented) 
and skip-innodb (when commented).

Hash! traversing is missing in R3 IIRC, I have to rewrite some code 
for the new map!. (I still don't get why hash! was removed, why can't 
we have hash! and map!?).

well, BrianH would say, download the hostkit and get yourself a curecode 
account!

I would answer, that spending my time reimplementing things like 
/Library, CALL or hash! in R3 using host kit (and giving my rights 
on it away), while code for such features already exists in R2, would 
be extremely stupid from me.

<rant>To be completly honest, I didn't decided yet if I'm ready to 
spend another decade with a new closed source Core as my main programming 
tool. With R2, we had no evolution and no bug fixing during years, 
undocumented features, no info on how GC works, etc...Same causes 
and context producing same consequences, I'm not very optimistic 
for R3. While keeping thinking about it, I've started learning Scala.</rant>

That said, I'll probably use R2 as long as it is working on new platforms 
versions for the existing apps. R2 will always be a very valuable 
tool for prototyping and daily scripting tasks. But I'm now considering 
other choices for my future projects (especially for business projects).

To make things clear for all, I'm still actively working on Cheyenne 
and CureCode. I have a long todo list for both of them (including 
new frameworks for Cheyenne) and intend to continue with it.

Btw, to clarify also other things, "switching to R3" by porting Cheyenne 
(which by itself would took weeks), would put me in difficult position 
where I would have to maintain 2 versions of Cheyenne (R3 version 
and R2 for all my installed personal and business webapps). Making 
a full switch (porting all my web and native apps to R3), would require 
*months* of work. I currently have around 12h a week (7 days) of 
free time for non-business projects. So, "switching" to R3, would 
mean stopping all evolutions on all my products during months, maybe 
a year until I can port everything to R3. This is not an option for 
me.


So, only a "R2 feature-complete" R3 version could make that doable 
in an acceptable time frame (and with much less risks of regressions). 


And all this huge work for what gain? Well, without threading, almost 
none (to be fair, maybe a little bit lighter source code base).

I'm addicted to the philosophy of "natural language"  cause that's 
what I develop, and how i got started in programming in the first 
place.

Actually, I would say that FOREACH works with map! (= hash! traversing) 
and extensions are better than /Library. No host kit required.

And Scala-made-anything is not applicable to the same use case as 
Cheyenne, if only because of the RAM and disk space overhead.

Lookup for the map! type is very fast, but there is no inherent persistent 
ordering (in theory). However, code that depends on hash! (or list!) 
will need to be changed to use block! or map!. You might want to 
go over your code to reoptimize it too, since some easy-to-use functions 
were not formerly used because they weren't optimal, and now they 
are.

Extensions are better than /Library

  True, Extension are more powerfull, but for simple DLL mappings needs, 
  it's overkill and too costly in maintenance (you have to code and 
  maintain C code for each platform instead of a unique REBOL code 
  base). Again, I can't understant why /Library code cannot be ported 
  to R3 and why we're loosing a valuable feature.

I agree with BrianH, that /Library was kind of limited. Extensions 
are better, although more difficult for novice to use. Somene (Ladislav?) 
proposed to make kind of /Library interface as an extension for R3. 
And IIRC, Max worked on some automatition ...

Mostly development tools and server-side apps.

doc, on windows, its easy because we can load and map functions on 
demand.  the only complexity is to build a proper structure dialect.

I was looking at using some of the windows speech recognition stuff 
via /library  earlier today. Accept voice prompts, and push to a 
web page via sockets.

Playing with PowerShell for the first time as well.  Has some promise.
The speech recognition in Windows 7 is world class.

Without R3 being completely open source, in this day and age, is 
soo 1984. And if the 'killer app' is a webserver, and that web server 
doesn't plan on using R3, then it's not much more than a hobby.
But hey, nothing wrong with having a hobby.

http://huddledmasses.org/control-your-pc-with-your-voice-and-powershell/

Terry: fully open sourcing R3 and using a dual licensing (GPL + commercial), 
as a lot of other small companies do, seems to me like the only viable 
model when you don't have money to invest.

Yeah, I remember how Carl looked at GPL 5-6 years ago, but I've hoped 
that he might have changed his POV looking at how others do (and 
sometimes succeed).

I think that this dual licensing scheme works only when you reach 
a critical mass of users. Given the size of the REBOL community, 
he should just BSD everything and hope enough people would be attracted, 
and when the criticial mass is reached, monetize REBOL with paid 
services, custom builds, dual licensings, goodies (REBOL mug and 
vines),....whatever.

I would be glad to visit Prague and see other rebolers.

wow ... restarted Cheyenne and killed it again :(

just sync and read changelog ... it is ... extensive :-)

Yes, there was a few critical fixes, and especially one for response 
buffer corruption. If you hit these bugs, I can only suggest you 
to upgrade.

Btw, I'm planning to freeze current SVN for a couple of weeks to 
release a new official version. I still have to patch a few recently 
added features and test the MTA more extensively first.

I'll setup a new CureCode instance for Cheyenne (and CureCode itself) 
this weekend. It would make it easier to follow Cheyenne's fixes.

<and put them> on the same Cheyenne server.

I'll bet dollars to doughnuts R2 takes off, and R3 languishes.

It seems to me that there's a bit of misunderstanding here on how 
OSS works. My understanding is that peoples are willing to contribute, 
because they *need* something and they *can* obtain it by modifying 
the source code. Expecting that your product development forces will 
magically increase because you're going open source is, in the general 
case, an illusion. People will contribute only if they're interested 
in your product, have a need to fullfill, and time/skills to make 
it. So, a critical mass of users is required to get enough contributions. 
If you don't get enough contributions, don't blame it on the open 
source approach, blame it on your product (or on your communication), 
because it doesn't attrack enough people to reach the required critical 
mass.

The other issue is that many of the open source projects are just 
too "hard" for the casual user to contribute.  It requires lots of 
documentation to get up to speed and often that is lacking.

That's why "critical mass" is important to reach. If, for example, 
1% of a user base is skilled enough and willing to contribute to 
an open source project, you need to get at least, a thousand users 
to expect significant contributions.

In the past, Carl has made a few attempt at OSS, but it seems to 
me, without understanding how it works. I guess that's why he was 
disappointed when View Desktop was opened for all to modify and he 
received no contribution after several months. The issue was not 
with open sourcing it, it was IMO, in the simple fact that (let's 
put it in crude words) : nobody really cares about View Desktop!

I remember the calendar app was broken in IOS and the source was 
hidden. But that got fixed by efhishant

The situation with REBOL language is very different: it's our base 
programming tool, so it's extremely important for us to get it working 
right and keep on improving it. We are also lucky because the % of 
rebolers with good enough C skills and CS understanding is quite 
high for such a small community, so, (getting to the conclusion), 
if R2 was fully open sourced (real OSS, I mean BSD or GPL, not RLA), 
you can bet on it becoming the faster growing project of all times 
in the REBOL world! I think the main issue in that case would be 
to properly organize all the contributions.

Doc, not caring about the Viewtop isn't entirely true. The problem 
is also that all REBOL experts are very busy with other projects. 
 For R2 it could have been an essential script deployment tool for 
end-users, but that's too late now, and ReBrowse is a much better 
idea anyway.

Open sourcing R3 core wouldn't help anything. Is it because you are 
up in arms over some curecode bugs that haven't been fixed in a couple 
of months? The important parts to have open are already open and 
of course we have people working on those parts. The process that 
R3 is following now is largely correct.

Just an observation that the developer base shrinks as time progresses 
...and I doubt anything apart from open sourcing r3 will help

Why? Do you intend to read the source code and be happy with that? 
What good does it do, if it doesn't reduce the number of bugs, vastly 
improve the design or in other ways lift R3 beyond where it is now?

but Gabriele and Cyphre have been blocked by lack of access to the 
code ... that is a matter of record

Do you think the curecode bugs would then magically be fixed?

 Do you really think that this is my intent by having it open sourced? 
 It's open source because its the logical way to distribute such applications 
 nowadays, offering to any user full insight and control over the 
 product.

but if you read this page:

http://www.rebol.com/rebol3/architecture.html


giving the user full "control" over the product is not the intent 
with R3. If you want "control", use one of the many variants of Python 
or Ruby. I quote "control", because at the end of the day, "control" 
will remove one of REBOL's greatest strengths in that there are no 
official derivatives of the language, that the user will just have 
to wrestle with.


Insight is another issue, which can be noble enough for educational 
purposes, and for that, the core would likely make a good study.

I used the variable 'captcha in my registration.rsp, and that has 
overwritten the variable in my web apps :(

I did use it once with cheyenne but had issues, not sure it was concurrency 
or driver version and/or osx version or sqlite version

This is odd .. I tried calling my batch file using a full path, and 
it did not work.  The only thing that did work was to cd to the directory 
and then call it without the path.

It's a company supplying the Olympics, and needs audio feedback as 
it scans product out of the warehouse... "Im sorry, but that pallet 
does not contain all of the necessary product to fulfill this order. 
Please add 3 more units of spam, and have a nice day"

I tried the url-encode from the repository ... and it does nothing.
It should do this
>> url-encode "=="
== "%3D%3D"

Because those characters are url syntax, and encoding them would 
break the syntax.

Particularly = and & would break url-encoded name/value pairs.

I encode each part of the url and then rejoin

What's the correct way how to deal with uploaded files? I mean... 
if I for example upload a very large file, then I must move it to 
correct location after upload is finished. What is the best way how 
to move a large file in the Cheyenne context? What about a possibility 
to set the custom %incoming/ location before download starts so no 
need for move will be required and we can just rename the file?

And move-file won't be fast all the time. e.g. if you're moving the 
file to another drive.

I think the in-memory mode is not much needed for me. I was a little 
bit suprised why some files are in memory and other on disk. And 
usualy you would like to store the original file (for example the 
csv) before processing anyway.

And do you save the in memory content?

Thanks Doc, I did get it running with some simple selects and updates 
now I just need to learn how to format the returned data. This is 
good stuff. By the way I am using the do-sql method and works great.

I want to move DevBase (R3 Chat) to Cheyenne, but I must admit that 
I am a newbie with Cheyenne.


Currently the code runs as a process, and we tunnel packets thru 
HTTP via Apache.


However, I could run it as a persistent process in Cheyenne, or via 
some method that would simply put the http input and output into 
a socket.

Anyone here know how this is done?

The web server does the serializing and I/O buffering.

And then you can run everything as a Cheyenne webapp

And is this a http timeout or a cheyenne timeout?

Found the issue ... http://www.rebol.com/r3/chat.rwas being cached. 
 Refreshed it in my browser until I got the new version and now it 
is working again.

SVN revision 72: File uploading improvements (changes might break 
older scripts)


FEAT: File upload management improved, in-memory uploading removed 
for consistency.

FEAT: request/store specifications changed. Now it renames the temp 
file to its original name by default. Use the new /as refinement 
to move the file (see Changelog).

FEAT: New complete example of file uploading (client and server-side) 
in www/ folder.

FEAT: New config keyword: 'incoming-dir <%/path/> to specify a custom 
incoming folder per domain or per webapp.

Btw, thanks to Will for improvements in the upload.html demo and 
to Oldes for its frequent feedbacks.

Strange, your blog comment code line appears empty here both in Chrome 
and IE8, but ok in FF??

Right, for both Jim and Graham, 'validate is the way to go : http://cheyenne-server.org/docs/rsp-api.html#def-23

Yes... but in most cases you don't want  none and you and up using 
code similar to Graham's

When the query is built, passed arguments are escaped depending on 
their own datatype and not depending on the target field in the table. 
This could be improved too by using an abstraction layer upon databases, 
giving you access to a logical data model instead of the physical 
model. I'm currently brainstorming on such abstraction layer to see 
the pros&cons.

Cheyenne's CGI handler reads the first 512 bytes of a CGI script, 
if it contains "REBOL" followed by a [, it loads the script and evaluates 
it. If header is not found, it reads the shebang line and run the 
script using CALL (so as a separate process). So, in order to run 
R3 scripts, you need to patch Cheyenne's CGI handler to run all scripts 
with CALL, or provide a R3 CGI script with shebang line and extra 
text (512 bytes) before the REBOL header (R3 should ignore the extra 
text).

Good ... I guess ... I thought I had lost the ability to set a parameter. 
 If you are looking, I also had trouble with the worker-libs and 
had to enter absolute addresses to get them to work ... %/c/cheyenne/www/private/mysql-protocol.r

For the CureCode I have set a new account request in and am getting 
no email. I went back to my Curecode R3 account and requested the 
password email and so far no email.  For new request, status says 
'account not yet activated'

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