• Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

AltME groups: search

Help · search scripts · search articles · search mailing list

results summary

worldhits
r4wp106
r3wp1460
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 / 156612345...121314[15] 16