AltME groups: search

Not the problem of the antialiasing, I just think i made a false 
translation of the command used in the shapes.

They use a smouthing curve, me not i guess. I have to verify that.
But Rebol can draw smoothing curves too, no problemo.

but the new grad-pen command of draw is awesome

Maxim, yes, I think this is one fo the ideas we discussed at DevCon 
in Paris.

If we add the DRAW shape->coordinates interface this will be yet 
another usage of it.

The current internal architecture already counts with sort of persistency. 
Currently we are just discarding all the internal shape paths on 
every redraw. I fear the main problem is how to handle this efficiently 
at the REBOL layer, especially GC handling...it can lead to big memory 
consumption in case programmer won't free all references to the DRAW 
elements etc. Or maybe a command for manually edstroying the 'DRAW 
internal context' would be the best solution...

Another question is, even if we solve the REBOL high-level access 
interface to it, how much would direct DRAW element modification 
at such internal level affect the performance, is it really worth 
doing that(ie make things more complex)?

Because in that case we will be only 'bypassing' the DELECT parser 
and AGG's internal Coordinate conversion pieline(s)...the rasterizing/rendering 
pahse needs to be always redone(but we could try to play with some 
clipping tricks here too). Both parts are already very fast but I 
agree there can be gain in some large data cases. This needs to be 
investigated before we decide to add such feature.

Yeah, the 'sql command is just a console wrapper for the underlying 
functions. I got tired of typing "db-select test [] []" ... but scripts 
should definately use the db- functions directly.


If you see some strange query results (wrong row(s) being returned 
or no rows returned at all) ... this is probably due to the binary 
equality bug I posted in !REBOL3. I'm putting some workaround code 
in (== instead of =) but working around < and > is a bit tricky! 
;)

I'm not a rebDB expert....So take my answers as something to be tested:

-- I don't think there is an explicit OPEN command. Simply access 
the table (with SELECT, INSERT, etc) to open it.  Similarly, no CLOSE 
-- use DB-COMMIT to ensure caches are flushed.

--rebDB supports REBOL datatypes. Have you tried creating a table 
row with a datetime in it? Did you have a problem?

Correct, it's just an 'ask loop (hence no semi-colon for command 
termination).

Well, currently I download the update and then write a command script 
that deletes the current application, and then renames the download 
to the application name, and then starts it up, call the command 
script and quit.  
But forwhatever reasons .. it often fails

so instead of using a command script .. I thought  I could use Cheyenne 
instead as that is always running.

I see your way dispenses with the need to run a command script.

I ran my own encap version as I needed /command

and I didn't think the command license permitted me to run command 
on multiple servers

SVN r62


FEAT: RSP scripts can now set response/buffer to a file! value allowing 
main process to transfer it optimally (see changelog.txt)

FEAT: worker tasks now have a more readable and cleaned-up command 
line.

FIX: fixed a bug with internal UniServe's DNS cache querying preventing 
'open-port from working in some cases.

Nick .. I'm using R3alpha ..and initial testing showed I can't get 
the command line in r3alpha

