[REBOL] Re: [The Gimp] clashes with REBOL on Windows 2000
Hi Anton, I just ran REBOL/View from my REBOL home directory to test the default install behavior. I was able to rename rebol.exe to another file name (blah.bak) and then write out a random file downloaded from a remote web site to a file named rebol.exe . You don't have to delete the file for this exploit to work. This is a major security hole. And yes, I was on Windows XP. Keep in mind that I was running in the console though. Scripts started from the REBOL desktop are sandboxed in their folders under public, so it's not as bad as it could be. View scripts started from the desktop actually need Pro or Command features to do more than fill your hard drive; with Library support or call enabled all bets are off though. Brian Hawley At 12:18 AM 5/10/04 +1000, you wrote: I just tried opening a copy of my rebol.exe, named rebolblah.exe and within the rebol console to delete %rebolblah.exe. This produces a write access error. As far as I know you can't modify a running executable. That's on WindowsXP. I can't remember if Win9x allows that. Anyone ? Anton. The important thing to remember here is REBOL's sandbox security. We need to prevent ordinary users from having write access to the installed REBOL executable without prompting and the easiest way to do that is to put it in a different directory than their data. This will prevent downloaded scripts from replacing the executable with something nasty. Brian Hawley -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: [The Gimp] clashes with REBOL on Windows 2000
Hello again Ari, At 01:24 PM 5/8/04 +0200, you wrote: Hi Brian and Gregg, if you need volunteers for the REBOL/View install project I'm happy to join. If you're gonna script, I think you should keep a few things in mind: 1. RT delivers stable releases with installer (or can you persuade RT to not ship with an installer???) Better yet, persuade RT to fix theirs, or even better, let us do so. 2. RT delivers beta releases without installer 3. is the installing userid a user with or without admin rights? So far, installing REBOL/View requires at least Power User rights. Perhaps it the installer can bail out for regular users and run as if the --noinstall option was selected - it should do this anyway for security reasons. Of course no such restrictions would have to be followed if the system is running on FAT filesystems, signaling that security isn't a concern. Keep in mind that all Win9x users have admin rights though. 4. should an installation concern all users on a given system or not? As long as the installer is setting up associations for .r file types, it does concern all users on the system. The important thing to remember here is REBOL's sandbox security. We need to prevent ordinary users from having write access to the installed REBOL executable without prompting and the easiest way to do that is to put it in a different directory than their data. This will prevent downloaded scripts from replacing the executable with something nasty. Even on FAT systems and for admin users we should pretend that this distinction exists. Security matters, even on Windows. So, in case 1 one has to install at first the RT way. Only after installing your script comes round the corner and has to: - clean up the mess created by RT installer - do a proper (re)install In case 2 the script could be used right away Yup. That will deal with all problems except those posed by the registry use by the existing RT installer. BTW Brian, AFAIK the default directory where REBOL installs is C:\REBOL\VIEW and not C:\Program Files ;-) So it is. That would be the first thing to fix then. Thanks so much for the effort you are willing to put in this project! Met vriendelijke groet / with kind regards, Arie van Wingerden http://home.zonnet.nl/rebolution/ Of course - this is fun! Brian Hawley -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: [The Gimp] clashes with REBOL on Windows 2000
Hey Gregg, At 07:27 AM 5/7/04 -0600, Gregg wrote: Excellent info Brian, Can we add it to REBOL.org somewhere (with due credit of course)? If people think that would be a good thing, could a couple other people review it as well? Sure, although I'd like to be one of those people. I've had a lot of time to give this problem thought - years, actually. If you want I have more detail on the registry settings from an email I wrote to this list on 16-Aug-2002, and more about directories from a feedback about the subject I sent in Sep-2000. Unfortunately this installation problem is a bit of a pet peeve for me. That's why my emails on the subject have been a bit more impressive (thanks Ari!) than I would like. If I could afford to buy the SDK I would have rewritten the installer years ago and submitted my changes to RT. I have offered to do so before, no charge, but I need the existing installer source first. Thanks! -- Gregg No problem! Brian Hawley -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: [The Gimp] clashes with REBOL on Windows 2000
Sure! Give me an idea of what you have in mind (script, tutorial, essay) and I'll do what I can. I've been writing installer scripts of various forms since the Win 3.1 days and I'd be interested in an excuse to see what changes the last couple of years have brought. Brian Hawley At 03:05 PM 5/7/04 -0600, Gregg wrote: Hi Brian, Thanks very much! It would be really terrific if you could do your review and coordinate a couple other volunteers (anyone willing?) then give us a ping when you think it's ready. I'll also take any input you have as I'm working on an installer project, and I do have the SDK. Thanks again! -- Gregg -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: [The Gimp] clashes with REBOL on Windows 2000
be interested. Good luck, Ari! Brian Hawley At 04:30 PM 5/2/04 +0200, Arie van Wingerden wrote: Hi all, when I tried to install The Gimp on Windows 2000 I found out that there is a clash with REBOL. I've set the environment variable HOME to point to the REBOL/View executable. However, The Gimp seems to take HOME as it's place to write user dependent info and tries to create directories and files at that place. Does anybody know whether there is an alternative name for HOME to point to the REBOL stuff, or to direct The Gimp elsewhere? I already tried to remove HOME temporarily, then letting The Gimp create it's stuff (now in an appropriate user dependent place). When I then start The Gimp later it works fine. However, when I reintroduce HOME, The Gimp gets lost again and wants to use HOME again. Met vriendelijke groet / with kind regards, Arie van Wingerden http://home.zonnet.nl/rebolution/ -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject. -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: Rebol on Pocket PC
At 06:52 PM 8/18/02 +0200, Sisbro wrote: Hi ! Hi yourself! A little problem with rebol on my PocketPC. I can't associate *.r files with the rebol engine. Someone have an idea ? REBOL on WinCE and PocketPC doesn't pay attention to command line parameters, for no discernable reason. Because of this you can't associate files. On another note, you can't use the clipboard in the REBOL console either, like you can on regular Windows. These problems severely limit the usefulness of REBOL on WinCE. Please send feedback about this. I can't be the only one that wants to use REBOL as more than a toy on a WinCE or PocketPC machine. Brian -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes.
[REBOL] Re: Rebol on Pocket PC
At 04:34 PM 8/19/02 +1200, Andrew Martin wrote: Jerome wrote: I use a Casio under Windows CE (MIPS processor).=0D I have realize an association with PocketTweak=0D =0D *.r - \Program Files\rebol\rebol.exe -qs %1 =0D On my Windows XP I've got this association: c:\rebol\view\rebol.exe -qs %1 REBOL on Windows CE doesn't take parameters :( Have you set up the REBOL_HOME environment value? On my machine it has the value: C:\Rebol\Core\ Windows CE doesn't have environment variables. See the General Paranoyaxc - Unix ports page at http://www.rainer-keuchel.de/ for workarounds to this. He uses the registry, a clib wrapper and his own console code, but it works. Not with REBOL though. Brian Hawley -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes.
[REBOL] Re: Printing with Rebol on Windows network
At 08:33 AM 8/21/02 -0500, Louis Turk wrote: Andrew, At 09:19 AM 8/21/2002 +1200, you wrote: ... Note that Windows printers require CR and LF to be sent for the end of line; newline. If you must print directly from Rebol, you'll need to replace/all of the newline values in your text with these values. How are you doing this? write/with %somefile somedata ^M^/ or you could use ^(0D)^(0A), it means the same thing. Brian -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes.
[REBOL] Re: Windows registry keys
\ CurrentVersion\Explorer\Shell Folders in the AppData value. If the user has a license, you can put it in the directory you created too. - Create KEY\Software\Rebol - Create KEY\Software\Rebol\Console - Create KEY\Software\Rebol\View - Under KEY\Software\Rebol\View, create values - HOME : The REBOL version of the AppData REBOL directory you created earlier, such as (on Win2k or above): /C/Documents and Settings/user/Application Data/REBOL/ - Product : The product and version, like View 1.2.8.3.1 without the quotes. - Create a per-user program group and shortcut to the global REBOL program file in C:\Program Files\REBOL or whatever the directory turned out to be. While you're at it you can copy that shortcut to the user's desktop folder, which you can get from KEY\Software\Microsoft\Windows\ CurrentVersion\Explorer\Shell Folders in the Desktop value. Try not to overwrite per-user settings that may already exist, but go ahead and overwrite the global settings. Don't bother using REBOL/View's built in uninstaller as it is not multi-user friendly. If you want to provide a user-accessible uninstaller, go ahead, but just let it remove the per-user registry settings but not the files. If you want an uninstaller to completely clean all of the REBOL settings and program files, it's best to keep it to yourself. I hope this helped. Probably more information than you needed, but if not I'll rig up an Inno Setup script that will generate an installer that behaves as above and post it for you. Brian Hawley -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes.
[REBOL] Re: Listening on a server IP address
At 09:08 AM 8/11/02 +0200, Maarten Koopmans wrote: Console 1: a: open tcp://:9090 b: first a console2: a: open tcp://some-ip-address:9090 console1: if not (b/local-ip = accepting-ip-address) [ close b ] I can't make it better than this Darn. I was afraid of that. That was as far as I got too. I was really hoping to have some way to avoid opening the port at all on adapters I didn't want to use, if only to allow another program to listen to that port. This kind of thing is really important for transparent proxies. Well, I have asked Feedback. If I hear any answer back you all will be the next to know. It may be time for an enhancement request... Brian -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes.
[REBOL] Binding server ports to specific host IPs
Help! My computer has several IP channels available to it: The ethernet card, localhost, and a couple VMware virtual networks. If I am setting up a server, how do I bind a listen port to just one or some of them, not all? I would like to set up local services that I would prefer not to be accessible to the outside world. I haven't found anything like this in the docs - they all seem to assume that all network channels are alike. For that matter, is there some way to set a net-mask or a list of IPs to limit who can connect to my service somewhere in the port settings, rather than manually checking every connection? I'm looking for speed and security here... I will ask feedback too. Unfortunately, the ability bind to only specific network channels (I forget the TCP/IP term) is a must for my project. If I can't, I must switch languages. That would be bad. Thanks for any assistance! Brian Hawley -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes.
[REBOL] Re: REBOL/Core 2.5.3 Released
At 04:32 PM 8/4/02 +0200, Andreas ([EMAIL PROTECTED]) wrote: 'alter in new /core is broken: s: [ 1 2 3 4 5 6 ] == [1 2 3 4 5 6] alter s 4 == [2 3 4 5 6] a quick look at the 'source reveals the problem either temp: find series value [remove series] [append series value] should read either temp: find series value [remove temp] [append series value] [submitted to feedback] I think it should be either temp: find series value [head remove temp] [append series value] for consistent behavior. I submitted my version to feedback as well (alas, before I read your message). By the way, the function is identically broken in /View. Perhaps it was broken all along, but no one wrote code that needed it to work correctly before, just for the trivial case of the item always being in the first position. Brian -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes.
[REBOL] Re: REBOL/Core 2.5.3 Released
At 09:08 PM 8/2/02 -0700, you wrote: A new REBOL/Core has been released for testing purposes. ... Some of the changes include: MAKE-DIR Rewritten New Bitset Functions: CLEAR, LENGTH?, EMPTY? Changes to SKIP Function ARRAYs Initialized with Block Values Added PARSE BREAK Word Fix to OPEN on Network Ports Fixed Crash on Modified Functions Unset Object Variables (on Exit) Added BUILD-MARKUP Function Revised BUILD-TAG Function Revised DECODE-CGI Function and more... Yay to all, but let me add one I noticed (belatedly): TO-REBOL-FILE and TO-LOCAL-FILE are finally there as 2.5.0 said they would be, and they work too! Well, for the most part. TO-LOCAL-FILE still needs to be passed a full file specification, but since you can use CLEAN-PATH to get that I don't have a problem here. That should be documented in the function spec, though. TO-REBOL-FILE even doesn't choke on NTFS file streams except in one case, when the file stream is specified off of a fully relative file name, like this: to-rebol-file blah:hiddenstream == %/blah/Lang/REBOL/Core/hiddenstream when it should be to-rebol-file blah:hiddenstream == %blah:hiddenstream I suspect that the existing behavior might be a carry- over from the Amiga version of TO-REBOL-FILE, but I would be the last person to ask that :) Really, REBOL is going about file stream support wrong. I would like to see NTFS file streams (or forks) use the GET-MODES 'forks interface, just like it is on Mac. I love the forks, type and creator support on Mac - it would be cool to be able to do similarly arcane stuff on Windows as well. On the other hand, perhaps streams are too arcane for REBOL to support directly... I'll look it up on MSDN and see what I can hack up to improve stream support for REBOL, then tell Feedback. And you all, of course. Brian Hawley -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes.
[REBOL] Re: NTFS Stream Fun
At 11:05 AM 8/6/02 +0200, Robert Muench wrote: However, IIRC you can have a lot of streams in a NTFS file. BTW: The stream feature is AFAIK available since NT 3.1 (1994). What you see in a directory listing is the so called default stream. This stream has the form of filename:$DATA Isn't that supposed to be filename::$DATA ? The three fields are: filename:stream:attribute The default stream name is (without the quotes). The default attribute is $DATA. All attributes start with $ . Oh wait, I just remembered that since all attributes start with $, you can skip the stream name if you are just using the default and want to specify the attribute. So I guess that filename:$DATA would work after all :) In other words, BFS completelly smokes NTFS out. :) NTFS is not that bad. I like some features of BFS as well but IMO the NTFS is really a nice thing. I don't remember the title of a book (if you know it let me know it too) that tells the story about the NT development. Very good read! Not very technical, instead it tells about the people and up downs while developing NT. There is a section about the development efforts that went into NTFS etc. Robert The database search capabilities of BFS are where it smokes NTFS. But not for long: Future versions on Windows are slated to have the filesystem built on top of the SQL Server engine, rather than the other way around. When that happens, the smoke will definitely be blowing in the other direction! Brian -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes.
[REBOL] Re: Binding server ports to specific host IPs
At 09:45 AM 8/9/02 -0500, G. Scott Jones wrote: From: Brian Hawley My computer has several IP channels available to it: The ethernet card, localhost, and a couple VMware virtual networks. If I am setting up a server, how do I bind a listen port to just one or some of them, not all? I would like to set up local services that I would prefer not to be accessible to the outside world. I haven't found anything like this in the docs - they all seem to assume that all network channels are alike. ... Hi, Brian, I probably have more questions than answers, because I believe that the best answer will depend on certain information. The implied risk of which I suspect that you are concerned is the risk of external Internet access to your proposed REBOL server. [ Huge amounts of useful information snipped :) ] I thank you for all of this information, but I've already gone through these steps. I do know about networking, I just forget the jargon terms for things :) The third but less desirable option is hooking your REBOL server to the localhost address (127.0.0.1). Actually, that is exactly one of the things that I want to do. Once your development machine is on a non-Internet-routable address, like the 192.168.x.x range, then you can hook your server to a port for listening, as seen at http://www.reboltech.com/library/html/rebserver.html You should be able to specify the actual IP that you wish to use on your machine, like: server-port: open/lines tcp://192.168.0.1:4321 You should, but what you have just done is open a client port. A server port is opened from specs like tcp://:4321 . You are not given the opportunity to specify which of your server IPs to bind to, or if you are I am asking would like to know how. Say I have a 2k machine, with one NIC, running VMware. I would then have 4 IPs for that machine, each on a different subnet. This info is typical for a computer behind a NAT firewall. localhost 127.0.0.1 255.0.0.0 (the NIC) 192.168.123.100 255.255.255.0 (VMware host-only net) 192.168.17.1 255.255.255.0 (VMware internal NAT) 192.168.119.1 255.255.255.0 I would like to use something like this: open/custom tcp://:4321 [ips [128.0.0.1 192.168.17.1]] or perhaps even use the names specified when you get-modes port 'interfaces It should be possible, but I don't know the exact syntax. If your machine is directly addressable to the Internet, but you have a fire wall installed, then in theory you only need to set the firewall to filter out any external access to the desired port. Most internal firewall software restricts on a program basis, not per-script. If you enable a port for one REBOL script you have enabled it for all of them. This is not my problem, though. I just want to set up local servers to handle non-REBOL standard protocols for client programs written in other languages. Seems simple enough to me... At 05:26 PM 8/9/02 +0200, Petr Krenzelok wrote: So once again, port: open tcp://:9005 probe get-modes port 'interfaces ... Is that what you wanted? No. I found that in the docs. What I want is to bind listen ports to only a subset of the IPs available on my machine. Get access hasn't helped me much there, I'm afraid :( Any ideas? Brian Hawley -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes.
[REBOL] Re: NTFS Stream Fun
At 10:34 PM 8/9/02 -0500, Bruno Albuquerque wrote: The database search capabilities of BFS are where it smokes NTFS. But not for long: Future versions on Windows are slated to have the filesystem built on top of the SQL Server engine, rather than the other way around. When that happens, the smoke will definitely be blowing in the other direction! Actually, no. First of all, the first version of BFS was a real database and it was dropped exactly because the performance hit on using a real database as the filesystem is too big (sure system ara faster today than they were in 1990, but this is no reason to make then slower). Second, BeOS has node monitoring capabilities so you always know rigth on the spot if a file that you need (and you're monitoring it) has changed and you can take appropriate action, This all without having to pool for the file (you receive a notification when it changes). Besides, BFS implements the live query mechanism where you are notified when files stop satisfying your query or when new files start to satisfy them. For instance I have a folder called Best Musics that contains all my MP3 files I gave a rating of 10. This folder is *ALWAYS * up to date even if you add and remove files. Strangely enough, all that was exactly what I was referring to when I agreed that BFS smoked NTFS. I just simplified so that I wouldn't get too far off-topic. Thanks for the links, though. I hadn't read _all_ of them ;) As for the future, we'll have to wait for it. I can't remember where I put that set of Yukon and Whistler links, so I can't go into much detail, but there is much to look forward to. We'll have to see what Microsoft can do with the best coders that obscene amounts of money and evil can buy. Maybe they'll surprise us and come up with something anywhere close to what their research papers claim. Brian Hawley -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes.
[REBOL] Re: AW: Core 2.6 - Last minute requests - take your chance!
At 08:29 AM 4/8/02 +0200, you wrote: Rebol/View has two functions, to-rebol-file and to-local-file. Quite useful when you write scripts that get filenames as arguments and are still to be platform independant. Would be nice to see them in Core, too. Yeah it would. Particularly since the /Core 2.5 docs have always said that those natives are already there. I've found those docs frustrating for a year now Brian Hawley -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes.
[REBOL] Re: Core 2.6 - Last minute requests - take your chance!
Well I have a few... (All platforms) - Add the to-rebol-file native that is in /View to /Core, and to-local-file to do the reverse. Make them support relative paths. Add function documentation for them. - Integer division native!, action! or op!, to be more efficient than to-integer (x / y). Is there one now? Would it actually be more efficient? - Actually release /Core/Pro on platforms where /View is absent (like WinCE) or awkward (like Unix w/o X11). I'd buy the WinCE one at least. (Windows) - Make certain the call native (when implemented) never opens a visible console window unless necessary. In particular, call/console should never do so. Neither should a call to a non-console app, nor should it when all forms of I/O are redirected explicitly, like call/input/output/error. The current behavior makes background or scripted use of call awkward. If you really need to open a console, why not a hidden one? (WinCE - Serious suggestions) - Clipboard support in the interface, just like Windows. - Command line support, just like Windows (used by the command shell and file associations in the registry - yes, WinCE has and uses those). - An icon for the REBOL executable, just like Windows. - Make now/precise not ignore the /precise refinement. - Mention in the setup documentation that %user.r needs to go in the root directory on WinCE. Better yet, why not a REBOL_HOME setting in the registry like /View on Windows. WinCE has no env vars or current dir. - Add clipboard:// ports for /Core. WinCE doesn't have /View, but always has a clipboard. (WinCE - Dreams) - /Core/Pro for WinCE (I don't want to learn Perl). - /View for Pocket PC. - Optimize the native code for either speed or size, rather than for neither. Keep in mind that ARM emulates floating point code, so use integers. REBOL on my Jornada 820 is 10 times slower than on my p133 laptop, when almost everything else is comparable. I'm sure that there is more that I could come up with, but that must wait until later. Must sleep :( Brian Hawley (Been busy...) -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes.
[REBOL] Re: REP Path! as Block!
Hi Andrew, That's what a paren! does. The syntax is nicer too. Brian Hawley Andrew Martin wrote: A path! datatype could act in much the same way as a block, except that the contents are executed immediately (instead of at a later date or not at all). A block! datatype is this: [ optional Rebol-Values separated with spaces ] For example: [Test: func [Arg] [print join Arg on end] Test Text] I believe that a path! datatype/value could be like this: optional : Rebol-Value / Rebol-Value / and so on; followed by optional : and be evaluated immediately. For example: Test:/func/[Arg]/[print join Arg on end]/Test/Text The above is a fairly meaningless example, but provides a interesting possibility for the path! data-type. Andrew Martin ICQ: 26227169 http://members.nbci.com/AndrewMartin/ -- -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes. -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes.
[REBOL] Re: Unable to use Switch and Datatypes..
Scott Dunlop wrote: Is this a bug or a feature? The following code, which I would expect to generate 'A word is a word.', outputs 'A word is not always a word.', indicating that word! is not equivalent to word! for the purposes of switch. This also appears to be the case with the string! datatype. The interesting thing is that [word! == word!] returns true. switch/default type? 'aWord [ word! [ print a word is a word.] ] [ print A word is not always a word. ] Thanks in advance for any suggestions people have for working around this, aside from a long chain of Either statements.. It's a feature :) The word word! is just a word until it is evaluated. The block of cases passed to the switch function is not itself evaluated - just the selected value. If you are using literal values as keys this is not a problem, even a speedup. For other values, try this: switch/default type? 'aWord reduce [ word! [ print a word is a word.] ] [ print A word is not always a word. ] That evaluates the case block, changing words to the corresponding values. Note that this creates a new case block every time the expression is evaluated. There are other hacks that can be done to evaluate the block only once, such as using compose, that may or may not be appropriate in your situation. Most of the time it doesn't matter. I hope this helps. Brian Hawley -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes.
[REBOL] Re: Unable to use Switch and Datatypes..
Larry Palmiter wrote: Hi Scott Just a quick tip. This works: switch/default type?/word 'aWord [ word! [ print a word is a word.] ] [ print A word is not always a word. ] You need to have word! be a word in the switch list, not a datatype. -Larry Well, that's much cleaner than my solution :) I never cease to be amazed at the clever little improvements that have been added to REBOL over time. Sometimes it seems like there isn't a day that goes by without one of the work- arounds that I've found over the years becoming obsolete. Bless Feedback, and this list :) Brian Hawley -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes.
[REBOL] Re: read bug? probably not!
Graham Chiu wrote:
I've done some more testing, and here's a test script
at http://www.compkarori.com/cgi-local/testcgi.r
#!/path/to/rebol -cs
REBOL [
Title: testcgi.r
File: %testcgi.r
Date: 3-May-2001
Author: [ Graham Chiu ]
Email: [ [EMAIL PROTECTED] ]
category: 'web
]
if system/options/cgi/request-method = GET [
prin {Content-type: text/html^/^/HTML^/HEAD^/
TITLERebol GET test/TITLE^/BODYserver responds to
GET/BODY^//HTML^/}
quit
]
prin {Content-type: text/html^/^/HTML^/HEAD^/
TITLERebol GET test/TITLE^/BODYNot a GET
request/BODY^//HTML^/}
Now, as you can see, this script just prints a message. It
doesn't actually do anything with the input. However, if
you feed it the same script as I used before, it kills this
script when the url length is greater than 4108 characters
with Server response: HTTP/1.0 400 Bad Request
The webserver is Apache.
Well, that may be an error in Apache. It should return a
414 (Request-URI Too Long). I suppose it's possible that
the excessively long URL got mangled in transit, though.
The HTTP standard warns against relying on URLs longer than
255 characters to work consistently. Something about older
routers, proxies and servers (read, most ones out there) not
being able to handle them. They suggest posting instead.
Brian Hawley
--
To unsubscribe from this list, please send an email to
[EMAIL PROTECTED] with unsubscribe in the
subject, without the quotes.
[REBOL] Re: Regarding /command and -w switch in win2K.
Hi Terry, I rearranged things to show the threads of conversation... Terry Brownell wrote: Brian Hawley wrote: TBrownell wrote: With win2K, if you create a shortcut to reb/command like so... c:\rebol.exe -w The only way to kill it is by rebooting? You can kill a process from the Processes page of the Windows Task Manager. Firstly, there is no process to kill with the -w switch. Sure there is. Processes show up on the Processes page. In WinNT/2k, processes don't show up on the Applications page unless they have a non-hidden window that shows up on the task bar, but they still show up on the Processes page. You can kill them from there with the End Process button. Alas, I don't recall how to kill processes from the command line on NT or 2k, just from Task Manager. Oh well... Is there anyway to have a command script run in the background, call a view script and... Can your task be done with /View/Pro? It would be simpler... Next, View doesn't have a runtime yet, so? It was a reasonable question. I thought you were going to say database support, but I forgot about the runtime. Does your app need database support or are you using the runtime as a cost-saving measure? I'm just curious - we may have the same problems here at my job. As for your problem, perhaps the /Command script can call the /View script through the Windows start command. There may be some combination of the /wait refinement to both the call function and the start command that might work. When the /View program exits, the call will return and the /Command script can continue. If you try this, please tell me if it works... Beyond that, I can only suggest that the /Command script be a server program and the /View script be the client. That's the general approach we use here, at least when we need functions that aren't in /Core, /View, or their /Pro equivalents. Brian Hawley -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes.
[REBOL] Re: Regarding /command and -w switch in win2K.
Hi! TBrownell wrote: With win2K, if you create a shortcut to reb/command like so... c:\rebol.exe -w The only way to kill it is by rebooting? You can kill a process from the Processes page of the Windows Task Manager. Is there anyway to have a command script run in the background, call a view script and... Can your task be done with /View/Pro? It would be simpler... Brian -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes.
[REBOL] Re: Thanks for the warm welcome!
Hi Tom! At 05:45 PM 4/29/01 -0500, you wrote: Thank you all for your welcome and support. I took Carl's advice and studied series for the last few days. It looked like it might be fun to recreate some APL, a math language, just to get something going. So here is my contribution. If you know of a way to tighten up the code, please don't hesitate to let me know. Also the function in APL for summing a vector or array is '+/' but I had trouble defining that as a function, would sure appreciate some suggestions. REBOLs typically give their functions names rather than symbols :) Here's my suggestions, using more natives. If you want the sum or product of empty blocks to be none rather than 0, just leave the word total off the end of the function, letting the foreach be the last expression. REBOL [ Title: Math Functions Author: Tom Schaeper Date: 26-Apr-2001 Version: .5 ] v+: func [ Sum a block of values block1 [block!] Block of numbers passed ][ block1: head block1 total: 0 forall block1 [ total: total + block1/1] return total ] sum: func [ Sum a block of values vec [block!] Block of numbers passed /local total ] [ total: 0 foreach x head vec [total: total + x] total ] v*: func [ Sum a block of values block1 [block!] Block of numbers passed ][ block1: head block1 total: 1 forall block1 [ total: total * block1/1] return total ] product: func [ Generate the product of a block of values vec [block!] Block of numbers passed /local total ] [ total: 0 foreach x head vec [total: total * x] total ] viota: func [ Generate a block of integers from 1 to num num [integer!] Number of entries from 1 to num ][ i: 0 block1: copy [] while [ i num] [ i: i + 1 block1: insert block1 i ] block1: head block1 ] vec-iota: func [ Generate a block of integers from 1 to num num [integer!] Number of entries from 1 to num /local block ] [ ; Preallocate the result block block: make block! num ; Let the repeat native do your calculations repeat x num [block: insert block x] ; The last assignment isn't necessary head block ] These should be somewhat faster. That was fun... Brian Hawley -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes.
[REBOL] Re: Core and stdin
Michal Kracik wrote:
actually, pipe can be used for redirecting REBOL input and output in
Windows. The problem is that Windows does not have the cat command,
If you don't have Cygwin, try the type command.
Better yet, why cat into a pipe at all? Use the operator instead.
...
What surprised me, piping input into REBOL works as well, if output
is also redirected:
C:\REBOL\testecho "Hello REBOL" | rebol -wq --do "print [ {from stdin:}
input ] quit" | more
from stdin: "Hello REBOL"
That never occurred to me! I just tried it and it works. Cool!
Now I can rewrite the workarounds I've made over the years :)
Thanks!
Brian Hawley
--
To unsubscribe from this list, please send an email to
[EMAIL PROTECTED] with "unsubscribe" in the
subject, without the quotes.
[REBOL] Re: Core and stdin
2ker wrote: Is this possible to catch data from stdin with REBOL/Core? (something like: cat file.txt |rebol -w script.r ) Does it require /Command or /View/Pro (shell extension)? It depends on whether you're running Windows or something more Unix-like. On Unix-like systems, I/O redirection is done without difficulties. On Windows the | operator does not work with REBOL, just and . You can do full I/O redirection from within REBOL with the shell functions of /Command and /Pro, but in REBOL syntax. See the docs on the shell functions on the REBOL site, but before you ask: No, you can't use the | operator with /Pro or /Command on Windows either. My advise: Get /Pro and use REBOL scripts as the main glue to call all of the external programs, instead of DOS batch language (useless) or Perl (ugly) :) Brian Hawley -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with "unsubscribe" in the subject, without the quotes.
[REBOL] Embedded REBOL (Re: Population of PDA Users)
bugs. For now I can only hope Carl gets a PDA itch, Me too! Brian Hawley -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with "unsubscribe" in the subject, without the quotes.
[REBOL] Re: Population of PDA Users
Hi all, Geo Massar wrote: I am curious how many PDA users are in the list and what country they live. I, for one, own a EPOC-based PDA (Psion 7) and live in US. I live in Chicago, IL and have an HP Jornada 820. Most of my friends have Palms and Visors, as does my mother. They have more than 60 Jornada 820s at my father's work - he is another REBOL user. Paolo Russo wrote: I'm seriously considering to buy a Jornada just to use /Link on it... You may be out of luck for the moment. /View has yet to be ported to WinCE. There are some architectural factors that make even /Core a bit memory-hungry by standards of WinCE programming languages - these should be resolved before /View would really fly. But then, watch out :) If you want to get a Jornada for REBOL, I would suggest the 720. I like the 820, but you will much appreciate the 720's extra RAM and more updated OS and software. It has the speed of the iPaq (alas, not the flash ROM), but you will really like the increased battery life and keyboard, particularly for programming on the machine. If you really want to buy handhelds for /Link you might consider getting an Agenda VR3 or some other Linux rig. It would be a lot easier for RT to get /Link running on something like that. Not that I don't want you pushing for /View and /Link to run on Jornadas like mine :) Brian Hawley Yes, I'm back :) -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with "unsubscribe" in the subject, without the quotes.
