AltME groups: search

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.

2) Send the READ job to a worker process using DO-TASK (but it will 
block it for 30secs, so not a very scalable solution).

Tried this.. it's not very ws:// "broadcast" friendly

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 should have my new site online within a week or two, using cheyenne 
on a linode server.  I did some of the design work this week, now 
I have to build the site around it.

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 :)

Requires /Library component! (needs /Pro, /Command or /SDK
 : right, Core has /Library since a while.

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.

Why are think like Javascript not prefixed with a tilda?

I have a weird delay happneing with the tts chat demo.. there's a 
pause of exaclty 30 seconds before the broadcast? I see no reason 
for this?

Terry: echo is much faster now (1-2s delay only). 


For the 30s pause, that might be caused by a network timeout on a 
sync port action. 
>> system/schemes/default/timeout
== 30

The delay is quite a bit less now - not too bad. I noticed that the 
last word (or part of one) seems to get cut off? Are you guys seeing 
the same?

yeah last word often gets cut on shorter strings .. need to get xml 
via https:// POST working for a solution.

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?

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)

The result is so fast that it looks like a RIA application, you hardly 
notice the redraw delay.

I agree that the application design counts also, being bloat-free 
helps a lot.

I must admit that, a few years ago, I was the first surprized when 
I put only my first RSP scripts, even more when I added db queries...

Right, a lot of UI effects are easier to implement in JS rather than 
generated server-side.

Is there anything stopping a R3 uniserve and cheyenne?

MySQL has a very efficient caching system for queries

are you using mysql query cache?

Pekr: it's more than just a word ;-)

So, the question is, what are the functional limitations in r3alpha 
that is preventing a port ?

there are some funny things with call ... try calling a command shell 
inside the rebol console

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

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

Scala has a lot to offer, especially for server-side. It compares 
very well with others, its main issue is just that it's not REBOL...so 
not easy to wrap a REBOL-addicted mind to it. Besides that, it is 
very promising.

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

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.

Here here.

Rebol is a mistress.

Will: I'm not leaving, I'm still here, at least as long as R2 obsolesence 
prevents it from working. It's just that my future projects will 
be most likely based on a open language with a large community. Not 
every programming language is good for all jobs. Btw, sometimes it's 
good to change your horizon to discover new things. Being in the 
position of a newbie can be funny too. ;-)

Not to say that a Scala-made web server written by Doc wouldn't be 
cool - it should just be called something else.

Brian: I'm using mainly FIND, NEXT, BACK, SKIP to navigate in hash! 
values. Hash! type is supposed to be a block! (inheriting all series 
navigation capabilities) with fast lookup times, so I've always used 
it like a block!. That's why I feel like I've lost something with 
map!.

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.

actually, we can build a /library extension in about an hour.

Brian, do you have any application code out there with a user base?

I mean something that actually has to be used in the field with a 
moderate amount of seamlessness.

I've never need to wrap a C library, but I have to wrap libraries 
written in other languages all the time. Languages without C interfaces.

Brian: I can't see how my code would be more optimized with map than 
hash (but I'm not a map! expert). For example, mime types lookups 
are made using a 1<=> N flat structure stored in a hash!.

make hash! [
	image/bmp	bmp
	image/gif	gif
	image/ief	ief
	image/jpeg	jpeg jpg jpe
	image/png       png
	image/tiff	tiff tif
	...
]

How can map! handle this easier than hash!? (looking up a mime-type 
based on a given extension)

Different from each other too, as I am also a real world developer.

Max: that would be good (with support for UNIX / OS X too), unless 
it requires to wrap a big 3rd party library?

In theory it would by possible to make an extension that could implement 
the /Library dialect, or a better version of it.

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.

R3 as an academic white paper is great. But I've learned that building 
stuff nobody wants is a waste of life. (Paul Graham agrees)

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.

Doc, is there a binary for the latest Cheyenne that works with curecode?

James: no, but I'll probably make a few ones today so people can 
test lastest CureCode easily. What OS are you using?

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.

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've got a REBOL notepad ...anyone want to buy it?? :)

If it has a nice splash screen with a 3D rotating logo (all in REBOL), 
I might buy one. ;-)