Requires /Library component! (needs /Pro, /Command or /SDK

this has changed, no?

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

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

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

mysql.exe command-line works well.

ODBC drivers are binary, and are only included if you have /Command 
or the SDK. Which also include a mysql driver, but not as good a 
driver as the free one linked above.

Well, that's a good idea, but the SDK license is quite restrictive, 
I shouldn't distribute Cheyenne in binary form (see "REBOL API Restriction" 
part at http://www.rebol.com/docs/sdk/sdkintro.html). RT didn't asked 
me to pay any additional license so far, so I don't want to push 
it further by giving away a free /Command with Cheyenne.

Graham, which version of Ubuntu are you using? The newest version 
of Ubuntu doesn't use the /etc/init.d system anymore, it uses upstart 
instead: http://upstart.ubuntu.com/getting-started.html.Much easier 
but less powerful (but maybe enough for you) is editing the /etc/rc.local 
file. That just starts an app after booting, it doesn't allow you 
to restart or stop it with a command. Just put the command to start 
up cheyenne on a line between "# By default this script does nothing." 
and "exit 0"

If you don't want to kill your running apps on session end, use  
"disown" command.

does it also say that if you use a plain enface? isn't this related 
to having access to pro/command features?

My experience with RT is, that if you try to communicate, you might 
get special deal. So - maybe /Command is no more a source of revenue 
stream for RT. What about asking them to relax the restrictions?

Perhaps it could be an R/Command build option?

Making the REBOL side process a command-line option for /Core and 
build option for /Command would be a good improvement.

You should just "Reset Workers", it's enough to reload all the webapps. 
You should also consider running your dev instance of Cheyenne with 
-w 0 command-line option to make it reload all apps on each request.

SVN r96 -> r103 (most of new features were suggested by Carl)  


FEAT: encapped Cheyenne binaries now returns 0 (or, in case of panic, 
a REBOL error code) on exit

FEAT: (UNIX) Added a new command line option: -V or --version. Displays 
Cheyenne's version, then quits.

FEAT: (Windows) Cheyenne's version is now displayed in the tray icon 
help message.

FEAT: RSP debug mode extended to display tail of trace.log file using 
a new [show trace] button.

FEAT: RSP debug bar look improved, menu horizontal alignment fixed, 
direct link to RSP API online
documentation added.

FEAT: RSP errors are now displayed in an overlay popup instead of 
being inlined in the page.

FEAT: RSP debug bar javascript code footprint reduced to a single 
object: rspdbg (avoids polluting global namespace)

FEAT: new RSP API function: debug. Switches the debug mode on or 
off, for the current RSP script.

FEAT: new API function: debug?. Returns TRUE if debug mode is active.

FEAT: 'debug config keyword definition extended to accept an optional 
block of parameters.

FEAT: RSP session/start now returns the session/active? flag as result.

FEAT: (UNIX) Added a new boot option: -h or --help. Displays the 
command line syntax help and quits.

FEAT: Improved RSP function 'validate to accept default values for 
optional parameters when using
the /full refinement.

FEAT: now plain REBOL scripts can also be run by the RSP engine! 
(see www/show.r)

FEAT: new RSP API function: emit. Does a REDUCE on its argument before 
APPENDing to response/buffer.

FEAT: added new RSP syntax for emit-action : <%? ... %>. Does the 
same as 'emit, but inlined in a
template page.

FIX: (Windows) improved child processes termination with a more graceful 
method using JobObject API

FIX: (UNIX) optimized child processes termination using a kill() 
routine! wrapper instead of CALLing the shell command
FIX: flush HTTP logs in cache on exiting.

FIX: mod-userdir was still commented in config file modules list, 
disabling user/group keywords in httpd.cfg

More info on the new RSP functions in changelog.txt file.

Hi Oldes, good point, I was thinking about adding a worker processes 
user-controlled killing policy since years now, but it  has never 
bothered me on my production linux servers. 


Also, if you use the -w command line option, you can (in theory) 
set the threshold for workers kept alive after each request. In practice, 
a worker gets killed only if the threshold is reached and after a 
request is processed, so you might have cases, where more workers 
than should be, remains temporary after a burst of requests.


If it's really an issue for you, I can have a look at this feature 
to see if there's a simple way to implement a killing policy (would 
decrease the number of worker processes using 1 / t or e^(-t) function 
classes). See function plots at :
http://www.wolframalpha.com/input/?i=1+/+t
http://www.wolframalpha.com/input/?i=e^-t

- pro: REBOL/Pro kernel
- cmd: REBOL/Command kernel

Yes, command kernel allows you access to odbc database sources

The worker number doesn't decrease unless you're using the -w command 
line option (or unless your code or a native bug crash some of them 
badly). Having more than 8 workers is possible if some of them are 
blocked (in a endless loop or waiting something forever). If you 
quit Cheyenne in that case, they'll remain there and will need manual 
killing. Cheyenne could do a better job at handling those non-responding 
workers in future versions.

You don't need any special tool for port checking in winXP...just 
use the console NETSTAT command.

To open a console window for each worker process, you need to change 
the CALL command line from %UniServe/uni-engine.r:

    call join form to-local-file system/options/boot [" -qws " cmd]

Replace:
* CALL with CALL/SHOW
* -qws with -s


Also, in that case it is also more practical to reduce the worker 
number to 1 using Cheyenne command line option: -w 1

Script: "Encap virtual filesystem" (21-Sep-2009)
REBOL - Security Check:

Script requests permission to execute a system shell command: netstat 
-f inet -p tcp -na
Yes, allow all, no, or quit? (Y/A/N/Q)

the only way I see is passing the config file path as command-line 
argument, something like:
cheyenne -p 8001 -conf /home/devel1/app/current/

safe in the sense that some code in uniserve/cheyenne might have 
an absolute reference to the req/in... and this could break the chain 
of command..

yes, the http connection will not close until it times out.


if the curl command line waits for ip close to return, its possible 
that is what is happening.

there are probably ways control this via some curl command line options?

20/4-04:00:21.407196-[CGI] Error:/bin/bash: c:devsdktoolsrebol.exe: 
command not found

can anyone get a login for the cheyenne wiki?


