| # | User | Message | Date |
| 2649 | Terry | yeah, Pekr's right. There's no flash there. I suppose the firewall would be an issue for some. | 16-Jun 17:28 |
| 2648 | Pekr | Terry imo wants to use Cheyenne as local web server, and to allow their kommonwealth to run locally cached, or something like that - but still - his technologies are html, css, js, ajax .... | 16-Jun 11:31 |
| 2647 | Pekr | what are you talking about, Oldes? And yes, it has something to do with firewalls. The thing is - noone was talking flash here ;-) | 16-Jun 11:29 |
| 2646 | Oldes | I'm not sure what is Terry doing, but of course you can use Rebol to connect from Flash to services on servers from not allowed domain as with Rebol you can change the request header easily. | 16-Jun 11:05 |
| 2645 | Oldes | Basically it's the part which was showstoper for Rebol plugin - shortly it works in a way, that if you want to connect to some site with Flash, Flash first loads crossdomain.xml file from the target server where must be your domain allowed to access the server domain. If it's not allowed, the Flash do not connects at all. It's a basic prevention of doing Dos attacks from Flash Player. | 16-Jun 11:00 |
| 2644 | Oldes | http://www.adobe.com/devnet/flashplayer/articles/flash_player_9_security.pdf (but it's not related to Cheyenne) | 16-Jun 10:52 |
| 2643 | Oldes | It has nothing to do with Firewalls. | 16-Jun 10:48 |
| 2642 | Oldes | Flash has very strict security. You have to setup it correctly to anable cross-domain functionality. It's not bad if you understand how it works. | 16-Jun 10:47 |
| 2641 | Pekr | Firewall problems? You have to allow listening port ... but - that should not be problem for 99% of users imo ... | 16-Jun 9:06 |
| 2640 | Terry | That's all taking place in the browser, being served up from our server.. and accessing a copy of Cheyenne running locally. No cross-domain issues here :) | 16-Jun 8:25 |
| 2639 | Terry | Here's a little video clip of a prototype in action.. http://kommonwealth.com/video/cheyennewidgetdemo.swf | 16-Jun 8:20 |
| 2638 | Terry | Think we might try using Cheyenne as a personal web server, providing functionality similar to Adobe Air, Google Gears for our product. | 16-Jun 8:05 |
| 2637 | Dockimbel | Thanks for the 'NT-Service? fix, it will be included in the next release. | 14-Jun 12:27 |
| 2636 | Dockimbel | CGI environment is not supposed to be persistent, so there's no other ways than to manually add libs loading code to %CGI.r script. If you're encapping Cheyenne, you can add your libs to %cheyenne.r (and don't forget to LOAD them too). If you need a persistent environment, use RSP instead. | 14-Jun 12:20 |
| 2635 | Oldes | (if I don't want to init them in all cgi scripts) | 13-Jun 14:32 |
| 2634 | Oldes | Let's say I need some functions available for all CGI scripts, where is the best place to init them? | 13-Jun 14:31 |
| 2633 | Oldes | There must be: set 'NT-service? false in misc/os.r in the block where the 'library component is not found. (to be able boot with Rebol/Core) | 13-Jun 10:21 |
| 2632 | Dockimbel | Chris, you should test using http://localhost/show.cgi script it will display all CGI data. 'script-name should give you what you need. | 5-Jun 8:50 |
| 2631 | Chris | I'm back at asking this -- how do I obtain the original request string -- e.g. "/wiki/show/This_Page" within the CGI environment? 'path-info only gives me the translated filename (always '/qm.r' for my app) | 5-Jun 3:35 |
| 2630 | Joe | hi doc, I have a c++ backg. and seen plenty fo 30k+ concurrent but yes for web sites its common to have a hw redirector and multiple servers | 3-Jun 9:42 |
| 2629 | Joe | the yaws vs apache benchmark is more an example on how the erlang service can handle DoS | 3-Jun 9:41 |
| 2628 | Gregg | I like "theorical", it sounds like "the oracle". :-) | 30-May 20:33 |
| 2627 | Dockimbel | theorical => theoretical | 30-May 20:02 |
| 2626 | Dockimbel | Yep, in real world, there's no point accepting more than 10k connection on a single server. You usually hit memory and cpu limits far before reaching that limit. Spreading the load among multiple servers is the way to go. That's why the Yaws vs Apache benchmark sounds so theorical and irrelevant to me. | 30-May 20:01 |
| 2625 | Terry | Handling 64,000+ concurrent clients is a problem I wish I had. | 30-May 18:25 |
| 2624 | Pekr | Sorry, but possible number of theoretical connection numbers is totally stupid reasoning for whatever kind of decision :-) | 30-May 11:29 |
| 2623 | Joe | Pat e wrote:
> Can anyone tell me how can Yaws have almost 80,000 concurrent
> connections, and some "home-made" erlang servers over 110K concurrent
> connections if there are only 64,000 tcp/ip ports? A TCP/IP connection is identified on each host by a (local port, local IP, remote port, remote IP) tuple. Therefore, there can be more than 2^16 connections to a server (even if the server is listening on a fixed port) provided that they are from more than one client. In theory it's also possible to have more than 2^16 connections between a specific pair of hosts provided that they use all of the available port combinations. However, TCP/IP stacks generally do not support reusing local port numbers (when the port is not specified by the client software) by default, so the practical restriction in this case may still be 2^16. -- David Hopwood | 30-May 11:25 |
| 2622 | Joe | not found the paper yet but here is an answer i found on the net | 30-May 11:25 |
| 2621 | Dockimbel | Unless Erlang implements its own TCP/IP stack, he will hit OS limitations, even if, internally, he's able to handle 2^32 connections. Anyway, I'm interested in reading such paper if you find it. | 30-May 6:06 |
| 2620 | Joe | Maarten, yes you can set the secret cookie but if one system is compromised the whole distributed system is. how is that different in other architectures ? | 29-May 23:28 |
| 2619 | Joe | doc, in erlang concurrency is supported in the programming language (i.e. does not use the os mechanisms). I am trying to track down a reference were it explained you could have 2 power 32 connections theoretically | 29-May 23:27 |
| 2618 | Maarten | There is a paper on Philip Wadler's site: http://homepages.inf.ed.ac.uk/wadler/documents/Service%20Architectures.pdf Check footnote 32 on page 21 (chapter 13). That's what stopped us. | 29-May 21:21 |
| 2617 | Dockimbel | In theory, a combination of a client IP and a local port (in the 64k range) could make a unique key allowing to handle more than 64k clients, but I don't think that the big 3 OS are able to exploit such trick in their default configuration. | 29-May 20:24 |
| 2616 | Dockimbel | AFAIK, every client or server connections are taking a port number in the 64K range. Each time a server receives a new connection it assigns a local port number to the client connection. That local port number is in the 64K range because TCP (or UDP) header storage space for source or destination ports are only 16bits each. | 29-May 20:12 |
| 2615 | Joe | Doc, the 64K limit is the limit on the number of server ports but not the number of connections that can be open to a single port like port 80 | 29-May 20:03 |
| 2614 | Joe | Hi Gregg, which is the project you're talking about ? | 28-May 21:51 |
| 2613 | Gregg | A good starting point for doc links is http://www.erlang.org/doc.html . The pros are that it's been around for a long time, it was built to solve a specific type of problem, and has been proven to work for large commercial systems. It also has a nice community it seems. Just as C# and VB.net are capable languages, you really need to know the .NET framework to make things sing. Erlang, by itself, is very capable, but the OTP (Open Telecom Platform) provides a huge amount of value on top of it, if you're building distributed systems. It also has Yaws, Ejabberd, and other things already built that you can leverage. On the downside, it's a very different model that takes some getting used to, though Maarten got up to speed for experimentation very quickly. If you're used to Prolog, that will help. It's also really only good for back end stuff, so we would still be doing front ends in something else, which wasn't the dealbreaker in our case. What turned us away was the security model. It's designed for use in an intranet type (read safe) environment, where access to machines on the cluster is controlled by secret cookie. If your cookie is compromised, they have absolute power over the node, and any nodes it shares that cookie with. http://www.erlang.org/doc/reference_manual/distributed.html#11.7 We decided that, since we would end up building security on top of everything, using something like dialects for control, we were better off sticking with REBOL. There are a number of things out there already to bulid on (LNS, Rugby, Uniserve, BEER), we can really do things the way we want, in a tool we know we like and are comfortable with. And we know its limitations, so there will be fewer surprises. | 23-May 16:00 |
| 2612 | BrianH | Was? That's a new project :) | 23-May 15:25 |
| 2611 | Pekr | Interesting :-) | 23-May 8:03 |
| 2610 | Terry | Never noticed this before.. seems someone was considering using Rebol as the GUI for Erlang http://erlbol.dougedmunds.com/ | 23-May 5:55 |
| 2609 | Graham | Where's the whitepaper? :) | 23-May 1:14 |
| 2608 | Will | Interesting Gregg, could you say more on what pros and cons made you take the decision? | 23-May 1:13 |
| 2607 | Gregg | It is *very* attractive, all the stuff you get basically for free, in the context of building distributed systems. | 23-May 0:08 |
| 2606 | Gregg | Erlang has a lot going for it, but it has its own set of issues as well. Maarten recently spent some time evaluating it quite deeply for me. At this point, we're sticking with REBOL. | 23-May 0:07 |
| 2605 | Dockimbel | Cheyenne, with its mono-thread full async engine, would scale very well on a similar benchmark, probably much better than Apache, but less than Yaws I guess. OTOH, a bench testing raw throughput, would show Apache performing quite better than Cheyenne (maybe 2 or 3 times better). It's hard for interpreted REBOL to compete with compiled C on raw power. I think that it would be possible to reduce this difference to 1.5 with deep optimization in Cheyenne (task scheduled for v1.1 according to my roadmap). R3 should open new perspectives for speed & memory optimizations (threading, clean async kernel, optimized ports, Rebcode, plugins...). | 22-May 21:21 |
| 2604 | Dockimbel | Yep, cooperative multitasking built-in. Maybe we'll get that in R4 ;-) | 22-May 21:02 |
| 2603 | Terry | "Although it is possible to take advantage of multi-core technology by running several applications processes in parallel, the real benefit would be for multi-threaded applications. The challenge then is to change single-threaded or sparsely threaded applications into multi-threaded and also to debug them. Erlang has unique properties for taking advantage of multi-core technology One of the fundamental properties of the Erlang language is built-in support for very light-weight processes, each with its own memory, and using explicit message passing for their communication. Because of this most applications written in Erlang are realized as a number of cooperating Erlang processes representing something in the problem domain of the application, for example active call sessions, connections or transactions. Typically this will result in many thousands of simultaneously executing processes in a heavily loaded application. The parallelism already present in most Erlang applications makes them ideal for taking advantage of multi-core technology, without there being any need to modify them. The only thing needed is an Erlang virtual machine (VM) which works in a multi-threaded way, and that is what we now are releasing in Erlang/OTP R11B." | 22-May 20:54 |
| 2602 | Terry | Im not that familiar with it.. just looked interesting. Amazon uses Erlang for their S3 and SimpleDB products Apaceh uses it for their CouchDB product. | 22-May 20:53 |
| 2601 | Dockimbel | This bench looks a little odd to me. First, how can Yaws supports 80,000 parallel connections when running on a single server (TCP/IP stack limit is at 65535 AFAIK) ? Second, the load is generated by sending request byte per byte with a delay of 10s between each bytes and getting in response a file of 1 byte...This isn't a web server real load test, it just compares the scalability of OS threads vs "soft threads". You don't need a benchmark to know which one scales better on a mono-CPU server, it's obvious. How Erlang handles multi-core CPU ? | 22-May 20:49 |
| 2600 | Terry | Here's a Yaws (Erlang based daemon) vs Apache benchmark.
http://www.sics.se/~joe/apachevsyaws.html Shows Yaws handling 80,000 parallell connections. | 22-May 20:21 |
| 2599 | Terry | It has some features that make it ideal for serving web pages, DB access etc... all the stuff that's right up your alley. | 22-May 20:14 |
| 2598 | Dockimbel | Erlang, no, I just looked at the language specs and a few examples, why ? | 22-May 19:29 |
| 2597 | Terry | Will, I only come here to keep an eye on Doc's developments. And get sucked into the evolution group simply because I can't resist :) But I've actually found post Rebol life to be very productive. | 22-May 19:23 |
| 2596 | Terry | Doc.. have you worked with Erlang? | 22-May 19:21 |
| 2595 | Pekr | It is just that I found Joomla much more user pleasant :-) | 22-May 13:11 |
| 2594 | Will | Pekr, forget joomla, that is bloated stuff, drupal is elegant, has good community and good documentation. I like the cleaning they have done with the database structure in latest version. It looks to me they have so much reduced the code a good php/rebol coder could translate it in a week.. ;-) | 22-May 12:47 |
| 2593 | Pekr | OT: Will, do you find Drupal better than Jumla? I downloaded both, just haven't tried extensively yet .... from what I saw I found Joomla has nice interface :-) | 22-May 12:32 |
| 2592 | Dockimbel | Yep the patch is for non-Windows only. | 22-May 12:24 |
| 2591 | Will | I just installed drupal 6.2 in a snap on Cheyenne, I really love the cleaning they have done on the database structure. If only it was in rebol... | 22-May 12:11 |
| 2590 | Will | btw, belcome back Terry? ;-) | 22-May 12:09 |
| 2589 | Will | the php source patch is needed only for non WIN platform | 22-May 12:07 |
| 2588 | Terry | Is that just for Mac? I was having some problems with PC | 22-May 7:40 |
| 2587 | Will | just in case if you want to have macports php5 support mysql 5.1.x, install this before php5 and php5 will recognise and use it: sudo port install mysql5-devel +server | 21-May 23:39 |
| 2586 | Will | tar -cjf php-5.2.6.tar.bz2 php-5.2.6 should be: sudo tar -cjf php-5.2.6.tar.bz2 php-5.2.6 | 21-May 23:34 |
| 2585 | Will | impressed! 8) I finally gave another try at php support in cheyenne and after patching fastcgi.c as suggested it now works like a charm.
If you are on os x and use macports, here is a way to patch and compile: sudo port install php5 +mysql5 +fastcgi sudo port uninstall php5 cd /opt/local/var/macports/distfiles/php5/ sudo tar -xjf php-5.2.6.tar.bz2 >> run patch below tar -cjf php-5.2.6.tar.bz2 php-5.2.6 sudo port install php5 +mysql5 +fastcgi checksum.skip=yes copy of Dockimbel's patch with path fixed for this example ;---- cut'n paste the following code in REBOL's console ---- patch-php: has [buffer pos][ target: %php-5.2.6/sapi/cgi/fastcgi.c if none? attempt [buffer: read target][ print "unable to find the file to patch!!" exit ] either parse buffer [ thru "int fcgi_accept_request(" to "if (req->fd >= 0) {" pos: to end ][ insert pos "^/^-^-^-^-break;^/^-^-^-^-" write target buffer print "patch applied." ][ print "failed to locate the line to patch!!" ] ] patch-php ;---- end of code ---- | 21-May 23:33 |
| 2584 | Dockimbel | Just as a reminder for those currently using Cheyenne/RSP, you can add the DEBUG keyword in your webapp config section in %httpd.cfg to display a menu with useful debugging info. | 20-May 13:46 |
| 2583 | Dockimbel | Same in RSP : <% either something [ %> normal HTML is here <% ][ %> something else here <% ] %> | 19-May 23:14 |
| 2582 | Dockimbel | Typo fixed, thanks Brian. | 19-May 23:11 |
| 2581 | Graham | or, remap your keyboard%% | 19-May 23:08 |
| 2580 | Graham | remap your keyboard?? | 19-May 23:07 |
| 2579 | Oldes | With PHP I often use code like:
<? if(something) { ?>
normal HTML is here
<? } else { ?>
something else here
<? } ?> Don't you miss some way to do such a conditions? And as I'm now writing RSP I found the RSP's <%%> tag much more difficult to write than PHP's <??> | 19-May 21:59 |
| 2578 | BrianH | On the web site linked above in the Chunk-encoding section: transferts -> transfers | 19-May 19:06 |
| 2577 | Oldes | I see... do-cache uniserve-path/protocols/HTTP.r | 19-May 17:28 |
| 2576 | Oldes | And where I should add protocol? If I used to start the proxy using: uniserve/boot/with/no-loop [services [proxy-http] protocols [http]] | 19-May 17:27 |
| 2575 | Dockimbel | Hard to answer, but as it's propably the most important software component for my company, quite a lot I guess. | 19-May 17:20 |
| 2574 | Terry | How much time will you be spending on Cheyenne Doc? | 19-May 17:17 |
| 2573 | Oldes | I will try it.. thanks. | 19-May 17:17 |
| 2572 | Dockimbel | That way it will work both in source mode and encapped. | 19-May 17:16 |
| 2571 | Dockimbel | 1) Add you service in %UniServe/services/
2) Edit %Cheyenne/cheyenne.r
3) Add in the 'set-cache block inside the %services/ section, the name of your service.
4) In 'do-cheyenne-app function : - find the line "do-cache %HTTPd.r" and add after that : "do-cache %your-service.r" - find the line "control/start/only 'task-master none" and add after that : "control/start/only 'your-service-name none" | 19-May 17:15 |
| 2570 | Oldes | If I have a proxy server made in Uniserve, what is the best way to join it with Cheyenne? | 19-May 17:08 |
| 2569 | Kaj | Cool | 19-May 13:42 |
| 2568 | PeterWood | Excellent. The graphics look really good. | 19-May 1:00 |
| 2567 | Will | looks pretty 8-) | 19-May 0:20 |
| 2566 | Paul | Very nice Doc! | 18-May 17:49 |
| 2565 | Dockimbel | This will be the new official web site for Cheyenne. I still needs some time to migrate all the old stuff, including the blog. | 18-May 17:24 |
| 2564 | Dockimbel | I'm letting the little indian go out : http://cheyenne-server.org ;-) | 18-May 17:23 |
| 2563 | Dockimbel | You're right about mod-alias, it's not completed yet. I found it might be redundant with a rewriting engine, so I left it unfinished until mod-rewrite comes. | 14-May 21:09 |
| 2562 | Dockimbel | Interesting comments, I should maybe move the URL parsing later in the processing pipeline or, instead, provide a hook for modules to be able to rewrite the URL before it is parsed. Anyway, you can change the URL, path, target and ext (+ req/vhost) in any module's phases if needed, but a clean way to do it is preferable. The hard part for making a good rewriting engine is, IMO, to invent a good clear, clean and compact dialect to achieve that...regexp are not really my taste. | 14-May 21:06 |
| 2561 | Oldes | And it looks the Alias is not finished as it looks just for redirects:) | 14-May 16:44 |
| 2560 | Oldes | ok.. found it... BUG: if there is specified other alias type than 'file ot 'path - Cheyenne halts on uncatched error. | 14-May 16:38 |
| 2559 | Oldes | Although now I see I should use mod-alias. But somehow don't know how - only redirect seems to work here. | 14-May 16:25 |
| 2558 | Oldes | I mean path, target and ext. Url should be set here of course so it can be parsed after url-translate. | 14-May 15:55 |
| 2557 | Oldes | Are you sure you want to set url, path, target and ext inside parse-request-line? If you do that, you cannot simply rewrite using mods. | 14-May 15:49 |
| 2556 | Dockimbel | True and there's a small limitation there that I will need to solve in the future versions. | 14-May 12:41 |
| 2555 | Oldes | Bug: it looks that reloading config does not updates databases. | 14-May 9:51 |
| 2554 | Dockimbel | Thanks for the info. | 13-May 18:32 |
| 2553 | BrianH | Fortunately the binary bug only arose during the testing of the R2 version of the new EXTRACT - the old version of EXTRACT never really worked with anything other than blocks anyways. | 13-May 18:05 |
| 2552 | BrianH | The discussions that Paul and I had resulted in some R2 optimizations for EXTRACT, but those optimizations never made it into the 2.7.6 release. The semantic changes that prompted your bug fix originated in the R3 version of EXTRACT that we wrote back in November, and were a result of discussions of the severe limitations and bugs of the old EXTRACT. | 13-May 18:02 |
| 2551 | BrianH | Watch out with EXTRACT: There is a bug in the 2.7.6 version with binary values that was fixed, but the fix never made it into 2.7.6. You can get the working version from DevBase r2-mezz-series #396. | 13-May 17:58 |
| 2550 | PeterWood | I'm pretty sure that Gregg uses Rebol/Services via HTTP & CGI. I believe that he found it slower but more reliable than via TCP. | 13-May 14:16 |
| 2549 | BrianH | It's not used in the current implementation (in DevBase), but I've seen no evidence that it was removed. | 13-May 14:11 |
| 2548 | Dockimbel | Sure, but is it supported in current implementation ? | 13-May 14:05 |
| 2547 | Pekr | rebservices should theoretically work over http, cgi or other layers. We will see ... | 13-May 14:02 |
| 2546 | Dockimbel | I don't know if current rebservices can use HTTP protocol as transport. Rebservices can run in the same process as Cheyenne, but processing rebservices requests may slow down Cheyenne's performances a lot. R3 threading will solve that kind of issue, so we'll see in a few monthes. ;-) | 13-May 14:01 |
| 2545 | Dockimbel | The new RSP framework will borrow ideas from some top Java web frameworks, like XMLc or Wicked. It will follow the MVC design pattern. Currently the View part is almost ready (complete separation of HTML and REBOL code and 100% pure HTML templates). I plan to work soon on the Model part trying to make an abstraction layer similar to the Object-Relationnal mapping solution found in the Java worl like Hibernate. For the Controller part, I didn't yet decided on how it should be, I plan to release only the MV part first. | 13-May 13:56 |
| 2544 | Pekr | RSP? Ah, server pages ... I exchanged it with services protocol? Still do you plan on some remote protocol? Btw - will rebservices work upon cheyenne? It probably should, as it can work upon html? | 13-May 13:52 |
| 2543 | Paul | Great to hear Doc! | 13-May 13:50 |
| 2542 | Dockimbel | Next Cheyenne release will include this bug fix. The next release should be soon because I intend to make some deep internal changes in RSP to support different HTML processing engines (not only the current one with mixed HTML and REBOL code). This shouldn't affect the RSP API or behaviour, just the internal design. So, I plan to make a new release before starting these changes. | 13-May 13:50 |
| 2541 | Paul | Ahh, yeah I think that change came about from discussions that me and BrianH had. | 13-May 13:46 |
| 2540 | Dockimbel | EXTRACT (on pre 2.7.6) was always returning a block! value. | 13-May 13:43 |
| 2539 | Dockimbel | extension-class: context list and replace it with : extension-class: context to-block list | 13-May 13:42 |
| 2538 | Paul | what is the bug in extract? | 13-May 13:42 |
| 2537 | Dockimbel | Hi guys, there's a tiny issue with Cheyenne running on 2.7.6 due to a bug fixed in EXTRACT. To fix it just open %HTTPd.r file and find the following line : | 13-May 13:42 |
| 2536 | btiffin | Quoting Brock. Go Doc Go! | 13-Apr 19:35 |
| 2535 | Dockimbel | with = from | 13-Apr 18:00 |
| 2534 | Dockimbel | Brock: trashing HTML, CSS and javascript, in favor of REBOL *is* the final goal ;-) First step is clean separation with HTML. | 13-Apr 17:58 |
| 2533 | Brock | quoting btiffin, GO DOC GO!! | 13-Apr 17:54 |
| 2532 | Brock | I've been wondering what it would be like to have a rebol version of asp.net. I'd like to see a solution that separates the HTML and the logic as discussed, but also get rid of the css, javascript, xml and other languagues that get in the way of a streamlined solution. | 13-Apr 17:51 |
| 2531 | BrianH | (Sorry, my internet connection died in the middle of the conversation.) | 13-Apr 16:17 |
| 2530 | Dockimbel | I didn't decided yet, but I may use <span> tag for extending the set of HTML standard widgets. | 13-Apr 15:56 |
| 2529 | BrianH | I put in some minor fixes yesterday, but I haven't yet had the chance to really look it over properly. Any advice would be appreciated, especially related to speed, size and security. | 13-Apr 15:55 |
| 2528 | Dockimbel | Nope, no custom tags, just plain HTML/xHTML. | 13-Apr 15:54 |
| 2527 | Dockimbel | Brian, nothing specific, it just looked "too big" last time I've checked the source code which was a year ago. I should have a look in Devbase for the latest version of LNS. | 13-Apr 15:53 |
| 2526 | BrianH | Are you going towards a asp.net style special tags model for the dynamic widgets? | 13-Apr 15:53 |
| 2525 | Dockimbel | HTML templates will be static files and some advanced widgets (like those AJAX-based) may be generated dynamically. | 13-Apr 15:52 |
| 2524 | BrianH | Doc, if you have specific complaints about LNS, please chime in - I am looking over the code now. | 13-Apr 15:51 |
| 2523 | Dockimbel | The new framework will still use HTML for UI but without mixing it with REBOL code. | 13-Apr 15:50 |
| 2522 | amacleod | I've tried to get it up and running (Magic!) but have never got it to work. Apachi always gives me a hard time. Since its CGI based I tried with Cheyenne but again unsuccessful. | 13-Apr 15:47 |
| 2521 | amacleod | Pekr, "not there". You mean just not powerful or useful enough? | 13-Apr 15:45 |
| 2520 | Pekr | Henrik - what he meant was to use some other means of tagging imo. Simply no combination of REBOL and html code. That aproach ala PHP is total crap | 13-Apr 15:43 |
| 2519 | Pekr | Doc - sounds cool! | 13-Apr 15:43 |
| 2518 | Pekr | magic is not there imo | 13-Apr 15:43 |
| 2517 | amacleod | Henrik, I like that idea. Is that what Magic! does somewhat. I know in the docs there seem to be widgets. | 13-Apr 15:41 |
| 2516 | Henrik | hmmm... I'm building a dialect that builds HTML code, in a sense, weeding out the need for HTML code inside the rebol code. is that what "x" does? | 13-Apr 15:37 |
| 2515 | amacleod | "clean and complete separation between HTML and REBOL code" So you are not mixing rebol code with html in one file? (like in RSP) But your building web pages using rebol code alone? Is the server acting like a serverside "plug-In"? Sorry if I sound completley novice. | 13-Apr 15:35 |
| 2514 | Dockimbel | My desire is to integrate the best features found around in other web frameworks, but in the most efficient way (simple, fast and lightweight). | 13-Apr 15:32 |
| 2513 | Dockimbel | I would also like to add AJAX and DB abstraction layer, but I didn't yet decided what approach would fit the best with REBOL. It needs a lot of experimenting first. | 13-Apr 15:27 |
| 2512 | Dockimbel | The main feature has been already exposed above : clean and complete separation between HTML and REBOL code. | 13-Apr 15:23 |
| 2511 | amacleod | What is the advantage of "x" framework? What kind of stuff does it enable us to do? | 13-Apr 13:25 |
| 2510 | Henrik | thanks | 13-Apr 9:36 |
| 2509 | Dockimbel | Just remove .r from this line : bind-extern CGI to [.cgi .r], and .r file will be served as static files. | 13-Apr 9:36 |
| 2508 | Dockimbel | Sure, It's just a matter of configuration in %httpd.cfg file. | 13-Apr 9:34 |
| 2507 | Henrik | i.e. when the user asks for .r files, not when another .rsp page wants to include them | 13-Apr 9:33 |
| 2506 | Henrik | with RSP, would there be an option to only run .rsp files and not .r? if I want to serve .rsp pages and allow downloading of .r scripts? | 13-Apr 9:33 |
| 2505 | Dockimbel | LNS or something similar, definitely. I would like something "lighter" if possible, than RT's LNS focused on speed and security. | 13-Apr 9:32 |
| 2504 | Henrik | dockimbel, I'm using RSP for the forum and it's working great so far. no problems. | 13-Apr 9:30 |
| 2503 | Dockimbel | RSP framework will stay and will be improved. The new framework "X" will be an addition, so you will always have the choice to use whatever framework suits best your needs : CGI, RSP, "X", QM, or FastCGI engines (like PHP). | 13-Apr 9:30 |
| 2502 | Graham | Built in LNS server support? | 13-Apr 9:27 |
| 2501 | Graham | will we have much of a rewrite of existing apps? | 13-Apr 9:26 |
| 2500 | Dockimbel | Btw, just as teaser, Cheyenne will soon have its own dedicated website with documentation and a roadmap for all planned features in future versions..among them, there's a new server-side framework providing 100% separation between HTML and processing code. Petr, you gonna love it ;-) | 13-Apr 9:23 |
| 2499 | Will | but that is mostly ajax, and load is put on the flickr api.. now for something that really use Cheyenne rsp power, check this http://beta.arounder.com/amsterdam/city_tour/van_gogh_museum_01.html click on the "read" tab, there is a little number in gray, that is page generation time, then reload the same page and check again, it use a uniserve/service memcache, also conside that it's on a multilanguage framework 8) | 13-Apr 9:17 |
| 2498 | Will | Thanks 8) | 13-Apr 9:12 |
| 2497 | Dockimbel | That's great ! | 13-Apr 9:02 |
| 2496 | btiffin | Very nice Will. Highlighting that REBOL can do media ... proof in the pudding. | 13-Apr 5:08 |
| 2495 | Will | running on great Cheyenne http://wrapr.org/ | 13-Apr 0:47 |
| 2494 | Rod | Looks good Doc, thanks. | 21-Feb 0:48 |
| 2493 | Dockimbel | RSS links fixed. | 20-Feb 15:28 |
| 2492 | Dockimbel | Thanks, Rod, I'll fix that asap. | 20-Feb 10:19 |
| 2491 | Rod | Doc - think you need to check the Cheyenne blog rss setup, when I subscribed and followed a link it went 404 and pointed to the following. http://softinnov.org/article/0017.html rather than - http://softinnov.org/cheyenne/blog.cgi?view=0017 FYI, Rod. | 20-Feb 4:05 |
| 2490 | Dockimbel | Binaries for latest Cheyenne release available here : http://softinnov.org/cheyenne/blog.cgi?view=0017 | 19-Feb 19:40 |
| 2489 | Pekr | As this group might be followed by our French friends, I have one off-topic request ... if here is anyone from Paris area, I would like him to msg me privately. Our Company is opening subsidiary in Paris area, and I need to find local partner, who would eventually take care of some local IT related duties :-) | 19-Feb 12:07 |
| 2488 | Pekr | go Doc, go! :-) | 19-Feb 12:06 |
| 2487 | Dockimbel | This is a bugfix only release, it fix many bugs, especially the one introduced in the previous release causing an exit from the main event loop. See details in %changelog.txt. | 19-Feb 11:52 |
| 2486 | Dockimbel | Cheyenne release v0.9.18 beta. Download at http://softinnov.org/tmp/cheyenne-r0918.zip | 19-Feb 11:51 |
| 2485 | btiffin | Yep; and some. I have visions of suger plums dancing in my head. REBOL Website bundles. Transient home PC whiteboarding. Kick Cheyenne and dance with a browser, have your friends attach to the ip and then, after the fact close up shop. Zero-conf temporary web hosting, and the apps are pure REBOL scripts. Sweetness abounds. I think up new applications just about everytime I think about Cheyenne now. I was busy when you announced .9.16 so I didn't think deeply enough about it (I woohoo'ed, but thaty was it) It struck me like lightning the other day. I broke with tradition and dropped a note to Carl, I was so excited. GO DOC GO! :) | 19-Feb 2:20 |
| 2484 | Dockimbel | Did you played with the %embed-demo.r sample ? | 18-Feb 20:11 |
| 2483 | btiffin | Go Doc Go! Not a bug note or anything, but I'm becoming very intrigued by the potential of emedded Cheyenne. Go Doc Go! ;) | 18-Feb 19:45 |
| 2482 | Dockimbel | I'm planning a Cheyenne bugfix release tomorrow, if you've found some new bugs to fix, please report them in Cheyenne's bugtracker or post them here. Thanks. | 18-Feb 19:34 |
| 2481 | Dockimbel | Do you launch Cheyenne with root privileges (for <1024 listen ports) ? Use this command line to debug : ./cheyenne -vvv | 7-Feb 20:08 |
| 2480 | Graham | you can set the log to verbose | 7-Feb 18:00 |
| 2479 | Henrik | firewall is inactive | 7-Feb 16:36 |
| 2478 | btiffin | Firewall? non-persistent changes to ip tables can get ya. | 7-Feb 16:35 |
| 2477 | Henrik | also it seems to launch two instances of itself. | 7-Feb 16:10 |
| 2476 | Henrik | After rebooting my OSX machine, Cheyenne doesn't work anymore. I didn't change anything. It starts and runs and launches its task handlers, but there is no access from a webbrowser. Does it create some kind of start up log so I can tell what's wrong? | 7-Feb 16:07 |
| 2475 | DerekR | good luck with the bug-hunting!! | 28-Jan 18:12 |
| 2474 | DerekR | but this _doesn't_ happen when running UniServe 0.9.9 | 28-Jan 18:11 |
| 2473 | DerekR | btw also determined that the URL spaces bug also happens w/ anchor & location "href" and in the address-bar | 28-Jan 17:59 |
| 2472 | DerekR | Doc? -- just filled in a ticket but when I tried to submit I got "Access Denied" ... bzzzzt | 28-Jan 17:57 |
| 2471 | Dockimbel | I've reset the server, it should be ok now. | 28-Jan 17:30 |
| 2470 | DerekR | anyway i'll try checking back later, see if i can get in -- grazie! | 28-Jan 17:19 |
| 2469 | Dockimbel | give me a few minutes to fix that... | 28-Jan 17:19 |
| 2468 | DerekR | almost kafkaesque, that bug ;-) | 28-Jan 17:19 |
| 2467 | Dockimbel | funny bug... I guess that's a regression from last restore after the server's disk crashed... | 28-Jan 17:18 |
| 2466 | DerekR | can't log-in either --> "Error: Account not yet activated" | 28-Jan 17:18 |
| 2465 | DerekR | recursive bug-tracking bug ... | 28-Jan 17:16 |
| 2464 | DerekR | woops -- just attempted to register a new acct w/ yr bugtracker -- got the email confirming, went to the indicated url -- found a bug ;-) --> > RSP Error Trapped< Error Code : 310 Description : script error ! validate-user has no refinement called update Near : [if not validate-user/update request/content [err?: yes]] Where : protected-exec | 28-Jan 17:15 |
| 2463 | DerekR | thx! | 28-Jan 17:10 |
| 2462 | Dockimbel | use : -p 8880 | 28-Jan 17:10 |
| 2461 | DerekR | This is on Windows 2000 | 28-Jan 17:10 |
| 2460 | DerekR | Can the port # be reassigned from the command line | 28-Jan 17:10 |
| 2459 | Dockimbel | Are you on Linux or OSX ? | 28-Jan 17:10 |
| 2458 | DerekR | I had a problem with port 80 at first -- this both in uniserve and cheyenne -- changed the hardcoded port assignment in httpd.r to 8880 and it worked fine | 28-Jan 17:09 |
| 2457 | Dockimbel | Thanks! That's exactly why I've built Cheyenne ;-) I plan to improve it much more in features, speed, easy configuration,... | 28-Jan 17:08 |
| 2456 | DerekR | Great! -- | 28-Jan 17:08 |
| 2455 | Dockimbel | I plan to make a new release this week, only bugfixes. | 28-Jan 17:07 |
| 2454 | DerekR | -- btw wanted to say how delighted I was to find a lightweight, scriptable, no-hassle-to-install, x-platform web server -- many thanks!! | 28-Jan 17:06 |
| 2453 | DerekR | Sure thing Doc! | 28-Jan 17:05 |
| 2452 | Dockimbel | Could you please fill an issue ticket about that in the bugtracker please : http://www.softinnov.org:8000/curecode/project.rsp?id=4 | 28-Jan 17:02 |
| 2451 | DerekR | (uniserve didn't have a problem with this btw) | 28-Jan 17:00 |
| 2450 | DerekR | While you're here -- I noticed that Cheyenne failed to fetch a jpg image that had spaces in its src url -- e.g. "red rock river.jpg" -- and "red%20rock%20river.jpg" didn't help either ... | 28-Jan 16:59 |
| 2449 | Dockimbel | ;-) | 28-Jan 16:58 |
| 2448 | DerekR | Hi Doc / Nenad -- excellent! (Jeez, there's the answer staring me in the face at the top of the window!) | 28-Jan 16:57 |
| 2447 | Dockimbel | Re DerekR: just look above at Henrik's message, it shows the patch to hide the REBOL console when CGI or RSP scripts are processed. | 28-Jan 16:54 |
| 2446 | Dockimbel | Softinnov.org is back online. There's some bad URL requests using not supported HTTP method that sometimes crash Cheyenne. I'm working on a fix for this and will publish it asap. | 28-Jan 16:52 |
| 2445 | DerekR | umm, okay, well maybe this is the right place for a small problem I've encountered with cheyenne / uniserve -- maybe not an issue with the server but me being new to rebol -- btw this is on windows 2000 and happens with both cheyenne and uniserve -- when I go to any cgi or rsp page a new rebol console pops up in front of the browser! Is there anywhere in the uniserve / cheyenne source where I can disable this behavior? | 28-Jan 16:49 |
| 2444 | Paul | not here either. | 28-Jan 14:03 |
| 2443 | Vladimir | http://www.softinnov.org/ is not working? | 28-Jan 13:44 |
| 2442 | DerekR | oops, probably the wrong place ... plz. excuse the noob | 28-Jan 5:27 |
| 2441 | DerekR | hi to Gregg -- thx for the invitation to your world... | 28-Jan 5:11 |
| 2440 | Rod | Doc - that would be too wonderful, us HTML challenged programmer types would be so very happy with such an option! | 3-Jan 1:21 |
| 2439 | amacleod | "Kind of VID dialect that compiles to HTML+CSS+JS." Now, that's what I'm talking about!!! | 2-Jan 0:18 |
| 2438 | Graham | Just like RoR, RSP can use the following <%= %> instead of <% print ... %> | 1-Jan 20:30 |
| 2437 | Henrik | cool | 1-Jan 16:04 |
| 2436 | Dockimbel | It's not on my Todo list, I plan to make a higher level framework for building web applications, where I don't want to mess anymore with HTML or Javascript. Kind of VID dialect that compiles to HTML+CSS+JS. | 1-Jan 15:41 |
| 2435 | Henrik | Doc, are you considering simple HTML templates for .rsp pages, or is that already possible? Such as converting a block of values to a table: <% print html-table read %. %> | 1-Jan 14:13 |
| 2434 | Henrik | great :-) | 1-Jan 11:10 |
| 2433 | Dockimbel | Thanks for the fix, it will be part of the next release. | 1-Jan 11:08 |
| 2432 | Henrik | I think I found the problem in Uniserve: In uni-engine.r, replacing: call join form to-local-file system/options/boot [" -s " cmd] with: call join form to-local-file system/options/boot [" -sq " cmd] quiets it down | 1-Jan 10:52 |
| 2431 | Henrik | Apparently it's not in the main cheyenne.r file, but during a call to a sub system (don't know which yet) that causes this. | 1-Jan 10:21 |
| 2430 | Henrik | Doc, you may want to say system/options/quiet: true I found this in /var/log/system.log on my Mac, when starting Cheyenne using Launchd: Jan 1 11:01:43 Macintosh com.rebol.cheyenne[60072]: / Jan 1 11:01:43: --- last message repeated 1 time --- Jan 1 11:01:43 Macintosh com.rebol.cheyenne[60072]: - Jan 1 11:01:43: --- last message repeated 1 time --- Jan 1 11:01:43 Macintosh com.rebol.cheyenne[60072]: \ Jan 1 11:01:44: --- last message repeated 1 time --- Jan 1 11:01:44 Macintosh com.rebol.cheyenne[60072]: | Jan 1 11:01:44: --- last message repeated 1 time --- Jan 1 11:01:44 Macintosh com.rebol.cheyenne[60072]: / Jan 1 11:01:44: --- last message repeated 1 time --- Jan 1 11:01:44 Macintosh com.rebol.cheyenne[60072]: - Jan 1 11:01:44: --- last message repeated 1 time --- Jan 1 11:01:44 Macintosh com.rebol.cheyenne[60072]: \ Jan 1 11:01:44: --- last message repeated 1 time --- Jan 1 11:01:44 Macintosh com.rebol.cheyenne[60072]: | Jan 1 11:01:44: --- last message repeated 1 time --- Jan 1 11:01:44 Macintosh com.rebol.cheyenne[60072]: / Jan 1 11:01:44: --- last message repeated 1 time --- Jan 1 11:01:44 Macintosh com.rebol.cheyenne[60072]: - Jan 1 11:01:44: --- last message repeated 1 time --- Jan 1 11:01:44 Macintosh com.rebol.cheyenne[60072]: | Jan 1 11:01:44: --- last message repeated 1 time --- Jan 1 11:01:44 Macintosh com.rebol.cheyenne[60072]: / Jan 1 11:01:45: --- last message repeated 1 time --- Jan 1 11:01:45 Macintosh com.rebol.cheyenne[60072]: - Jan 1 11:01:45: --- last message repeated 1 time --- Jan 1 11:01:45 Macintosh com.rebol.cheyenne[60072]: \ Jan 1 11:01:45: --- last message repeated 1 time --- Jan 1 11:01:45 Macintosh com.rebol.cheyenne[60072]: | Jan 1 11:01:45: --- last message repeated 1 time --- Jan 1 11:01:45 Macintosh com.rebol.cheyenne[60072]: / :-) | 1-Jan 10:05 |
| 2429 | Henrik | sounds interesting | 31-Dec 18:51 |
| 2428 | BrianH | Part of the plans for DevBase is to clean the code structure to make it more modular, to make different front ends easier. | 31-Dec 18:05 |
| 2427 | BrianH | A Cheyenne front end could be very useful. Cheyenne could easily use REBOL/Services for login. | 31-Dec 18:01 |
| 2426 | Henrik | I wonder now if cheyenne can use REBOL/Services' account system for login. | 31-Dec 18:00 |
| 2425 | BrianH | secirity -> security | 31-Dec 17:59 |
| 2424 | BrianH | I just changed the secirity model of DevBase to be more fine-grained. It would probably be extensible to cover something like that. | 31-Dec 17:58 |
| 2423 | Henrik | but it has to start at that, so I want to use cheyenne for that :-) | 31-Dec 17:58 |
| 2422 | Henrik | it is much more than just providing links to scripts on a webpage. | 31-Dec 17:57 |
| 2421 | Henrik | but the basic idea is that developers should have an easy way to distribute their programs and users should have an easy way to upgrade their rebol applications. there are some tricks involved to lock it down so only specific users can get specific updates for specific programs. it may be tied into a purchasing system as well. that's where the on-demand encapping comes in. | 31-Dec 17:56 |
| 2420 | Henrik | looking forward to that :-) | 31-Dec 17:54 |
| 2419 | BrianH | Perhaps they will converge. I have big plans for DevBase. | 31-Dec 17:53 |
| 2418 | Henrik | (which I expect will be a year from now at this pace) | 31-Dec 17:48 |
| 2417 | Henrik | I will explain more when it's ready. | 31-Dec 17:44 |
| 2416 | Henrik | in fact I hope I'll be able to use devbase with this. | 31-Dec 17:43 |
| 2415 | Henrik | it's nothing like devbase.(sorry, I said docbase) it's user centric, not developer centric. | 31-Dec 17:43 |
| 2414 | BrianH | Sounds like DevBase. | 31-Dec 17:20 |
| 2413 | Henrik | once they start the program, they can connect to the source server to get updates via REBOL/Services. Delivery by the developer to the source server is meant to be just as simple. | 31-Dec 17:11 |
| 2412 | Henrik | doc: source code service: not like docbase. it's more for control of what versions a user can download, discerning between stable, unstable versions. also delivers a clean upgrade procedure that is easy for the user. one can download scripts, packages of scripts and on-demand encapped executables. it works all inside REBOL/Services, but I need a "virgin" entry, so new users can get their programs through a webbrowser as well. | 31-Dec 17:08 |
| 2411 | Dockimbel | VID based config : it's a planned feature, but I need first to finish the web-based version. The VID version could be done quite easily using the same HTTP API. | 31-Dec 16:39 |
| 2410 | Dockimbel | Sourcecode service ? Sounds interesting :-) | 31-Dec 16:37 |
| 2409 | Henrik | will there be a VID based config UI for it? | 31-Dec 16:12 |
| 2408 | Henrik | looks like I'll finally be replacing my webserv.r script soon with cheyenne, since I need to build something that will communicate with my sourcecode service. :-) looking forward to 1.0. | 31-Dec 16:11 |
| 2407 | Gabriele | it won't work with encap. encap needs to read the .exe to extract the rebol script. there's no way it can do that once you modify it in any way. (eg. even changing the program icon can make it fail. when changing icons, you have to replace it with one of the exact same byte size.) | 23-Dec 8:49 |
| 2406 | Graham | I think I have tried this type of program before with Rebol encapped programs, and they have not worked for me. | 22-Dec 16:52 |
| 2405 | Robert | Very cool link Tom. Never heard about this one. | 22-Dec 13:47 |
| 2404 | TomBon | http://www.molebox.com/ | 22-Dec 12:09 |
| 2403 | Dockimbel | That would be a very handy feature. In R3, with thread and good callback support, the service DLL would be useless, you could do all in API calls from REBOL. | 21-Dec 20:07 |
| 2402 | BrianH | There are times that I wish REBOL had a facility similar to BackOrifice, which dynamically linked to libraries stored in exe resources without having to extract them. The equivalent in REBOL would be to load/library from a binary! value. | 21-Dec 20:01 |
| 2401 | Dockimbel | Yes, it is. | 21-Dec 19:57 |
| 2400 | BrianH | Is the service.dll file encapped then? By this I mean stored in the exe as binary data and written out when necessary. | 21-Dec 19:57 |
| 2399 | Dockimbel | Yes, when asked to run in service mode (-s cmdline switch), Cheyenne.exe write the service.dll file in its working directory and then use load/library. | 21-Dec 19:55 |
| 2398 | BrianH | BTW, I recall that Hamachi includes a -srvany parameter that tells it to ignore logoff messages and just pay attention to shutdown messages. That kind of thing may be doable in REBOL too, with the system port. | 21-Dec 19:55 |
| 2397 | BrianH | That makes much more sense. Does your Cheyenne.exe dynamic-link to the dll? | 21-Dec 19:53 |
| 2396 | Dockimbel | My service DLL spawns a new thread to respond to SCM (Service Control Manager) messages. The main thread is still the one from Cheyenne, if Cheyenne dies, the service dies too. That's an intended feature. The SCM has built-in service automatic restart capabilities, you just need to properly configure that in service's properties. | 21-Dec 19:50 |
| 2395 | BrianH | Do you think you could add keepalive facilities to the service dll, where it could monitor the Cheyenne process and restart it if it shuts down? That could really help - I have admired that facility in recent malware. | 21-Dec 19:43 |
| 2394 | Dockimbel | To be more accurate, it's possible for a service to have an opened window (even if it's not visible) to receive messages, but in this case, I never was able to make it survive a session logoff / logon sequence. In Windows, there's also threads message queues, but REBOL doesn't seem to trigger events from that channel too. If SYSTEM port was able to support that way to communicate, that would be a better way for the DLL to transmit messages from the service manager. | 21-Dec 19:35 |
| 2393 | Dockimbel | service.dll does has a minimal effort to support services. It has only starting and stopping support. Stopping triggers a UDP packet sent to Cheyenne process to notify the shutdown message. That's the only way to communicate with a REBOL process. Windows message cannot pass because it requires a permanent window structure (not possible in service mode). Pipes coud be a solution but they don't trigger events in REBOL wait loop. | 21-Dec 19:24 |
| 2392 | Graham | Yes, he said that he re-released that archive with the source. | 21-Dec 19:07 |
| 2391 | BrianH | The 0.9.17 beta source that I had doesn't have that directory, but upon redownloading the file it does. Thanks tor the heads up. | 21-Dec 19:06 |
| 2390 | Graham | See Cheyenne/service for the C source | 21-Dec 19:03 |
| 2389 | BrianH | I'm a little curious as to what service.dll does. As Dockimbel said, it is currently Cheyenne-specific, and it currently doesn't come with source (that I can find yet), but looking at the calling source it seems that it does not handle all of the service-related functions, just "ServiceLaunch". I wonder if there would be some merit to putting wrappers for the other service functions in that dll, or converting the ServiceLaunch function to REBOL and just doing calls to system standard dlls. Pulling the existing REBOL wrapper functions out into a seperate script and generalizing them would probably be a good idea, at the least. | 21-Dec 18:57 |
| 2388 | BrianH | There will be. It is planned. | 21-Dec 18:34 |
| 2387 | Graham | Maybe we could have service support in R3 as well? | 21-Dec 18:33 |
| 2386 | Graham | not me .. I normally use fire daemon to run rebol scripts as services. | 21-Dec 18:22 |
| 2385 | BrianH | Have you looked into srvany, seen how it interacts with the process it is loading? | 21-Dec 18:18 |
| 2384 | Graham | It's in the latest Cheyenne distro. | 21-Dec 18:18 |
| 2383 | BrianH | If it is solid, I could use such a dll right away. | 21-Dec 18:17 |
| 2382 | Graham | that sounds great. | 21-Dec 18:12 |
| 2381 | Dockimbel | Re service.dll : it could be used to add NT-Service support for any REBOL app. But currently, there's a few hardcoded parameters in the C source, so it would need at least a recompilation to work for another app. I was thinking about packaging this into a simple library...I'll see if can find some time to do that. But, in all cases, it requires at least /Library component. | 21-Dec 17:51 |
| 2380 | Dockimbel | Thanks for the fix :-) | 21-Dec 17:47 |
| 2379 | Graham | "As a remainder, all the Cheyenne source code, including the service.dll source is release under BSD license." => "as a reminder ... " | 21-Dec 17:37 |
| 2378 | Graham | About Service.dll .. is this just for Cheyenne, or is there a general way for all Rebol apps to run as a service? | 21-Dec 17:30 |
| 2377 | Graham | Doc, I've had talks with Carl about this, and i think he's more relaxed about it. But you're probably right, so just leave it enfaced. | 21-Dec 17:27 |
| 2376 | Dockimbel | In the meantime, I have also on my todo list a dedicated web site for Cheyenne. I'll work on that in the next days. | 21-Dec 14:16 |
| 2375 | Dockimbel | I'd really like to have the admin control panel in 1.0. So maybe I'll delay until I'll add, at least minimal, control panel. | 21-Dec 14:14 |
| 2374 | Dockimbel | AddHandler: it's on my Todo list for 1.0 :-) | 21-Dec 14:12 |
| 2373 | Pekr | btw - any chance of AddHandler like directive? | 21-Dec 12:22 |
| 2372 | Pekr | I would not prolong it for much longer :-) If ppl see alpha, they might be scared. If you feel it is solid enough already, I would go for 1.0. | 21-Dec 12:21 |
| 2371 | Pekr | How close do you think you are to 1.0 relese candidates? | 21-Dec 12:20 |
| 2370 | Pekr | aha .. btw - how do I get to admin portal? | 21-Dec 12:20 |
| 2369 | Dockimbel | Conf file is ok too, using the 'listen keyword. You should not change it directly in the source code (the HTTPd.r port-id value is override by the following line in %cheyenne.r : foreach p any [port-id [80]][control/start/only 'HTTPd p] | 21-Dec 12:15 |
| 2368 | Dockimbel | cheyenne -p 8080 | 21-Dec 12:12 |
| 2367 | Dockimbel | you can change the listening port(s) using the command-line : | 21-Dec 12:12 |
| 2366 | Pekr | hmm, I have Apache installed on port 80. So I manually changed httpd.r port setting in the object section but it did not work. So I tried via conf file and now it works. I wonder if directly setting port number should work too? | 21-Dec 12:09 |
| 2365 | Dockimbel | Cheyenne v0.9.17 re-released. Now includes the source code for the %service.dll library. As a remainder, all the Cheyenne source code, including the service.dll source is release under BSD license. | 21-Dec 10:52 |
| 2364 | Dockimbel | The issue with encapping with a /Command binary is that Cheyenne through CGI and RSP expose the REBOL dialect and expose all /Command stuff, for free...IIRC that's forbidden by REBOL license. Did this changed for latest SDK ? | 21-Dec 10:46 |
| 2363 | Graham | Not needed for me, but perhaps encmdface would be better than enface? | 20-Dec 20:48 |
| 2362 | Graham | Great stuff .. and lots of new stuff too! | 20-Dec 20:48 |
| 2361 | Dockimbel | HOW-TO make Cheyenne work with PHP for non-Windows OS The purpose of the following patch is to make FastCGI in PHP work the same on all OSes. 1) If you have PHP v5.2.1 or higher with sources, you can skip 2) & 3) else : 2) Download latest PHP sources from http://www.php.net/downloads.php 3) Untar the archive anywhere yo want 4) Go to PHP install folder 5) Patching PHP source : Open a REBOL console, then : ;---- cut'n paste the following code in REBOL's console ---- patch-php: has [buffer pos][ target: %sapi/cgi/fastcgi.c if none? attempt [buffer: read target][ print "unable to find the file to patch!!" exit ] either parse buffer [ thru "int fcgi_accept_request(" to "if (req->fd >= 0) {" pos: to end ][ insert pos "^/^-^-^-^-break;^/^-^-^-^-" write target buffer print "patch applied." ][ print "failed to locate the line to patch!!" ] ] patch-php ;---- end of code ---- 6) Once the patch is applied : > ./configure --enable-fastcgi > make > sudo make install 7) Check if everything is ok : > php-cgi -h ... you should see a -b option listed meaning you got proper FastCGI support. If it fails (occured on OSX), try with a full path instead : > /usr/local/bin/php-cgi -h 8) Edit Cheyenne's config file (httpd.cfg) to set the correct option in the PHP section. Non-Windows users have to also set the new 'delay option. | 20-Dec 17:56 |
| 2360 | Dockimbel | "...PHP needs to be patched..." | 20-Dec 17:02 |
| 2359 | Dockimbel | For non-Windows users, PHP need to be patch in order to work with Cheyenne. I'll post here a small HOW-TO in a few minutes. | 20-Dec 17:01 |
| 2358 | Dockimbel | For linux users that don't have X11 installed, the released binary won't work unless you install the X11 support libraries. Here's how-to install the required libs without installing a full X11 desktop (Debian/Ubuntu users only) : > apt-get install libx11-6 > apt-get install libxaw7 > apt-get install libstdc++5 > apt-get install libfreetype6 | 20-Dec 17:00 |
| 2357 | Dockimbel | BTW, the binary versions are built using ENFACE, so View subsystem is available (but VID is not included). | 20-Dec 16:55 |
| 2356 | Dockimbel | Test this release well before using it in production. Please report any bugs or issues in the online bugtracker : http://www.softinnov.org:8000/curecode/project.rsp?id=4 | 20-Dec 16:53 |
| 2355 | Dockimbel | For OSX users, if you experience "invalid compressed data" errors, see http://www.rebol.net/cgi-bin/rambo.r?id=4306& | 20-Dec 16:52 |
| 2354 | Dockimbel | Thanks Will ! | 20-Dec 16:51 |
| 2353 | Dockimbel | Cheyenne beta v0.9.17 encapped binaries are also available for testing : Windows: http://softinnov.org/tmp/win/cheyenne.exe Linux: http://softinnov.org/tmp/linux/cheyenne OSX: http://softinnov.org/tmp/osx/cheyenne Remember that Linux and OSX versions require root privileges to listen on ports < 1024. | 20-Dec 16:50 |
| 2352 | Will | As always, great great stuff! Thank you Dock! | 20-Dec 16:50 |
| 2351 | Dockimbel | See the changelog.txt file in the archive for more info. | 20-Dec 16:22 |
| 2350 | Dockimbel | Cheyenne release v0.9.17 beta. Download at http://softinnov.org/tmp/cheyenne-r0917.zip | 20-Dec 16:21 |