AltME groups: search

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.

can you provide the DRAW data for the octagonal/triangle icon? I'd 
like to try something....

For example, I did the Try REBOL site with it on top of QM, but I'm 
working on replacing QM fully

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.

Doc says he will try and fix the 'alert issue ... though he's not 
sure it will fix the ability to run as a service

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?

re Cheyenne PID: your OS ID returned by system/version/4 might not 
be the same as the Linux one. Open %misc/os.r and add a new entry 
in the SWITCH block with your system/version/4 value and [%misc/unix.r], 
then try again.

I've removed -w 0 option also to mimic your config, I'll try putting 
app-init.r back now.

You should get some if you try to use any session object functions 
or access any session/content variables.

did you try *do ?

Gregg: I'll give it a try today to see what's going wrong.

send them to try rebol?

2.7.7 didn't looked as stable as 2.7.6 when I first tested it (View 
crashed on linux, CALL's code seems to have changed). As I can't 
take any risk with my code in production, I've sticked to 2.7.6 so 
far. Maybe I should give it a more serious try now.

Thanks, I remember now - I'll give that a try.

That works. I'll now try it with REBOL/Services.

Thanks, Kaj  - I'll try to check that out later.

The actual system will run under Windows but we've encountered a 
strange problem. I'm trying to do some testing on my Mac to try to 
isolate the problem.

Cool Cheyenne on OSX... I will give it a try on our new server.

The code in my Try REBOL site supports this, although it isn't even 
used that way

Graham: you should try by adding the following header to your RSP 
script outputting a PDF file in order to display it in the browser 
:
response/header 'Content-disposition  {inline;filename="doc.pdf"}

Also from what I understand. Carl has lot of work on finalizing the 
design of R3core lib now so ti can go BETA. So IMO it is too early 
to make some 'fixed' configuration of the official hostkit. I believe 
He'll try to define the official hostkit set after the r3core goes 
beta.

You can also do it in a try statement and check the error codes.

If you can send me the sample, I'll try to take a look for you later 
on.

alan, if you use getJson, you expect to see an application/json header. 
 So, try just $.get instead ....

You're using a literal string as response, you should try to add 
a COPY in front of it to avoid side-effects: response/buffer: copy 
{<svg></svg>}. Even better, as you're in a templating system, make 
it a template:

<% response/set-header 'Content-type "image/svg+xml" %>
<svg></svg>

Try with: locales-dir %DocK/catalogs/

let me try a clean checkout

by app-root i mean that directory level which cheyenne will never 
try to reach above

i have a couple of ideas how to hack this, but what would be the 
correct" way?"


You could try using the ALIAS config option. Add this to the httpd.cfg 
file in a domain section (not sure if it would work in a webapp context):

    alias "/rest" %rest.rsp

and call your REST resources with:
    /rest/asd 
    /rest/qwe


In %rest.rsp, you can put your URL parsing code to produce a "REST 
routing" and return the JSON object. It might also work with "/" 
(untested).

is it just curl? i will try from rebol 1st

Thanks for your suggestions, I'll try to improve this page, especially 
for newcomers that don't know about REBOL.

It recognises the fast-rebol-cgi keyword in the globals now, but 
it doesn't seem to do anything. It seems to try to execute REBOL 
code as real CGI. It tries to use the shebang line and has permission 
problems with CGI files that it didn't have before

having issues starting the cheyenne server from win. it doesn't find 
the system libs.


 I had a fix for the same issue in some other code I did... I'll try 
 to see if this cures the bug in cheyenne .

I didn't try running cheyenne as a windows service though, if that 
is what you meant.

Graham, did you try the webservice mod?

Try REBOL is the first dynamic site I've done that way. You stay 
on the same page, send in data to a service interface and get data 
back that updates arbitrary parts of the page

It recognises the fast-rebol-cgi keyword in the globals now, but 
it doesn't seem to do anything. It seems to try to execute REBOL 
code as real CGI. It tries to use the shebang line and has permission 
problems with CGI files that it didn't have before

Thanks, I'll try

just for the sake of test, it would be valuable if u could try your 
'do* code using 'do

7-May-2011/20:07:17+2:00 : make object! [
    code: 311
    type: 'script
    id: 'invalid-path
    arg1: 'mod-rsp
    arg2: none
    arg3: none

    near: [if exists? file: service/mod-list/mod-rsp/sessions/ctx-file 
    [try-chown file uid gid]]
    where: 'set-process-to
]