I'd really like to put down my trials and errors of building my own 
cheyenne mod (with handler), so that others may benefit of knowing 
the few little caveats which can make the whole thing fail .... 
maybe do something like a step by step tutorial to begin with.


I'd also like to document all the phases of each internal layer of 
cheyenne (there are many), so that we can more easily navigate the 
code, knowing what we are doing and what other phase is part of each 
type of mod,extension, service, etc.   often, we see just one or 
two parts of a system implemented per module and its hard to get 
the whole picture.   


ironically, looking at the base objects is also hard to do, since 
there is so much "internal" code that it gets REALLY hard to understand 
what is internal, what is "interface" and what is provided as helper 
funcs for your own systems to use.  Add the fact that there are many 
layers sitting over each other, some layers which aren't actually 
layers of code, but layers in the "chain of command" and various 
phases.


now that I've made sense of a *portion* of this, I think I'm well 
placed to start documenting this.   I think that having a complete 
api reference for cheyenne would be really good for adoptance.


It would allow many of us to simply create integrated tools which 
just drop into cheyenne.  (like remark)

he actually does give the difference between /pro and /command on 
the page.

keys are not required to run sdk/command encapped builds

so, when will this be available?


*very soon*  I am building my first test release for my client tonight.


most of the research and prototyping is done, I already did some 
client demos for the people who are funding this project and I'm 
now in the "delivery" phase.


The most complicated parts of the system are already working (i.e. 
handler processes, dynamic compilation, automatic api interface building, 
per-host api/config, request/response chain of command, multi-format 
output, and more.)

a lot of details are still "up in the air" as far as implementation 
goes, so if you really have a need for this, PLEASE STAND UP and 
raise your voice.  tell me what you need, how you want it to work, 
etc.

so far I plan to deliver the first release with: 

  support 4 interfaces for calling : GET url, POST XML, POST Form data, 
  POST JSON.

  support 4 output formats : XML, HTML, JSON, TXT (which is in fact 
  rebol native data)


obviously this will be an ongoing project and anyone who is interested 
in helping out is welcomed to do so.  :-)

Cheyenne revision 134:

- FEAT: new config option (globals section): 'allow-method. Extends 
allowed HTTP methods.

- FEAT: -w command line option extended to allow to specify an additional 
"start" number value.

- FIX: -w 0 now starts Cheyenne with no workers at all (was spawning 
one at start until now).
- DOC: updated %changelog.txt (was lagging behind a bit).

See %changelog.txt for more info.

Those drivers are built in REBOL/Command. It depends if Mysql 5 and 
Oracle 10 servers are compatible with older drivers. I can only answer 
for Mysql, and the answer is no.

BTW, if you launch Cheyenne from REBOL console, you can still pass 
it command line options, my local Cheyenne is launched using:

rebol -s cheyenne.r -vvv -w 0

command/core has library

Most people don't have Command/Core

nowadays, I think command is only available via the sdk, no?

i pasted the command lines too

Are you using the Pro or Command binary? (I guess it is the r139 
one)

the funny thing is im trying to "debug" from the command line and 
i have to login to the app 1st but if the debug flag is on, im getting 
back and error page and multiple session cookies

Dockimbel: i want the authentication. im just asking how can i test 
it programmatically easily. any idea whats wrong w the curl command 
lines?

pff.. my-http is not really transparent...

>> do http://www.rebol.org/download-a-script.r?script-name=my-http.r

connecting to: www.rebol.orgScript: "patched HTTP/HTTPS protocol 
with cookies support" (18-Aug-2006)
== none
>> trace/net on
>> read http://localhost:8080/testapp/login.rsp

URL Parse: none none localhost none testapp/ login.rsp** Script Error: 
querying has no value
** Near: http-command: either querying ["HEAD"] ["GET"]

This is both against the structure of Unix and modern Windows systems.


UNIX filesystem layout usage are not identical. Here are the Apache 
error log location in just 3 UNIX flavours (among dozens):

* RHEL / Red Hat / CentOS / Fedora Linux Apache error file location 
- /var/log/httpd/error_log

* Debian / Ubuntu Linux Apache error log file location - /var/log/apache2/error.log

* FreeBSD Apache error log file location - /var/log/httpd-error.log

and here are the possible locations of configuration file:
* /usr/local/etc/apache22/httpd.conf
* /etc/apache2/apache2.conf
* /etc/httpd/conf/httpd.conf


Notice how the file name changes too (both for the log and conf files). 
BTW, I personnally prefer the GoboLinux approach ;-).