It's paper!  Allen gave it me a few years ago when I was in that 
part of Australia ...

So, it's a collector!

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.

It's already working now with latest Cheyenne+CC. I already have 
a Cheyenne instance running 2 CC instances for a customer since a 
week without issues. I've tested locally with up to 4 instances, 
each with different settings without any issue so far.

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.

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.

So, the options are either obtain a critical mass by waiting for 
a 1000 users, or, improve the docs to reduce the potential critical 
mass

Or provide a good enough support, so that people won't get stuck 
with bugs for months or years.

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!

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.

Graham, I don't agree with that observation. In fact we've gained 
a few people the last year or so.

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

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.

Yes, I'd estimate that a lot of bugs reported would then have patches 
available now

I should have added a protect 'capcha to avoid such issues.

I've wrapped all my code into a context ...

All SQLite accesses would block the server, so it would be OK by 
making a standalone Uniserve+sqlite combo. Such SQLite  frontend 
exists already (don't remember if it was made in C, Python or Ruby).

I suspect if you make a uniserve service then requests are serialized

What happens if I call a process that does not return .... eg.  a 
rebol server via a batch command .. is the helper process blocked?

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.

LFReD ported to websockets using the TTS from the demo. Opens up 
a whole new world.

I already have a paid gig for it as well :)

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"

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?

I think that under Windows for fast file movement I can use:
set 'MoveFile make routine! [
   		"Moves file using OS"
        lpExistingFileName  [string!]
        lpNewFileName [string!]
   ] kernel32.dll "MoveFileA"
But what about under Linux? Just a simple call?

here is from the change-log:

RSP: new method 'store added to Request object. It simplifies uploaded 
files

   management by abstracting file's location (memory or disk). Example:

			request/store request/content/file %attached/
			

   will save the uploaded file passed as "file" query parameter in %attached/ 
   folder
	  using the original name (!!watch out for security issues!!).
	  
	  		request/store request/content/file %attached/my-file.bin
	  		

   will save the uploaded file with a forced name (original name needs 
   to be saved
	  separatedly if needed).

I'm currently reworking the response/store function. I'm considering 
dropping in-memory uploaded files mode, it was supposed to help processing 
uploaded data files (think CSV files for example) avoiding the disk 
write/read part, but it just adds complexity for a marginal gain. 
If anyone found that mode useful, please say so now.

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.

When uploading a file, the RSP script is called when the upload is 
completed.

If you're referring to the httpd.cfg file, I don't have any references 
to mysql except for those referring to actual databases. What I did 
to test mysql was use the rebol mysql driver (in a normal rebol shell) 
outside of the Cheyenne environment to make sure it worked. Hope 
that helps.

I usually load mysql driver from a local Cheyenne libs/ sub-folder 
:

globals [
    ...
    worker-libs [
         %libs/mysql-protocol.r
    ]
    ...
]

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?

(BTW, I'm doing this to move DevBase to the new Linnode server... 
to offload it to a faster location.)

If it's running as a single process .. that won't scale very well 
will it?

It scales very well... as long as it has a web server sitting in 
front of it.

as a cheyenne app it probably would run faster

I can write a CGI to do that, but it will be slower because it requires 
an extra CALL from cheyenne.

So, I guess a short RSP should do what I need.

if you want to let users login, then you need to track a session 
cookie

And then you can run everything as a Cheyenne webapp

This is for R3 Chat, not web.  Session management is already there. 
I'm simply using a port 80 tunnel.

Ok... got a one line RSP that works for this:


>> to-string second load write http://host4.altme.com/echo.rsp"testing"
== "testing"

Ok... basically got it working, but it's very slow due to hitting 
a timeout on each packet.