Kaj: can you try with user "www" only?

Could you extract the mod-userdir/get-id function and try to run 
it from a REBOL console using:

    col: #":"
    get-id "www"

i can try on mac too, if u tell me what should be tried

ok, i will try that, thx

no, i have 1 webapp only now, but let me try in an incognito window

i'd be interested in looking into the sessions during runtime too.. 
can i do it on the cheyenne console by pressing escape?
You can access them in 3 different ways:


1) if run from sources, escape in the console, then enter: probe 
uniserve/services/httpd/mod-list/mod-rsp/sessions/queue. Type do-event 
when you want to resume Cheyenne.


2) run the %clients/rconsole.r from the source archive, you will 
have a remote console connected to your local Cheyenne process (try 
on prompt: netstat)


3) add this to the config file in globals section: persist [sessions]. 
When you want to look to the sessions, just stop Cheyenne process, 
a .rsp-sessions file is created holding the session objects.

You should try to send a GET request first on the login.rsp page.

This is awkward because these areas have distinctly different characteristics. 
These walls will be run into as soon as you try to implement standard 
security practices

but why am i not getting such a nice and descriptive error?
btw, i was trying to catch this error, but no luck:
>> e: catch [cfg/root-dir]
** Script Error: Invalid path value: root-dir
** Near: cfg/root-dir
>> e: try [cfg/root-dir]  
** Script Error: Invalid path value: root-dir
** Near: cfg/root-dir

how can i get this as an error object, do i can explore?

but, nevermind, i will try nodejs first and see how these things 
work there, how hard is it to integrate the various implementation 
techniques into the middleware stack

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 happen to have a win7 laptop around. i will git it a try, if u 
can be more specific about the versions of ur environment
run http://cheyenne-server.org/tmp/cheyenne-sources-r146.zip
with http://www.rebol.com/downloads/v278/rebol-view-278-3-1.exe?

i happen to have a win7 laptop around. i will git it a try, if u 
can be more specific about the versions of ur environment
run http://cheyenne-server.org/tmp/cheyenne-sources-r146.zip
with http://www.rebol.com/downloads/v278/rebol-view-278-3-1.exe?

FYI: I've been doing some web sockets testing with Cheyenne. It seems 
that the specification is still a fast moving target. The browsers 
are trying to keep up, but server implementations (like Cheyenne) 
are breaking. For example, the Cheyenne web socket samples work with 
Chrome 12 on Ubuntu, but not with Chrome 14 or Safari 5.1 on Windows. 
I'm going to try the iPad tomorrow.

And maybe it's a good idea to try to serve some static JSON data 
first instead of generated data to narrow down where the problems 
are.

I think its ok to use append if its not a heavy-loaded web site. 

I did this to prevent possible file access problem if it happens 
same time in very rare cases:

		unless 'ok = loop 3 [
			if not error? try [
				save voter-file append voters session/content/username
			] [
				break/return 'ok
			]
			wait 0:0:0.1
		] [
			response/redirect "error.rsp?code=error-on-voting"
		]

about encap: I'll try to find the problem and if it's not difficult 
I try to fix it as well. I wanted to ask before spending time on 
it. Thank you. Doc: if you already done / test it please let me know. 
I'm planning to use it in a production.

Thank you. I'll try.

What I'm working on is, to poll a database table and send some changes 
to a client on a web socket. polling should not block Cheyenne of 
course.

I'll try again tonight.

I've tried a lot of different hand-crafted request to try to crash 
Cheyenne and reproduce your issue, but Cheyenne is keeping responding 
right.

If you let me know which ones, I'll try them out on my machine .... 
but I won't be able to do so just now.

Thank you for the test, I'll will try to reproduce it here.

but I guess I could try using paths as the function argument... that 
actually might work too.

The plus side is that what you would just do, before you try to optimize, 
tends to be faster in R3 than it is in R2.

we might try the trick - look at the source, maybe the column is 
done by another column separator marker, no? :-)

BrianH: that is not a good solution. If we want a good one, let's 
have it at least in R2 level. If you want the raw one, you HAVE to 
count on the default Windows version. Suggesting ppl to download 
xy MB crap is not the way to go to try REBOL at all ...

From the sidelines, I hope this bears fruit Maxim (and Carl). Very 
cool.