One the Windows front, it is barely better. The registry database 
is fine for storing parameters (name/value couples), but not a REBOL 
dialect file. A common way is to store files created at runtime in 
%USER%/AppData/Local/<appname>/. Cheyenne stores all his files (including 
config file) either in the local folder or in %ALL_USERS%/Cheyenne/. 
Storing them in %USER% hierarchy should be better.


Taking into account every OS specificities (or oddities) is not always 
a good choice for a cross-platform product. I know that Cheyenne 
needs to be gentle with the OS best practices, so I am willing to 
improve it whenever it is possible, but without sacrificing the default 
behaviour (because that is the way I want it to work for me).


BTW, I am also willing to test the centralized logging approach, 
but it has to be a cross-platform solution. So an abstraction layer 
needs to be built with connectors for UNIX syslog daemon and Windows 
Event Logger (they are two types to support: pre-Vista system and 
new Vista/7 one). Has anyone already worked on such wrappers with 
REBOL?


I personnaly need that the log files be exactly in the same format 
and if possible at the same place across platforms to make my life 
easier, so this will keep being the default anyway. The current -f 
internal Cheyenne command line (Windows specific currently) could 
be extended to work on UNIX too (and no Max, this one cannot go into 
the config file, because it indicates where the config file is located 
;-)).

BTW, what verbose level are you using? (how many "v" in the command 
line?)

https://github.com/joyent/node/wiki/modules#compression
these are the kind of compression solutions for nodejs

they also have a plain gzip command line utility based solution too

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?

sqlab Re: Win-Call


Have you tried using the full "command", I suspect that may be the 
problem you are facing:

>> do %call.r

Script: "Untitled" (none
)
>> win-call/output "cmd.exe /c dir" str: make string! 1024

== none
>> probe str

