AltME groups: search
Help · search scripts · search articles · search mailing listresults summary
world | hits |
r4wp | 106 |
r3wp | 1460 |
total: | 1566 |
results window for this page: [start: 1466 end: 1565]
world-name: r3wp
Group: Ann-Reply ... Reply to Announce group [web-public] | ||
nve: 26-Nov-2010 | I invite RobertS on http://www.digicamsoft.com/cgi-bin/rebelBB.cgi?thread=<16Nov201014400973923100> Or send me an email. | |
Group: !AltME ... Discussion about AltME [web-public] | ||
nve: 8-Dec-2010 | Does someone report the presentation bug of long url ? Sorry my english explanation... But let's show an exmple : http://www.digicamsoft.com/cgi-bin/rebelBB.cgi?thread=%3C26Nov2010120307258032100%3E | |
nve: 8-Dec-2010 | The link is working... But it is written correctly in blue with hyperlink only http://www.digicamsoft.com/cgi-bin/rebelBB.cgi?thread=%3C26Nov20101203072 and to the end of url it is in black... | |
Gregg: 7-Mar-2012 | http://www.altme.com/cgi-bin/lookup.cgi?lookup=rebol4 To get the WNS to refresh, the world must be started from the GUI, not via the CLI. | |
Group: Announce ... Announcements only - use Ann-reply to chat [web-public] | ||
nve: 23-Nov-2010 | A call to french reboleur : Nous cherchons a promouvoir REBOL au sein de la communauté developpez.com. Nous sommes donc en quête de bonnes volonté pour écrire des cours/tutoriels, des articles sur REBOL, des critiques des livres, animer un blog, etc... Les bonnes volontés peuvent se déclarer sur : http://www.digicamsoft.com/cgi-bin/rebelBB.cgi?thread=%3C16Nov201014400973923100%3E (we are seeking for french volunteers to promote REBOL on french programing site developpez.com) | |
Group: #Boron ... Open Source REBOL Clone [web-public] | ||
Graham: 23-Jun-2010 | Just wondering what you can do with a clone that has no ports ... can it read and write files? Do cgi ? | |
Kaj: 23-Jun-2010 | Of course, ORCA has been able to read and write files for years, and that's what I use in Syllable. And when it can do that, or just print to standard output, you can also do CGI with it | |
NickA: 23-Jun-2010 | Can I use it for CGI now? | |
NickA: 23-Jun-2010 | There's no 'system, let alone system/options/cgi. Is there any method for retrieving GET or POST data? I'd work agressively at implementing some useful web site applications with Boron if there was even rudimentary CGI support. | |
Kaj: 23-Jun-2010 | Not much is needed for CGI, so I'd guess it's possible. ORCA had a getenv function to get the environment variables and so does Boron, I guess | |
Kaj: 23-Jun-2010 | CGI is not the kind of stuff Karl does, so it may be missing. They're just small things to add, though | |
NickA: 23-Jun-2010 | As it stands, Boron seems reasonably capable of processing strings and lists - I could certainly have a go at writing some useful stuff if CGI were possible. I'll send Karl an email... | |
NickA: 29-Jun-2010 | I've been communicating with Karl about getting Boron CGI working, so I'm sticking with Boron for now :) | |
Group: !REBOL2 Releases ... Discuss 2.x releases [web-public] | ||
Geomol: 30-Nov-2006 | Cyphre, you might wanna see my comments here: http://www.rebol.net/cgi-bin/upnews.r?view=0011#comments Maybe you can give it better meaning, how it should work, than I did!? | |
Henrik: 30-Nov-2006 | cyphre: oh, Carl is talking about a focusing problem, but it would be the same thing: http://www.rebol.net/cgi-bin/blog.r?view=0157 | |
Gabriele: 25-May-2007 | http://www.rebol.net/cgi-bin/rambo.r?id=3259& | |
Graham: 22-Mar-2008 | These were date strings being returned by an IMAP server in the rebelBB.cgi script. And because parse-header-date barfed on this format, it kept returning today's date. | |
Graham: 22-Mar-2008 | http://www.rebol.net/cgi-bin/rambo.r?id=4302& | |
Graham: 23-Mar-2008 | http://www.rebol.net/cgi-bin/upnews.r?view=0008 | |
Carl: 29-Dec-2009 | Testing... >> read https://secure28.inmotionhosting.com/~rebolc5/cgi-bin/order.cgi?cmd=buy&prod=sdk& == {<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> So far, so good. | |
Graham: 29-Dec-2009 | http://www.rebol.net/cgi-bin/rambo.r?id=4205& | |
Graham: 29-Dec-2009 | dunno about anton's report http://www.rebol.net/cgi-bin/rambo.r?id=4245& | |
Graham: 29-Dec-2009 | I posted this report in 2004 http://www.rebol.net/cgi-bin/rambo.r?id=3557& | |
Graham: 29-Dec-2009 | and Maarten also posted the same bug in 2005 http://www.rebol.net/cgi-bin/rambo.r?id=3593& | |
BrianH: 2-Jan-2010 | I put a full list of my changed and added features in the comments here: http://www.rebol.com/cgi-bin/blog.r?view=0447#comments Once someone tells me where to put it I will put that information on the web. | |
Will: 17-Jan-2010 | been looking for 2.7.7 changes, maybe a link to this blog http://www.rebol.com/cgi-bin/blog.r?view=0447 sholuld be put on this page http://www.rebol.com/docs/v2-7.html | |
Graham: 14-Mar-2010 | Just shows how long I've been using rebol for cgi work! | |
BrianH: 25-Mar-2010 | Does anyone have a second opinion on my last comment here? http://www.rebol.com/cgi-bin/blog.r?view=0466#comments | |
BrianH: 26-Mar-2010 | The 2.7.7 R2/Forward stuff is here: http://www.rebol.com/cgi-bin/blog.r?view=0447#comments | |
Graham: 12-Apr-2010 | Free OpenBSD sdk http://www.rebol.com/cgi-bin/blog.r | |
TomBon: 15-Apr-2010 | like this? the cli connector is using the cli component nearly all major databases delivering. the connection is made via rebols call/wait/info/output/error and a simple parse after, for the resultset. I am using this prototype mainly for a q & d connect to mysql/postgresql/monetdb/sqlite. on my list are also connectors for firebird/oracle/greenplum/sybase/ingres/infobright/frontbase and cassandra. pros: 1. very fast for single requests 2. no rewrite of code needed if a new version or protocol is out 3. easy 'data migration' between the db's 4. adding new db's are a matter of hours only (see the cli spec thats all) 5. fast prototyping and testing for new db's 6. robust, never had any trouble with cli's even with bigger resultsets 7. should be perfect also for traditional cgi (the process starting overhead is minimal, execpt you name is facebook) 8. very small footprint (~120 lines for connecting to 4 db's, could be the half) with a nice tcp-server component like rebservice the cli multi connector could be very usefull as a c/s connector. I made a test with 2.000 concurrent calls (simple select) on a 4 gig quadcore. the cpu was only close to 50%, a good value. cons: 1. slow if you have very much serial inserts (unless you shape them into one sql query) 2. need to start a cli process for every request 3. needs a tcp server for non-local connections 4. some more, but who cares ;-) with a solution to keep the cli open from rebservice, these cons could disappear and the speed diff overhead to a memory based lib could be marginal. | |
Graham: 1-Sep-2010 | for 2.7.8, I have submitted this to rambo http://www.rebol.net/cgi-bin/rambo.r?id=-4776& | |
Graham: 2-Sep-2010 | http://www.rebol.net/cgi-bin/rambo.r?id=4400& | |
Sunanda: 26-Sep-2010 | Rambo bug for +13 already exists: http://www.rebol.net/cgi-bin/rambo.r?id=4302& Now all it needs is fixing :) | |
Graham: 26-Sep-2010 | This is an error I posted back in 2003 to the tracker .. http://www.rebol.net/cgi-bin/rambo.r?id=3174& | |
Andreas: 11-Dec-2010 | For R2 bugs we have RAMBO: http://www.rebol.net/cgi-bin/rambo.r | |
Group: !REBOL3 Extensions ... REBOL 3 Extensions discussions [web-public] | ||
Graham: 17-Jul-2010 | As you can see here .. Max took it upon himself to do something about swig R3B0L support http://www.rebol.net/cgi-bin/r3blog.r?view=0231 | |
Gregg: 30-Jul-2010 | Carl, by STDIO, I just mean the basics for writing pipe-and-filter apps. e.g. while [data: input] [print data] I just found http://www.rebol.net/cgi-bin/r3blog.r?view=0282so maybe we're close and just need to write up some examples and a doc page explaining limitations on different OSs. Gabriele has some things in his power-mezz package as well (chain, filter, pipe), which are worth keeping in mind. The blurring of lines between in-process and inter-process, and piping is where we need design direction from above. A REBOL way (passing around blocks of dialected data, i.e., messages) vital, but we also need gateways to other mechanisms. The REBOL way is critical because it reduces or eimilates external dependencies and provides a model for gatewys to emulate. | |
PeterWood: 30-Jul-2010 | Whether Spread would be right for REBOL is another matter though it would offer a limited alternative for secure inter-process communications with non-REBOL processes without having to resort to either cgi or "roll-your-own". | |
Kaj: 26-Jan-2011 | How much time and memory do delayed modules take? In any case, it will be too much on for example CGI scripts | |
BrianH: 26-Jan-2011 | Kaj, you do realize that you won't be able to just load any system library, right? Unless that library has an R3 extension API, it can't be loaded as an extension. And if you can only load R3 extensions anyways, why not name them as R3 extensions? The .so filename suffix isn't even portable to all POSIX platforms. If you want your code to be portable and load filenames, use a portable filename. That is why we have the .rx convention. And we have %rebol.r for anything specific to your personal platform - you don't even have to touch host code. For that matter, CGI scripts could call a R3 interpreter that is in a different directory than the user R3 interpreter so they would use different %rebol.r settings. | |
Group: !REBOL3 GUI ... [web-public] | ||
Graham: 14-Jul-2010 | There really is only once place you need to be concerned about the library size and that's for cgi .. and that doesn't use graphics | |
Robert: 19-Jan-2011 | This is the code: code: view [ title "Opinion Survey" text "Do you want programs to be easy to build?" hpanel 2 [ label "Answer:" hgroup [ radio "Agree" radio "Disagree" radio "Not sure" ] pad check "I'm a programmer." pad check "I am also a REBOL expert." label "Name:" field label "Comment:" area ] hgroup [ button "Submit" submit http://www.rebol.net/cgi/submit.r button "Reset" reset button "Cancel" close ] ] loop 10 [ do code ] print "all code passed - no crashes" halt | |
Group: !REBOL3 ... [web-public] | ||
Graham: 2-Aug-2010 | We've got some prelim docs here on the host kit http://www.rebol.com/r3/docs/concepts/host-kit.html but then we now see documentation in the change logs here http://www.rebol.com/r3/changes.html as well as here http://www.rebol.net/cgi-bin/r3blog.r?view=0324 | |
Graham: 2-Aug-2010 | http://www.rebol.net/cgi-bin/r3blog.r?view=0144 | |
Graham: 20-Aug-2010 | http://www.rebol.com/cgi-bin/blog.r?view=0484#comments Does any one have write access, or is Carl mistaken ? | |
Graham: 20-Aug-2010 | Carl ... http://www.rebol.com/cgi-bin/blog.r?view=0484#comments ... big typo at the top of the page! | |
Andreas: 22-Sep-2010 | Let's use DECODE-CGI as a simple example: currently in R2, you fire up R2 and can use decode-cgi in your code straight away. | |
Andreas: 22-Sep-2010 | In the future in R3, the code itself will be bundled with R3, but if you fire up R3 and type decode-cgi, it won't be available straight away. You'll have to explicitly import the CGI functions with import 'cgi first. | |
Andreas: 22-Sep-2010 | And obviously there are many REBOL scripts which will never need the CGI stuff :) | |
Andreas: 22-Sep-2010 | + all schemes (currently only http is bundled with R3), + all functions which are not yet bundled in R3 but where available in R2 (cgi, html), + modules which might be worth bundling (database?) | |
Andreas: 22-Sep-2010 | In a CGI use case, that is _definitely_ worth it. | |
Gregg: 22-Sep-2010 | It wouldn't help a CGI script, because it would need to import CGI, HTTP, HTTPS, ... ;-) | |
Andreas: 22-Sep-2010 | It would help a CGI script a lot, because it won't have to import 20 network protocols it never uses. But I sure noticed the ;-) at the end :) | |
Gregg: 22-Sep-2010 | Oh to have to complain about the overhead of 20 standard network protocols...<wistful sigh> But I take you're point, if my CGI is called hundreds of times per day, it adds up. ;-) | |
Maxim: 29-Sep-2010 | http://www.rebol.com/cgi-bin/blog.r?view=0489#comments | |
BrianH: 30-Sep-2010 | Pekr, most of the time you will not specify the boot level if you are doing CGI. The default (unspecified) boot level loads the module system and all of the opt-out modules. | |
Pekr: 30-Sep-2010 | All I needed to know in the past is, that for CGI I need fast system, which will not load unnecessary code, e.g. help, etc. Hence I used /base executable. Now: base - initialize only the lower levels. This option is for special purpose testing only because it provides no way to load external code. (No schemes, such as file access, nor load or do functions.) If your host-kit build is crashing on startup, you can use this option to confirm that the exe image is loadable and runable. sys - initialize up to and including the basic runtime lib and sys contexts. This option allows you to run a very "lean" system (minimal memory and boot time) where your code will be supplying all other run-time functions and modules. Provides a basic load function but with very limited special options (no import, needs, versions, or related features.) mods - initialize up to and including lower-level resident modules. In addition to boot-sys, this level adds high-priority resident modules, but not mezz plus (higher level mezzanines). | |
BrianH: 30-Sep-2010 | No, it wouldn't, because there are still a few opt-in modules that are included but not imported by default. For instance, modules that implement conflicting functionality, such as CGI vs. GUI. | |
Pekr: 30-Sep-2010 | This stuff will require very precise documentation and examples, explaining e.g. how user can save some cycles for CGI purposes, yet how he/she can load his own framework (modules) etc. | |
GrahamC: 15-Oct-2010 | result: write http://yourhost.com/cgi-bin/myscript.cgi{Posted data} See http://www.rebol.net/wiki/Scheme:_HTTP | |
Pekr: 20-Oct-2010 | http://www.rebol.net/cgi-bin/r3blog.r?view=0282#comments | |
Pekr: 21-Oct-2010 | http://www.rebol.net/cgi-bin/r3blog.r?view=0282#comments- so those are the problems Carl faced ... | |
Dockimbel: 27-Feb-2011 | In fact, this blocking mezz-level CALL is used in worker process where it's allowed to wait. Right, WaitForSingleObject is the correct way, this CALL was just a quick adaptation of my async version for Cheyenne (I needed to pass environments variables to a child process for CGI support), but I think I'll drop it in next Cheyenne revisions and use a different approach. | |
Geomol: 12-May-2011 | Carl's latest REBOL blog is dated 28-Mar-2011: http://www.rebol.com/cgi-bin/blog.r | |
Geomol: 13-May-2011 | I notice ++ and --, which was discussed here: http://www.rebol.net/cgi-bin/r3blog.r?view=0057#comments Would it be ok to let NEXT and BACK do the job, like this: next: func [series] [ either word? series [ set series system/contexts/lib/next get series ][ system/contexts/lib/next series ] ] Examples of use: >> blk: [a b c] == [a b c] >> next blk == [b c] >> blk == [a b c] >> next 'blk == [b c] >> blk == [b c] | |
Geomol: 26-May-2011 | And http://www.rebol.net/cgi-bin/r3blog.r?view=0341#comments | |
Pekr: 1-Nov-2011 | I would add following "negatives" (depends upon how you look into it): - no /libary extension and easy wrapping of DLLs. There was a bounty started to bring in kind of R2 DLL capabilities using extensions, Max was working on something, but did not deliver. Some ppl claim, that working with extensions is easy enough, much more powerfull, and that in fact R2 /library interface was weak in comparison in capabilities. - weak and underpowered CALL.No /output or /wait parameter IIRC. Carl said, that R2 C code to it was complex, and that the code is eventually awailable for volunteer to bring in to R3. The outcome is - CALL is limited in usage in comparison to what can be easily achieved in R2. - protocols. The only protocol IIRC was available was HTTP, done by Gabriele. It was HTTP 1.1 compatible, but due to some bug (?) it was downgraded to 1.0 version. No proxy support. Other protocols were done by some other ppl, I do remember Graham doing some work here. In regards to protocols, IIRC there was some work done by Kaj, who brought Curl networking extension to R3. - under Windows console is a bit more inconvenient in usage than in R2, we use native Windows console, yet we don't have full console support, so we can't replace the native R3 one by e.g. Console2 or some other version ... - DBAccess - forget R2 protocols available. The rescue is ODBC extension for R3 - CGI - no native CGI support in R3, though it should not be difficult to emulate - Sorting & Unicode - althought we have Unicode strings available, sort is not adapted to that, and the question is, if it can be easily done ... | |
GrahamC: 1-Nov-2011 | I thought Kaj was using R3 for cgi ?? | |
Andreas: 1-Nov-2011 | no native CGI support in R3 True, although that "native" support is barely needed. `get-env` and `system/ports/input` are basically all you need. I am running several R3 CGIs which work just fine. | |
Group: !REBOL3 Host Kit ... [web-public] | ||
Andreas: 4-Nov-2010 | Here;s a direct link: https://connect.apple.com/cgi-bin/WebObjects/MemberSite.woa/wa/getSoftware?bundleID=19907 | |
Group: !REBOL3 Modules ... Get help with R3's module system [web-public] | ||
Andreas: 22-Sep-2010 | So if, for example, DECODE-CGI is in an "optionally included" (which I guess == "delay-loaded") CGI module, DECODE-CGI will be available even if you don't import 'cgi first? | |
BrianH: 31-Oct-2010 | See here for the bug announcement, in the comments to the release announcement: http://www.rebol.net/cgi-bin/r3blog.r?view=0343#comments | |
Group: Core ... Discuss core issues [web-public] | ||
Ladislav: 14-Nov-2010 | http://www.rebol.net/cgi-bin/r3blog.r?view=0090 | |
james_nak: 12-Mar-2011 | I think this is a Graham question. I've been trying to communicate with this video encoder. It uses .xml and .cgi files to talk to it: tmp: http-tools http://192.168.1.62/user/GetTTLStatus.xml[] and this works fine. The problem is with he .cgi files. They aren't POST files but they only return a: http-tools http://192.168.1.62/user/StorageMediaFiles.cgi[] probe a make object! [ HTTP-Response: "<?xml version='1.0' encoding='ISO-8859-1' ?>" Date: none Server: none Last-Modified: none Accept-Ranges: none Content-Encoding: none Content-Type: none Content-Length: none Location: none Expires: none Referer: none Connection: none Set-Cookie: none ] When you place the url in a browser it works as expected. Any ideas on how to get this to work? | |
james_nak: 12-Mar-2011 | Graham, I get an error Error. Target url: http://192.168.1.62/user/StorageMediaFiles.cgi could not be retrieved. Server response: HTTP/1.1 40.... If you know a way to get the full error code, that might help. | |
Dockimbel: 19-Mar-2011 | That's the second native bug I hit today...This morning while searching about an issue in Cheyenne's CGI handling (reported by PeterWood), I found out that the REBOL's CGI output in binary-mode is not working (it stays in string-mode, so corrupts binary data). Is this the correct way to switch the CGI output to binary mode?: set-modes system/ports/output [binary: true] | |
BrianH: 19-Mar-2011 | I thought CGI required WRITE-IO for binary output. | |
Dockimbel: 19-Mar-2011 | I've tested both with INSERT and WRITE-IO, same result. But I've used CALL/OUTPUT on the test CGI script to simulate a call from a webserver. | |
Dockimbel: 19-Mar-2011 | Here's my test script: #!c:\dev\sdk\tools\rebol.exe --cgi REBOL [] print "Content-Type: application/octet-stream^/" port: system/ports/output set-modes port [binary: true] insert port #{0D} | |
Dockimbel: 19-Mar-2011 | I was wondering if it could be related to a CALL issue, but my own CALL.r implementation in Cheyenne shows the same result. So I guess it's definitely an internal CGI handling issue. | |
BrianH: 19-Mar-2011 | I think CGI should set the line ending to crlf so PRINT works right for the header, even on Linux. | |
Andreas: 19-Mar-2011 | $ rebol --cgi --do "print 'foo" | hd 66 6f 6f 0a | |
BrianH: 19-Mar-2011 | Ok, weird. I don't know if this is the case, but IMO the --cgi option should cause the output port to be in text mode and to convert ^/ to crlf, network standard. And then WRITE-IO should not do any conversions, and output in binary mode regardless of the text mode of the output port. | |
Andreas: 19-Mar-2011 | correction to the above: when actually running as cgi, `print rejoin [.. crlf]` seems to work fine | |
Andreas: 19-Mar-2011 | and write-io with 2.7.8 on linux actually running as cgi works fine as well | |
Andreas: 19-Mar-2011 | #!/usr/local/bin/rebol278 --cgi REBOL [] print rejoin ["Content-type: application/octet-stream" crlf] write-io system/ports/output data: #{610d620a63} length? data | |
Dockimbel: 19-Mar-2011 | No conversion issues on linux: rebol --cgi --do "print 'foo p: system/ports/output set-modes p [binary: true] insert p #{0D0A}" | hd 00000000 66 6f 6f 0a 0d 0a | |
Dockimbel: 19-Mar-2011 | Launching the script with CALL on linux (using /Core 2.7.6) shows something interesting at the end :-)) >> s: "" call/output "rebol -c test.cgi" s == 0 >> probe s foo^/^/^M | |
PeterWood: 20-Mar-2011 | I suspect that the problem is more likely to be with 'call than REBOL in CGI mode as REBOL/Services runs as a CGI under Xitami on Windows. The problem does not occur on OS X. | |
Dockimbel: 21-Mar-2011 | I concur, it's a CALL issue and not a --cgi one. I did more tests with my own CALL/OUTPUT implementation and it doesn't show any newline alteration in the binary CGI output. | |
james_nak: 1-Apr-2011 | Again, this might be a Graham question: I'm still working with that video encoder which uses http to communicate. They have a .cgi script which downloads the recorded video file from the internal SD card to the requester. My problem is the content I receive is somehow different than the files which I can download via a browser and of course will not play. I still using your http-tools to GET/POST. My initial thought was that data returned is somehow being translated. Any thoughts? | |
Dockimbel: 11-May-2011 | I use CALL without /show in Cheyenne to start worker processes. Anyway, CALL is quite unreliable in 2.7.8 on Windows as shown by this RAMBO ticket: http://www.rebol.net/cgi-bin/rambo.r?id=4416& | |
Sunanda: 13-May-2011 | Long discussion of R3/local here: http://www.rebol.net/cgi-bin/r3blog.r?view=0341 | |
Henrik: 22-Aug-2011 | http://www.rebol.net/cgi-bin/rambo.r?id=4332& | |
Dockimbel: 22-Aug-2011 | Same issue with FIND on native! values: http://www.rebol.net/cgi-bin/rambo.r?id=4126& | |
Henrik: 17-Dec-2011 | Seems it's already been repported: http://www.rebol.net/cgi-bin/rambo.r?id=4093& | |
Group: !REBOL3 Source Control ... How to manage build process [web-public] | ||
Andreas: 28-Oct-2010 | And from there on, we can have build bots which pick up any new export and build it for their platform. Build results are reported back somewhere (email, static website on the bots which gets aggregated elsewhere, a simple CGI, R3 chat, ...). | |
Group: Red ... Red language group [web-public] | ||
NickA: 29-Mar-2011 | Doc, the Red project has really sparked my hope for future REBOL development. The following discussion is particularly exciting: http://translate.google.com/translate?hl=en&sl=fr&tl=en&u=http%3A%2F%2Fwww.digicamsoft.com%2Fcgi-bin%2FrebelBB.cgi | |
GrahamC: 31-Jan-2012 | eg. system utilities, web apps, cgi scripting, desktop apps ..etc |
1401 / 1566 | 1 | 2 | 3 | 4 | 5 | ... | 12 | 13 | 14 | [15] | 16 |