One favour to ask.  Max, if you get hold of our low levels ... be 
gentle ... try and factor some of it down so the 2 dimensional 4 
digit brain types still have a chance to decode some of that whiz 
bang almost too far out of the box stuff I suspect you may have brewing. 
 :)

I second BrianH's opinion - please release to the first limited group 
of Devs, to prevent possible initial chaos. As for me - I think that 
we CAN manage the situation, even if you would release it publicly. 
Not many ppl use R3 Chat do download sources nowadays. I think that 
if you set some coordinator or two, e.g. BrianH, Henrik, Maxim  - 
whoever who will accept the role, then we will be fine and even other 
ppl can study the code and try some things for themselves ...

So, the plan is to try go get the build mechanism setup again for 
the host development method.

Then, I'll probably just drop you a zip of everything for you to 
try it and tell me what problems pop up.

Just giving a little report about a very interesting chat I had with 
Carl:


- Host code package is in the works... given priority.  My impression 
is that Carl is really wanting for this to happen.  If any of you 
feel you can actually participate and do real tests and work, now 
is the time to raise your voice.
 

- Devices and the Extensions dll code are part of the host code. 
  Thus, by extrapolation...  We (i.e. Not Carl) could work on a model 
of Device extensions and propose it to Carl, if anyone (or group) 
wants to put the effort.  obviously using the current Extensions 
as the reference...


- As it stands now, adding Native Datatypes is complex outside of 
the rebol core  (ex: in host code) because of a few issues (GC integration 
being a major one).


- Carl isn't against the idea of finding a way to add Native (binary) 
user datatype but it most probably will have to wait a bit until 
Carl and Host developers find a way to make it simple and bug free. 
 a possible idea is to bave a special extension model which acts 
as a datatype marshaller, with defined commands as datatype actions 
(aka accessors in other languages).


- Talked a little bit about threads, but nothing really specific 
to say about it... I'll need to try it in practice so I can ask relevant 
questions.

I don't like point 2) - I think that Carl knows best, how to add 
integration of Devices, eventual callbacks, images, etc. - simply 
the requested stuff. We (the community) should use extensions, we 
should not try to develop its API.

Seems like there's a newer version, than what I have installed. I'll 
try the newer one...

I try all to keep away from C++ these days. It just gives to much 
hassles when going from one compiler to the next.

I try this

read daytime://time-a.nist.gov

weird !

The open function must not return the tcp port, but the fake daytime 
port.

Because if someone try to thing like this. 
>> port: open daytime://...
then 

>> read port ; ==> the wrong actor is called (not the daytime one).

The windows console in Windows 7 is very odd ... if you maximize 
it , it shifts to the left hand side of the screen.  Try and move 
it and is shrinks back again :(

Graham... did you try the screen? mine works its really cool.

There's many ppl out there, who will want to try REBOL as a tool, 
and have ABSOLUTLY NO intention into coding some infrastructure things 
themselves. So - we can say such things as "do it yourself" in a 
community cooperative manner here, but let's not dare to present 
such opinions publicly ...

well well, let me try it again

you don't even need an account, try if you get to the server rejecting 
your message :)

going to try writing a NOOP

could you try `system/contexts/system/read client` instead

actually, i have something minimal working already, if you want to 
try

so try with: s: open pop3://...

could you try and replace `wait either system/version/4 = 4 [1] [subport]` 
by just `wait 1`

maybe I need to read the number of bytes from the buffer, clear that 
number and try reading again until none

I mean - I was used to get data by using 'read, not 'open .... Open 
just always opened the port, nothing more ... now try following with 
your solution:

print read dns://www.rebol.com

i should make a try, i have some doubts

try /debian/pool/main/x/ instead of /debian/dists/lenny/

let me try that

i'll try that

Uploaded my latest version which by default downloads ubi.exe which 
is a 1.5mb file ( ubuntu windows installer. )
You can uncomment the 650 mb download if you want to try :)

i guess i'll try a local ubuntu mirror

well try it and you may see it ...

ah, i guess i should try with the win32 r3 instead

i'll try :)

try it ..

Small optimization:


Graham, if you try to connect to a host with an ip as a string, then 
a DNS lookup is performed even if it's useless.

On the other side, if you provide an ip as a tuple, no lookup is 
performed and it's a straight connection.


So as an example, when you enter in PASV mode (ftp proto) try this 
instead.

data-address: to-tuple to-block form copy/part tmp 4

we could give a try for real time collaborative work and update the 
code in a shared sheet. There some tools for that