{ Volume in drive C has no label.^M
 Volume Serial Number is F4A6-6294
^M

^M
 Directory of c:\Red\quick-test^M

^M

09/11/2011  18:26    <DIR>          .^M

09/11/2011  18:26    <DIR>          ..^M

09/11/2011  06:16             6,148 .DS_Store^M
13/10/2011  18:16             8,545 call.r^M
etc.

The plink example didn't work for me. I got the following message:


>> win-call/output "plink.exe -l user -pw password [checkall-:-host] 
 df "  str: make stri
ng! 102

4
== {CreateProcess failed!: The system cannot find the file specified.}

Though I got a similar message from the console:

C:\Documents and Settings\Peter>plink.exe -l user -pw password [checkall-:-host] 
 df

'plink.exe' is not recognized as an internal or external command,
operable 
program or batch file.

plink is a ssh command line tool  of the putty package

I'm trying to send an email within an .rsp script. Is this not possible 
because I keep getting errors: 


** User Error : Server error: tcp 503 AUTH command used when not 
advertised 
** Where: none 
** Near:  [smtp-port: open [scheme: 'esmtp]

After a few attempts playing with expired sessions, I can't reproduce 
your issue with the latest SVN revision. Try to run Cheyenne in verbose 
mode using : -vvv as command line argument and send me the log chey-* 
log file once the error happens.

The chey-<pid> file is produced when Cheyenne is run in verbose mode 
(-v... command line option) with no window (-w or encapped).

I created this group, cause ever so often these experiments come 
around and we loose them... this should become a quick repository 
of tests & disussion for profiling discoveries we do.


any test should provide the full test command-line code, so its easier 
for other to copy-paste & compare without having to re-type.


ever so often, a compilation should be done, highlighted in a different 
color for easy referral...

Do you use the skew command in draw ? or are you calculating the 
coordinates of your 3D objects for each layer.

(I think SKEW allow to simulate isometric rendering in AGG, but it's 
just an assumption, i never tried it)

just a note - COMMAND. I was thinking lately, if the word is not 
too good to be used for extensions? Commands fit dialects. I thought 
that we could use ROUTINE in Extensions. But I know that it might 
be late for the change, or that I have maybe shifted understanding 
of what "command" word actually means ...

I remember writing a program many years ago on my Amiga, that would 
change the input to what I choosed using a simple lookup table. I 
used it to write fast in e.g. IRC, where I would make a table with 
the 3 first letters of many english words. When I wrote 3 letters 
and pressed space, it would write the full word. Could be used to 
change things like !did to didn't. The good thing with the Amiga 
was, I connected to the console device (or what it was called), so 
the program worked everwhere with all other programs using the OS. 
Could also be used to e.g. program fast using shortcuts for command 
words.

and the first item must be solely the command

and you'll get whatever the command handler deems to be the right 
result to pass along

you send the command to the port and retrieve either a multi or single 
line response

Sure ... but then a new command comes along ...

there's also the issue of returning the data to the client issuing 
the command.

Just looking at what R2 does .. .each time it does a file/directory 
transfer, it opens the data connection, sends the command and then 
closes it again.

This isn't going to work unless I queue the user commands and process 
them once a command has completed.

It works on my server, but I tried it on one of the linux distro 
sites and there it doesn't.... as my write commands are written to 
the port before the previous commands have completed.

Check IO-Request connection flag. This is not a socket check, it 
is a request state flag check.
Check the port/data for an existing buffer.

If no buffer found, allocate one that is of the default size (32,000). 
Note: not 32K.
Compute buffer space available.

If available space is less than half the default size, extend the 
buffer.
Recompute buffer space available.

Setup the IO-request data and length fields. Data is the buffer tail 
position. Length is the buffer space available from above. Clear 
the actual field.
Call the TCP device with READ command.
Check result for error. If error, throw it.

so every command uses the timeout .. so don't understand that

Uploaded latest version with this change, and the STOR command .. 
just in time for bed!

Hmm... sounds a serious lapse to let code no one understands be placed 
into r/command ...

Sometimes you want to write to the port, and then continue to write 
... so your awake handler returns false.

But sometimes for the same command, you want it to return on completion 
.. so your awake handler returns true instead.

So, .. .what is the best approach?  Pass a flag to the write?
Use a dialect for the write data block?

On testing a ftp server behind NAT ( well, it's a home system ), 
the ftp server responds to a PASV command with its local non addressable 
network address.

I think mine allows file upload resume by sening a APPE command with 
the rest of the file

but rather than handling it directly ... you can just write the command 
to the port

DevBase is the forum/filestore that you access withg the CHAT command 
in R3.

ChristianE the idea arises from the fact the time server send only 
response and close immediately, so I only implemented Read actor. 
The problem is that you may not create a new refinement but only 
redefine one existing. 

time scheme needs a little polishing and will be posted to script 
library.

Anyway you are right the only possibility how to controll the scheme 
in wider borders is to write a command block and wait for reply. 
Another not so generall would be write into port state context and 
use this as switch for read actor.

I am wondering how one would implement the IMAP4 IDLE command .. 
see http://tools.ietf.org/html/rfc2177


It seems that once one sends an IDLE command, the server might then 
send a response back any time up to the server's inactivity timeout.

Start is a cmd.exe builtin command on Win2k+ (not Win9x). Try call 
"cmd.exe start textpad" or calling Textpad directly.

the above code does not run in R3. Dunno if "end" is forbidden or 
became a keyword, but I get following error, if I don't change end: 
to en:


>> s: now/time/precise loop 1000000 [parse "abc^/def^/ghi^/" [start: 
any [end: n
ewline start: | skip]]] now/time/precise - s
** Script error: PARSE - command cannot be used as variable: end:
** Where: parse loop
** Near: parse {abc
def
ghi
} [start: any [end: newline start: | skip...

There are character length limits to what you can put in a doc string. 
That is why we make the manual web page accessible from the R3 command 
line. It was the same in R2.

what is the command type?

A command is the type of function that you currently use to access 
extensions. Soon it will be more.

Is there a list of  words reserved for parse, as

>> parse "a b" [ copy limit to " " ]

** Script error: PARSE - command cannot be used as variable: limit
** Where: parse
** Near: parse "a b" [copy limit to " "]

>> parse "a b" [ limit ]

** Internal error: reserved for future use (or not yet implemented)
** Where: parse
** Near: parse "a b" [limit]

How then can I get this code, executed from the command line, to 
always quit?
  r3-a97-3-1.exe --do "print true attempt [exit] print true quit"

You will need to have some way for a block of dialect to be passed 
to a command-based dialect processor. So some function to take the 
place of DELECT will be required, even though it won't be compatible 
with DELECT.

I wonder what happens to DELECT itself. If we will use command interface. 
Will DELECT still be any usefull?

I believe command/DELECT changes are being made for good, so that 
we can use it also for other extensions. The only thing missing for 
Extensions then is - Devices integration and or callbacks?

if your app also has an extension which can give data to scintilla, 
then you'd just  add a command to the above string which calls the 
extension's command! with parse results.


the xtensions are very adept at parsing blocks, so converting that 
back to scintilla as native C data is possible there.

There is a new command block evaluator that needs to be used a bit 
differently. Hence the DRAW dialect loop needs to be adjusted. As 
the AGG interface

Henrik - I saw small mention of some speed-up, due to more streamlined 
command interface (probably in opposite to DELECT). So - any chance 
we get updated 1000 cows demo or so, to see "the difference"? :-)