[REBOL] Time
I've just ran into a brick wall. Where is the epoc time support in Rebol? i.e. tot: to-time 958465679 == 266240:27:59 is fine sorta, except it's not exactly a localtime() or date() call :) Regards, Deryk
[REBOL] PAM links Re:
[EMAIL PROTECTED] wrote: Hi deryk, The links do not work. Brett. Brett, I tested both links from a couple of my offshore shell accounts and they worked just fine. Regards, Deryk
[REBOL] Re: /View and the Web Re:(2)
- Open Your Mind - Quoting from Tim's message (13-Jun-00 23:11:44). t I am beginning to use core as a CGI workhorse for me (and I t hope Carl continues with it, despite some evidence to t the contrary in this list). I still don't have this sorted out... Do /Core and /View share the same source with, say, just a definition at the top like "#define CORE" to compile one or the other? Or are the differences more profound? Judging on the basis of what little I know, I guess that when /View's ready, it will be a matter of hours before the corresponding /Core comes out... Am I right? One other thing :-(and consider I still have to look at /View for lack of time, so I may not have a global vision)-: If, when it comes out of beta/gamma state, /View is just /Core with a GUI, then /Core is just /View without a GUI, no? So, the way I see it, the only reason to keep /Core is the smaller disk/memory footprint (and maybe a slightly higher speed), something useful for, say, webservers. How am I doing, so far? But, based on the current difference in size of the two executables, I'd *guess* (and I'm not qualified to guess :-) the gain won't be large enough to justify having /Core around any more: just use /View without using its GUI. Am I missing something? Alessandro Pini ([EMAIL PROTECTED]) deep-thought-ultimate-answer: func [] [ wait years-to-seconds 7'500'000 42 ]
[REBOL] PAM links Re:(2)
The links in your message? Oh well. Must be my end. I get 404 - not found message. - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, June 14, 2000 7:41 PM Subject: [REBOL] PAM links Re: [EMAIL PROTECTED] wrote: Hi deryk, The links do not work. Brett. Brett, I tested both links from a couple of my offshore shell accounts and they worked just fine. Regards, Deryk
[REBOL] /View and the Web Re:(4)
[EMAIL PROTECTED] wrote: - Open Your Mind - Quoting from Tim's message (13-Jun-00 23:11:44). t I am beginning to use core as a CGI workhorse for me (and I t hope Carl continues with it, despite some evidence to t the contrary in this list). I still don't have this sorted out... Do /Core and /View share the same source with, say, just a definition at the top like "#define CORE" to compile one or the other? Or are the differences more profound? Judging on the basis of what little I know, I guess that when /View's ready, it will be a matter of hours before the corresponding /Core comes out... Am I right? One other thing :-(and consider I still have to look at /View for lack of time, so I may not have a global vision)-: If, when it comes out of beta/gamma state, /View is just /Core with a GUI, then /Core is just /View without a GUI, no? Yes, you are right So, the way I see it, the only reason to keep /Core is the smaller disk/memory footprint (and maybe a slightly higher speed), something useful for, say, webservers. How am I doing, so far? But, based on the current difference in size of the two executables, I'd *guess* (and I'm not qualified to guess :-) the gain won't be large enough to justify having /Core around any more: just use /View without using its GUI. Am I missing something? Probably a few issues. Some people like /Core :-) Some people were also reporting slower start of /View in comparison to /Core, and as for CGI, it's a strong argument again /Core denial. And then there's also distribution question - I remember times RT claimed REBOL's gonna be spread by emails too, and then there's a difference in size as a factor worth consideration ... Also, according to discussion on beta list, it seems to me more people would still prefer classical aproach - one /Core = kernel thru all REBOL products, and then additional loadable modules (libraries, components, whatever) - /View, /Shell, /ODBC, /Library-access, etc. As with current situation, there is some limitation - we can't combine /View and /Command and /Apache and /Command together. Who's gonna produce all that variants for us? Anyway - REBOL/View's cool. I don't use CGI, I use /Apache module, so I will be satisfied for some time, if someone gives me /Apache with /Command functionality and /Command with /View functionality. One other opinion was - shell access and library calls should become part of /Core, free of charge. On the other hand /ODBC is something RT could let us pay for ... Remember that future can bring us another modules, and then it will not be just 300kb molded into one .exe file :-) Cheers, -pekr- Alessandro Pini ([EMAIL PROTECTED]) deep-thought-ultimate-answer: func [] [ wait years-to-seconds 7'500'000 42 ]
[REBOL] Time Re:
I've just ran into a brick wall.
Where is the epoc time support in Rebol?
It's easy enough to do, Deryk... Here's to epoch time:
--
REBOL[
File: %epoch.r
Author: "Ralph Roberts"
]
date: now
seconds: ((date - 1-1-1970) * 86400) + (date/time/hour * 3600) +
(date/time/minute * 60) + date/time/second
zone: now/zone
zone: zone/hour
zone: zone * 3600
seconds: seconds - zone ; minus a minus gives plus
print seconds
(I just ran the above and got 960987050 for the time period that I'm doing
this message).
And here's how to convert back:
--
REBOL [
Title: "Convert Epoch Time to Date"
Author: "Ralph Roberts"
File: %epoch-to-date.r
Date: 21-Feb-2000
Purpose: {converts UNIX Epoch time (seconds after 1-1-1970)
to current date and time }
Example: {outputs "Epoch date 951142987 is 21-Feb-2000
14:38:52 GMT or 9:38:52 Local" }
]
epoch: 951505087
days: divide epoch 86400
days2: make integer! days
time: (days - days2) * 24
hours: make integer! time
minutes: (time - hours) * 60
minutes2: make integer! minutes
seconds: make integer! (minutes - minutes2) * 60
time2: make time! hours * 60) + minutes2) * 60) + seconds)
prin ["Epoch date" epoch "is" 1-Jan-1970 + days2 time2]
print [" GMT or" time2 + now/zone "Local"]
-
Enjoy!
--Ralph Roberts
author: REBOL/CORE FOR DUMMIES
[REBOL] Time Re:(2)
[EMAIL PROTECTED] wrote: I've just ran into a brick wall. Where is the epoc time support in Rebol? It's easy enough to do, Deryk... Here's to epoch time: Ralph, Danke, you're the man for the day! :) (I still think it should be a normal function in rebol ;)) Regards, Deryk
[REBOL] Re: /View and the Web Re:(4)
- Open Your Mind - Quoting from Petr Krenzelok's message (14-Jun-00 13:53:39). P Some people like /Core :-)/ I'm one of them. (-: P Also, according to discussion on beta list, it seems to me more people would still prefer classical aproach - one /Core = kernel thru all REBOL products, and then additional loadable modules (libraries, components, whatever) - /View, /Shell, /ODBC, /Library-access, etc./ Yeah, count me in! That's the first thing that came to my mind when I first heard about /View: If /Core is the kernel, uhm, core (:-), then /View will be the visual extension. Alessandro Pini ([EMAIL PROTECTED]) "Expand or die!" (95th Rule of Acquisition)
[REBOL] Time Re:(2)
- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, June 14, 2000 1:55 PM
Subject: [REBOL] Time Re:
I've just ran into a brick wall.
Where is the epoc time support in Rebol?
It's easy enough to do, Deryk... Here's to epoch time:
--
REBOL[
File: %epoch.r
Author: "Ralph Roberts"
]
date: now
seconds: ((date - 1-1-1970) * 86400) + (date/time/hour * 3600) +
(date/time/minute * 60) + date/time/second
zone: now/zone
zone: zone/hour
zone: zone * 3600
seconds: seconds - zone ; minus a minus gives plus
print seconds
(I just ran the above and got 960987050 for the time period that I'm doing
this message).
And here's how to convert back:
--
REBOL [
Title: "Convert Epoch Time to Date"
Author: "Ralph Roberts"
File: %epoch-to-date.r
Date: 21-Feb-2000
Purpose: {converts UNIX Epoch time (seconds after 1-1-1970)
to current date and time }
Example: {outputs "Epoch date 951142987 is 21-Feb-2000
14:38:52 GMT or 9:38:52 Local" }
]
epoch: 951505087
days: divide epoch 86400
days2: make integer! days
time: (days - days2) * 24
hours: make integer! time
minutes: (time - hours) * 60
minutes2: make integer! minutes
seconds: make integer! (minutes - minutes2) * 60
time2: make time! hours * 60) + minutes2) * 60) + seconds)
prin ["Epoch date" epoch "is" 1-Jan-1970 + days2 time2]
print [" GMT or" time2 + now/zone "Local"]
-
Enjoy!
--Ralph Roberts
author: REBOL/CORE FOR DUMMIES
[REBOL] An appeal to keep /Core
To all REBOLians, both at HQ and those of us out here in the field:
Upon thinking about Carl's original message and this subject in general for
the past several days, I offer the following two major points as to why
/Core should be kept, both in spirit and in name.
Primus: REBOL/Core is the very foundation of the REBOL concept, i.e. small
footprint, just copy into a directory to install, code runs without
modification on 37 systems (and more soon, we hope). It is universal,
catholic in the original sense of the word, no GUI stuff to slow it down nor
otherwise restrict it from operating everywhere in everyway. And /Core most
immediately meets the call for a simple yet exceptionally powerful scripting
language with the potential of replacing Perl ("REBOL is Perl without the
complication," etc.). /Core properly evangelized will get the attention of
the many millions out there already trying to craft CGI applications. /Core
carries on the great learning tradition of a beginner's interpretive
language like GWBASIC that has started so many programmers and to which
there has not existed a true alternative for over a decade... not until
REBOL/Core. It is a real, easily accessible gateway to the Common Gateway
Interface.
Secondus: From a marketing viewpoint, the name '/Core' is much stronger than
'/View'... What is the 'core?' It is the center, heart, central part, hub,
nucleus, middle, interior, foundation, mainstay, focal point, basis, crux,
meat, substance. It is: REBOL/Core.
So we of the /Core Corps respectfully ask that /Core be retained in spirit
and name or, in the hallowed words of an old Southern mountaineer and
certainly a profitable philosophy, "You dance with them what brung you," and
it is /Core that's currently getting REBOL attention and respect as a
viabable scripting language. /Core will get /View and the others in the
door, but let's not leave it outside.
--Ralph Roberts
author: REBOL/Core for Dummies
[REBOL] CGI Re:(5)
Hello, You mentioned that the scripts runs another script with 'do/args - where does that other script reside? Is it in the same/lower directory, or a higher? The latter script reside in a higher directory. Regards, Rachid -- [EMAIL PROTECTED] http://perso.worldonline.fr/mutant
[REBOL] Epoch (and Epoch-to-date) as a function in REBOL/Core
I've just ran into a brick wall.
Where is the epoc time support in Rebol?
It's easy enough to do, Deryk... Here's to epoch time:
Ralph,
Danke, you're the man for the day! :)
(I still think it should be a normal function in rebol ;))
Sie sind willkommen, Deryk. Ich arbeite schwer, um gute REBOL Spitzen
bereitzustellen.
Now, you say you wish epoch time was a function in REBOL? No problem. Here's
how you can achieve it (this technique, by the way, is in my forthcoming
book, REBOL/CORE FOR DUMMIES).
1) create a REBOL script file in your REBOL directory called %myuser.r and
add the line 'do %myuser.r' in the 'rebol.r' file. You now have a home for
all sorts of handy enhancements to REBOL/Core which get activated every time
REBOL starts.
2) Turn the to epoch script into a function, as so:
epoch: func ["Returns epoch date of now"][
date: now
seconds: ((date - 1-1-1970) * 86400) + (date/time/hour * 3600) +
(date/time/minute * 60) + date/time/second
zone: now/zone
zone: zone/hour
zone: zone * 3600
seconds: seconds - zone ; minus a minus gives plus
]
3) Paste it into your %myuser.r file. Restart REBOL. Now you can use it as
any function function, for example:
help epoch
USAGE:
EPOCH
DESCRIPTION:
Returns epoch date of now
EPOCH is a function value.
print epoch
960993613
print epoch + 10
961093622
4) Okay, now the from epoch conversion function... put it in your %myuser.r
file also:
epoch-to-date: func [{Convert from epoch to date,
example: epoch-to-date 960994210 returns
Epoch date 960994210 is 14-Jun-2000 14:50:10 GMT
or 10:50:10 Local } epoch][
days: divide epoch 86400
days2: make integer! days
time: (days - days2) * 24
hours: make integer! time
minutes: (time - hours) * 60
minutes2: make integer! minutes
seconds: make integer! (minutes - minutes2) * 60
time2: make time! hours * 60) + minutes2) * 60) + seconds)
prin ["Epoch date" epoch "is" 1-Jan-1970 + days2 time2]
print [" GMT or" time2 + now/zone "Local"]
]
5) Reload %myuser.r. Now you can also use the function epoch-to-date. Do it
like this:
help epoch-to-date
USAGE:
EPOCH-TO-DATE epoch
DESCRIPTION:
Convert from epoch to date,
example: epoch-to-date 960994210 returns
Epoch date 960994210 is 14-Jun-2000 14:50:10 GMT
or 10:50:10 Local
EPOCH-TO-DATE is a function value.
ARGUMENTS:
epoch -- (Type: any)
epoch
== 960994724
epoch-to-date 960994724
Epoch date 960994724 is 14-Jun-2000 14:58:43 GMT or 10:58:43 Local
epoch-to-date (epoch + 10)
Epoch date 961094764 is 15-Jun-2000 18:46:04 GMT or 14:46:04 Local
epoch-to-date (divide epoch 100)
Epoch date 9609947.89 is 22-Apr-1970 5:25:47 GMT or 1:25:47 Local
6) Enjoy and support the /Core Corps, shock troops of the great REBOLution.
--Ralph Roberts
[REBOL] An appeal to keep /Core Re:
"I TOTALLY AGREE!!" he said seconding the motion.
Carl and the marketing folks might not realize
that by dropping the "/core concept" they might actually lose
some market share.
I still evangelize others about REBOL by saying
it's the one INTERNET scripting language
you can install in minutes and be productive in
the first three hours.
Baby rebolians need to drink the /core-milk-first,
before they have any teeth.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, June 14, 2000 10:18 AM
To: [EMAIL PROTECTED]
Subject: [REBOL] An appeal to keep /Core
To all REBOLians, both at HQ and those of us out here in the field:
Upon thinking about Carl's original message and this subject in general for
the past several days, I offer the following two major points as to why
/Core should be kept, both in spirit and in name.
Primus: REBOL/Core is the very foundation of the REBOL concept, i.e. small
footprint, just copy into a directory to install, code runs without
modification on 37 systems (and more soon, we hope). It is universal,
catholic in the original sense of the word, no GUI stuff to slow it down nor
otherwise restrict it from operating everywhere in everyway. And /Core most
immediately meets the call for a simple yet exceptionally powerful scripting
language with the potential of replacing Perl ("REBOL is Perl without the
complication," etc.). /Core properly evangelized will get the attention of
the many millions out there already trying to craft CGI applications. /Core
carries on the great learning tradition of a beginner's interpretive
language like GWBASIC that has started so many programmers and to which
there has not existed a true alternative for over a decade... not until
REBOL/Core. It is a real, easily accessible gateway to the Common Gateway
Interface.
Secondus: From a marketing viewpoint, the name '/Core' is much stronger than
'/View'... What is the 'core?' It is the center, heart, central part, hub,
nucleus, middle, interior, foundation, mainstay, focal point, basis, crux,
meat, substance. It is: REBOL/Core.
So we of the /Core Corps respectfully ask that /Core be retained in spirit
and name or, in the hallowed words of an old Southern mountaineer and
certainly a profitable philosophy, "You dance with them what brung you," and
it is /Core that's currently getting REBOL attention and respect as a
viabable scripting language. /Core will get /View and the others in the
door, but let's not leave it outside.
--Ralph Roberts
author: REBOL/Core for Dummies
[REBOL] Time Re:(3)
(I just ran the above and got 960987050 for the time period that I'm doing this message). That would be 14-Jun-2000 12:50:49 GMT or 8:50:49 Local... I would guess you are up early in the Mountain time zone? or Pacific with daylight savings? --Ralph
[REBOL] An appeal to keep /Core Re:
[EMAIL PROTECTED] wrote: To all REBOLians, both at HQ and those of us out here in the field: Upon thinking about Carl's original message and this subject in general for the past several days, I offer the following two major points as to why /Core should be kept, both in spirit and in name. --Ralph Roberts author: REBOL/Core for Dummies yeah right, what is a book about language without language :-) sorry, I can't stop my self karol
[REBOL] CGI Re:
Thank you for your help, everyone. This is how far I've got until now : Apparently, file access is working normally only in the first cgi script launched by Apache, all its child processes (subsequent calls of scripts, whether they reside in cgi-bin or elsewhere) have problems to access the local file system. Can someone help me with the following : Consider this : print exists %. In other words, does the current directory exists ? (which has to be always true). However, when this line is called from a CGI script (it's not part of the CGI script itself, but part of a rebol script called with "do/args" from the CGI script), it produces "false". I'm running Apache. daniel -- [EMAIL PROTECTED] http://perso.worldonline.fr/mutant -- [EMAIL PROTECTED] http://perso.worldonline.fr/mutant
[REBOL] Re: New VID scroller styles... Re:
Hello [EMAIL PROTECTED]! On 13-Giu-00, you wrote: P Hey, Gabriele, cool. Use 'across at the beginnig of your P examples please, as all that variants of scrollers don't fit P 800x600 resolution. Well, those "..." where there for some reason. :-) P Gabriele, would it be possible to get scroller which will P react upon mouse relese, so not in real-time? I saw it P implemented in some apps, and it could help us on slower P systems - so drag the scroller, release the mouse button, do P the event ... Yup, I just forgot to implement it (I remember you asking for it...). Perhaps tomorrow... Regards, Gabriele. -- Gabriele Santilli [EMAIL PROTECTED] - Amigan - REBOL programmer Amiga Group Italia sez. L'Aquila -- http://www.amyresource.it/AGI/
[REBOL] Pekr scroller...
REBOL [] ; this isn't tested, so take it as an example only. :-) ; you can download the new version here do http://web.tiscalinet.it/rebol/scroller-styles.r view layout [ styles scrollers style pekr-scroller scroller options [no drag events] across s1: scroller 200x17 [t1/text: form s1/current show t1] t1: text "000" return s2: pekr-scroller 200x17 [t2/text: form s2/current show t2] t2: text "000" ] ; enjoy!
[REBOL] CGI and /view
Hello all, On my setup (NT and Apache), I only succeeded to use /Core for CGI. Not /View. In my rebol headers, #!c:/rebol/rebol.exe -cs would work. #!c:/rebol/view/rebol.exe -cs won't work. After executing the script from my web browser, it just waits indefinetely... -- [EMAIL PROTECTED] http://perso.worldonline.fr/mutant
[REBOL] An appeal to keep /Core Re:
[Charset iso-8859-1 unsupported, filtering to ASCII...]
To all REBOLians, both at HQ and those of us out here in the field:
Upon thinking about Carl's original message and this subject in general for
the past several days, I offer the following two major points as to why
/Core should be kept, both in spirit and in name.
Primus: REBOL/Core is the very foundation of the REBOL concept, i.e. small
footprint, just copy into a directory to install, code runs without
modification on 37 systems (and more soon, we hope). It is universal,
catholic in the original sense of the word, no GUI stuff to slow it down nor
otherwise restrict it from operating everywhere in everyway. And /Core most
immediately meets the call for a simple yet exceptionally powerful scripting
language with the potential of replacing Perl ("REBOL is Perl without the
complication," etc.). /Core properly evangelized will get the attention of
the many millions out there already trying to craft CGI applications. /Core
carries on the great learning tradition of a beginner's interpretive
language like GWBASIC that has started so many programmers and to which
there has not existed a true alternative for over a decade... not until
REBOL/Core. It is a real, easily accessible gateway to the Common Gateway
Interface.
Secondus: From a marketing viewpoint, the name '/Core' is much stronger than
'/View'... What is the 'core?' It is the center, heart, central part, hub,
nucleus, middle, interior, foundation, mainstay, focal point, basis, crux,
meat, substance. It is: REBOL/Core.
If it's a choice between /Core and /View, then /View wins. But you bring up
good points. If /View supplants /Core, changing the name to /Core may be
worth RT's time to consider. For the reasons you point out it is in some
sense is more "attention getting."
So we of the /Core Corps respectfully ask that /Core be retained in spirit
and name or, in the hallowed words of an old Southern mountaineer and
certainly a profitable philosophy, "You dance with them what brung you," and
it is /Core that's currently getting REBOL attention and respect as a
viabable scripting language. /Core will get /View and the others in the
door, but let's not leave it outside.
--Ralph Roberts
author: REBOL/Core for Dummies
--Alan
[EMAIL PROTECTED]
[REBOL] CGI Re:(2)
Howdy, Daniel: Thank you for your help, everyone. This is how far I've got until now : Apparently, file access is working normally only in the first cgi script launchedby Apache, all itschild processes (subsequent calls of scripts, whether they reside in cgi-bin or elsewhere) have problems to access the local file system. That's an odd one. We'll have a closer look at that one when we can (cgi with apache for windows, right?), but unfortunately don't have a decent answer for why you're seeing that behavior right now. Is having your cgi-bin script reading and writing files outside of cgi-bin what you want to accomplish? Perhaps you could have a separate rebol process running living in the directory that you want to write files in that talks through ports to the cgi-bin program. This background REBOL process could do the writing and reading of files on the cgi-bin script's behalf. -jeff
[REBOL] No longer dangerous (use of) Secure Re:
if I understood you correctly, you are asking what happens, if the untrusted script were: untrusted: [ security: [file allow] get: func [/any][ do %bad-stuff.r ] ] let's try it with a more comfortable/debugged secure-do (sent to [EMAIL PROTECTED]): Howdy, Ladislav: Had a look at what you put there-- really neato. It's great to see that some of the finer higher level aspects of REBOL, the context dependent nature of REBOL (the R.E.B. in REB-ol), are being so well absorbed by people such as yourself. I think the way contexts work is one of the neatest things since sliced bread! At some point there will be more built in support for protected execution environments. Can't say when-- scheduling and development priorities are a complicated thing. :) -jeff
[REBOL] An appeal to keep /Core Re:(2)
[EMAIL PROTECTED] wrote: To all REBOLians, both at HQ and those of us out here in the field: Upon thinking about Carl's original message and this subject in general for the past several days, I offer the following two major points as to why /Core should be kept, both in spirit and in name. --Ralph Roberts author: REBOL/Core for Dummies yeah right, what is a book about language without language :-) sorry, I can't stop my self karol No problem, Karolg. I've already been quite well paid for the book and I'll not lose in any case. I believe the book will sell just as well as a general REBOL reference whether /Core is still there or not (my working title was simply REBOL FOR DUMMIES, it was later changed, but I wrote the book as an overall instead of specific to /Core guide). My books over the years have already made me very comfortable financially, so I'll keep putting bread and new computers on the table, come what might. I'm more concerned with seeing REBOL, the language, succeed. It is something--the concept of Carl and others--that I passionately believe in. In over 30 years, of using and writing about computers I've not seen anything else with its sheer potential. REBOL is an ideal whose time has come. As Charles Fort wrote about railroading, when it's time for railroading, someone will invent trains. As to something that can REALLY run on the tracks of the Internet, that someone was Carl Sassenrath. Remember, we had rails for centuries before we had trains powered by other than humans and donkeys. Luckily Carl did not make us wait that long. It's just my opinion, and that of many others so it seems, that /Core oughta stay around. This does not mean that we do not want /View or /Command or any of the others (we do, we do!)... It just means that /Core is the perfect entry level point for REBOL and we hope that ever-so-easy-to-open portal remains in place. --Ralph
[REBOL] REBOL and the unix shell Re:(2)
Thank you kindly, Larry, for your encouraging words. Hopefully I will get out more such articles soon. They're an after hours thing, ya know. The grand picture is for a variety of domain specific articles which discuss particular specific applications of REBOL. The next one in the works is all about the ins and outs of REBOL bots-- stuff you gotta do to filter mail, running via .forwards, exporting to unix mail format, etc. I've got a number of other topics but I won't go into them now because that's the cart in front of the horse. Another goal is to provide both an html and a view version of the articles, generated from the same source files. Right now I've got a little parser that generates the html for the articles based on a very minimally tagged plain text file. It won't be too much work to get it to spit out view source at the same time, but once I got the html to spit out more or less the way I wanted I moved on to writing the articles. Can always add the view support latter. My real hope is that if I get a bunch of these articles together, other people would be interested in contributing some domain specific articles of their own to the collection. REBOL is used for a universe of tasks, and various people out there know the complete ins and outs of doing a particular task with REBOL. IMHO, their specialized REBOL knowledge should be recorded and shared with the rest of the community. -jeff Hi Jeff Very nice! I reallylike short command utilities like these. -Larry - Original Message - From: [EMAIL PROTECTED] Say folks: I put up an article I wrote this weekend on using REBOL with the unix shell. It's a part of some other domain specificREBOL materials I've been assembling. Have a look and please feel free to send me any feedback you have. http://www.cs.unm.edu/~whip/rebol-unix-shell.html -jeff
[REBOL] An appeal to keep /Core Re:(2)
If it's a choice between /Core and /View, then /View wins. But you bring up good points. If /View supplants /Core, changing the name to /Core may be worth RT's time to consider. For the reasons you point out it is in some sense is more "attention getting." --Alan [EMAIL PROTECTED] I could live with, Alan... Just so long as /Core stays lean and mean, the more features it has, the better. --Ralph
[REBOL] An appeal to keep /Core Re:(3)
One of the things that always amazes people is how powerful /Core is despite how small the binary is. I think /Core needs to stay around because we will be looking to put messaging language into smaller and smaller devices and time goes by. Put /Core on a watch or in a medical device which swims in the bloodstream and sends messages back to a computer via wireless. Keep /Core around, for sure, and work to make it SMALLER for gosh sakes. It's just my opinion, and that of many others so it seems, that /Core oughta stay around. This does not mean that we do not want /View or /Command or any of the others (we do, we do!)... It just means that /Core is the perfect entry level point for REBOL and we hope that ever-so-easy-to-open portal remains in place.
[REBOL] oops, I have the answer to my own question, I guess!
somefunc: func [ 'param [word!] ][ ; do stuff with param ] Well, it turns out that instead of the awkward expression like do reduce [:somefunc someword] I can simply use this: somefunc :someword I had never used the : with anything but the word for a function, not a word for another word. It gets the value without evaluating it further, and for some reason reduce by itself doesn't do that: somefunc reduce someword Oh, I see! The word 'reduce is itself being passed without evaluation! Wild !!! -galt Thanks to any of you who are busily composing the answer to my last question!
[REBOL] REBOL and the unix shell Re:(3)
Hey, combine these articles with the script library, online documentation, news headlines, links, discussion board, a REBOL store (hey, who doesn't want a t-shirt, anyway?) and an open-source project area and you have a very cool resource. 8-) My real hope is that if I get a bunch of these articles together, other people would be interested in contributing some domain specific articles of their own to the collection. REBOL is used for a universe of tasks, and various people out there know the complete ins and outs of doing a particular task with REBOL. IMHO, their specialized REBOL knowledge should be recorded and shared with the rest of the community.
[REBOL] An appeal to keep /Core Re:(3)
Here's my $0.02... how about *1* distribution (a.k.a. "Core") with other features such as view, DB connectivity, etc. being separately installable "packages" that are dynamically but explicitly loaded / used by the single distribution / interpreter to extend functionality? Otherwise, we'll end up in the unenviable situation of i.e. Tcl circa the early 90s, where every new, interesting extension essentially required its own version / build of the interpreter, and the community fragmented... jb [EMAIL PROTECTED] wrote: If it's a choice between /Core and /View, then /View wins. But you bring up good points. If /View supplants /Core, changing the name to /Core may be worth RT's time to consider. For the reasons you point out it is in some sense is more "attention getting." --Alan [EMAIL PROTECTED] I could live with, Alan... Just so long as /Core stays lean and mean, the more features it has, the better. --Ralph
[REBOL] list values and series operations ... Re:(3)
[EMAIL PROTECTED] wrote: List!s are actually stored differently from blocks, paths and hashes, so any operation on them requires special code that has not been implemented for all action types. - jim Maybe the list also uses slightly less storage overhead per element? Lists use more storage per element than blocks. I would assume that hashes use more storage than blocks as well, but I don't know how they compare to lists. I think that parens use the same storage method as blocks. This is just in my experience, but I would be interested in to know if I'm right about this. Jim? Brian Hawley
[REBOL] An appeal to keep /Core Re:(4)
[EMAIL PROTECTED] wrote: Here's my $0.02... how about *1* distribution (a.k.a. "Core") with other features such as view, DB connectivity, etc. being separately installable "packages" that are dynamically but explicitly loaded / used by the single distribution / interpreter to extend functionality? Otherwise, we'll end up in the unenviable situation of i.e. Tcl circa the early 90s, where every new, interesting extension essentially required its own version / build of the interpreter, and the community fragmented... Very valid point imho . -pekr- jb [EMAIL PROTECTED] wrote: If it's a choice between /Core and /View, then /View wins. But you bring up good points. If /View supplants /Core, changing the name to /Core may be worth RT's time to consider. For the reasons you point out it is in some sense is more "attention getting." --Alan [EMAIL PROTECTED] I could live with, Alan... Just so long as /Core stays lean and mean, the more features it has, the better. --Ralph
[REBOL] CGI Re:(3)
- Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, June 15, 2000 3:45 AM Subject: [REBOL] CGI Re:(2) Howdy, Daniel: Thank you for your help, everyone. This is how far I've got until now : Apparently, file access is working normally only in the first cgi script launchedby Apache, all itschild processes (subsequent calls of scripts, whether they reside in cgi-bin or elsewhere) have problems to access the local file system. That's an odd one. We'll have a closer look at that one when we can (cgi with apache for windows, right?), but unfortunately don't have a decent answer for why you're seeing that behavior right now. Is having your cgi-bin script reading and writing files outside of cgi-bin what you want to accomplish? Perhaps you could have a separate rebol process running living in the directory that you want to write files in that talks through ports to the cgi-bin program. This background REBOL process could do the writing and reading of files on the cgi-bin script's behalf. -jeff Hey Jeff, This might be related to the do/args "string" bug I found, feedback #3246. Cheers, Allen K
[REBOL] Re: Parsing command line arguments
- Open Your Mind - Quoting from Jeff's message (13-Jun-00 22:15:09). jOddly enough, I just wrote a little article on using REBOL jfor shell scripts: j j http://www.cs.unm.edu/~whip/rebol-unix-shell.html Nice. Just one observation: dlink's not going to work on pages containing anchors like a name="I_am_so_bastard_I_come_before_the_href_attribute" href="HAL9000.r" which are not as rare as one may think. Alessandro Pini ([EMAIL PROTECTED]) "First thing we have to do is run a complete biospectral analysis on an asymptomatic individual." "Loosely translated, that means he needs a volunteer." (Bashir J. Dax)
[REBOL] list values and series operations ... Re:(5)
This may help in understanding the allocation/insertion times: A hash preallocates a chunk of memory (into 'bins'). When you insert an item, a special value (hash value) is calculated for the item to determine which bin to place it in. This is all done for fast access when dealing with large numbers of items. A list typically doesn't preallocate memory but allocates only when inserting a new item. At least this is true of the hashes and lists that I've written in C++. HTH, Rodney Snell -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 14, 2000 3:15 PM To: [EMAIL PROTECTED] Subject: [REBOL] Re: list values and series operations ... Re:(3) Hello [EMAIL PROTECTED], I did some testing on REBOL/2.2.0.1.1 (Amiga) and here's the results: I allocated a block!, a list! and a hash! of 1024 * 1024 elements, each in a fresh instance of REBOL and noted free memory before and after allocation (all numbers in bytes). block!: 55962072 - 39184656 = 16777416 list!: 55959904 - 30789760 = 25170144 hash!: 55927968 - 39176256 = 16751712 that'll be 16 bytes pr element for blocks and hashes, and 25 bytes for list. Also note that inserting into the hash! seemed to use extra memory (about 1.5 byte/element, but I guess it might depend somewhat on the data?), while inserting into the two other didn't (inserting integer!s). I guess these numbers would be somewhat bigger on 64bit architectures... (twice the memory requeired for pointers). One thing that really surprised me, is that while allocating the block! and hash! took long time enough to notice, list! allocation was instant. Best regards Thomas Jensen On 14-Jun-00, [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: List!s are actually stored differently from blocks, paths and hashes, so any operation on them requires special code that has not been implemented for all action types. - jim Maybe the list also uses slightly less storage overhead per element? Lists use more storage per element than blocks. I would assume that hashes use more storage than blocks as well, but I don't know how they compare to lists. I think that parens use the same storage method as blocks. This is just in my experience, but I would be interested in to know if I'm right about this. Jim? Brian Hawley
[REBOL] Re: list values and series operations ... Re:(3)
Correcting myself, On 14-Jun-00, [EMAIL PROTECTED] wrote: --snip-- block!: 55962072 - 39184656 = 16777416 list!: 55959904 - 30789760 = 25170144 hash!: 55927968 - 39176256 = 16751712 that'll be 16 bytes pr element for blocks and hashes, and 25 bytes for list. --snip-- 24 bytes for lists that is - a bit too quick there :-) /Thomas
[REBOL] parsing questions - newbie Re:(2)
Hi Keith, well i've looked at the parse section and can't quite figure it out... how do you nominate that you want the parse function to take place on a text file say "aeros.txt" rather than a string? The parse function works on a string or on a block. If you want to parse a file read the file into a string like this file-as-string: read %aeros.txt or maybe (on windows) file-as-string: read %/c/autoexec.bat If you want to parse a web based page you can do this web-page-as-string: read http://www.abc.net.au/news Then you can parse file-as-string parse-rules or parse web-page-as-string parse-rules etc.. and how do you specify it's location? Refer to the user manual for the word READ and for accessing files. and how would you strip off just what's after the colon and discard what is before the colon? your-string: "FORM: Popular Recording" parse your-string [ SKIP THRU ":" COPY text [ TO newline | TO END ] (print text) ] when you parse files, can it be done on a folder of files? i have a stack of html files that i need to extract all text in a particular section and then change the table cells to tabs etc but i have a few to do and would like to run the script over the whole lot at once if possible. Use a loop. See the manual on looping. i can see no reference to how you parse files locally..there are only examples of web addresses or specifying a string. The input data to parse must be a series! type. This series! can be either a string! or a block!. So if you can make your data into a string or a block you can use parse. thanks for your help No Prob. Brett.
[REBOL] An appeal to keep /Core Re:(4)
I think this is a good point. As REBOL grows in capability and application areas, it will be necessary to consider such issues as scalability. A /Core with the ability to add predefined facilities easily would be one approach. My concern would be that REBOL might end up with problems similar to what I experienced with FORTH, where I experienced problems going from an embedded language to a full development environment. The fact that the name space was flat and there was no real modular way to control the expansion caused problems. As an example, REBOL modules seem to want to reside in a single home directory. Perl uses a mechanism where module naming structure and directory structure are parallel. This mechanism evolved to meet the problem of managing a growing body of standard modules - it wasn't gratuitous. While REBOL supports the idea of category, and REBOL-Org structures their library based on it, it doesn't seem to be a formal mechanism. (I admit that I haven't found any discussion of the category word and its use.) FWIW, Garold (Gary) L. Johnson DYNAMIC Alternatives [EMAIL PROTECTED] 562 802 1639 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] One of the things that always amazes people is how powerful /Core is despite how small the binary is. I think /Core needs to stay around because we will be looking to put messaging language into smaller and smaller devices and time goes by. Put /Core on a watch or in a medical device which swims in the bloodstream and sends messages back to a computer via wireless. Keep /Core around, for sure, and work to make it SMALLER for gosh sakes. It's just my opinion, and that of many others so it seems, that /Core oughta stay around. This does not mean that we do not want /View or /Command or any of the others (we do, we do!)... It just means that /Core is the perfect entry level point for REBOL and we hope that ever-so-easy-to-open portal remains in place.
[REBOL] parsing questions - newbie Re:(2)
Hi Keith,
you wrote:
hi elan
well i've looked at the parse section and can't quite figure it out...
how do you nominate that you want the parse function to take place on a
text file say "aeros.txt" rather than a string?
parse read %aeros.txt rules some-parse-rule
and how do you specify it's location?
%aeros.txt ;- file aeros.txt is located in current directory
%/c/windows/temp/aeros.txt
;- aeros.txt is located on drive C: in directory
;- \Windows\Temp\
and how would you strip off just what's after the colon and discard what is
before the colon?
It depends on which version of REBOL you are using. I'll go with REBOL/Core
here.
I am assuming that newline is your delimeter for a record. The
CMLISTPTRACKS: entry is wrapped over several lines in my email client. But
for this item I also assume that the original data consists of one long line.
The following script creates a parse rule, reads the aero.txt file and
applies the rule to the file.
It generates the following output in the REBOL console: (This output is
tripple wrapped: by the REBOL console, by my email client, by your email
client. The actual string contains no newlines.)
do %parse-question.r
Script: "Untitled" (none)
INFINITE POSSIBILITIES AMEL LARRIEUX 4948792 9399700067507 C9921
21 SMA 19/06/20
00 GET UP,I N I,SWEET MISERY,SEARCHIN' FOR MY SOUL,EVEN IF,INFINITE
POSSIBILITES,SHINE,DOWN,WEA
THER,MAKE ME WHOLE,GET UP (THREAD HAD FUN MAIN MI,GET UP (MV MIG MIX
(RADIO))15.91 Compact
Disc
Here's the script:
REBOL [
file: %parse-question.r
]
result: {}
words: [
"CPTITLE:"
"CPARTIST:"
"CMCATNUMBER:"
"CMAPN:"
"CMARIAPRICECODE:"
"CMARIAMEDIACODE:"
"CMARIADISTRIBUTORCODE:"
"DMRELEASE:"
"CMLISTPTRACKS:"
"CURMPRICE:"
"CMTYPE:"
]
parse-sub-rule: []
foreach word words [
insert tail parse-sub-rule :word
insert tail parse-sub-rule [copy info to newline (append result join info
tab)|
]
]
insert tail parse-sub-rule [
skip
]
parse-rule: compose/deep [some [(parse-sub-rule)]]
parse-file: read %aero.txt
parse parse-file parse-rule
print result
when you parse files, can it be done on a folder of files?
foreach parse file load %/c/folder/of/files/ [
clear result
parse parse-file parse-rule
print result
]
i have a stack of html files that i need to extract all text in a
particular section and then change the table cells to tabs etc but i have a
few to do and would like to run the script over the whole lot at once if
possible.
This sounds like a different task?
i can see no reference to how you parse files locally..there are only
examples of web addresses or specifying a string.
See the examples above.
thanks for your help
keith
hi all
i am new to scripting (rebol and python) and was wondering if it was
capable of doing to the following and if so..how?
the following is an example of what i need to strip and turn into a tab
delimited file..
the entries are from a music database that is updated weekly..it is in
lotus notes so i export from there and it dumps this file out with the new
titles for the coming week (here the 19th June)
i only need to get the rows with the double astericks at the start (i put
those in for this post, they are not there in the normal file) and then
strip the words at the start and then put a tab in between them so i can
bring it into excel for the sales team to look at i would need a
first
row to describe each column also maybe something like
Title tab Artist tab Cat no tab APN etc etc
the tracklisting is a little more complicated as it has multiple tracks
within the row..they are seperated by commas
i think that it won't be that hard but i had no success in perl so i
thought i might try rebol or python...
thanks in advance
keith
FORM: Popular Recording
CMTYPESWITCH: Popular
RELOCORIGINAL: 55864A2603AC94ACCA2568F200224388
CMCOUNTRY_ORIGIN:
CMGENRE_CODE:
**CPTITLE: INFINITE POSSIBILITIES
**CPARTIST: AMEL LARRIEUX
CPOARTISTS:
**CMCATNUMBER: 4948792
**CMAPN: 9399700067507
**CMARIAPRICECODE: C9921
**CMARIAMEDIACODE: 21
**CMARIADISTRIBUTORCODE: SMA
CMARIAPACKAGECODE:
**DMRELEASE: 19/06/2000
cMDateFormat: 19/06/2000 12:00:00 AM
DMDELETE:
cMDeleteStatus: No
**CMLISTPTRACKS: GET UP,I N I,SWEET MISERY,SEARCHIN' FOR MY SOUL,EVEN
IF,INFINITE POSSIBILITES,SHINE,DOWN,WEATHER,MAKE ME WHOLE,GET UP (THREAD
HAD FUN MAIN MI,GET UP (MV MIG MIX (RADIO))
CMLISTPARTISTS: ,,,
RELOCMEDIA: F73C80183A01A8D7CA2568F2002A5517
**CURMPRICE: 15.91
**CMTYPE: Compact Disc
CMRECORDCOMPANY: SONY MUSIC
CMPACKAGE:
CMARIADISTRIBUTORHOUSECODE:
cDistributorHouse:
CMLOCALE: Y
$UpdatedBy: CN=PPT/OU=AEROS/O=JUKEBOX
$Revisions: 02/06/2000 05:42:22 PM,02/06/2000 05:42:22 PM
;- Elan [ : - ) ]
;- Elan [ : - ) ]
[REBOL] Errata: parsing questions - newbie Re:
Hi Keith, small error. Should be: foreach file load %/c/folder/of/files/ [ clear result parse-file: read file parse parse-file parse-rule print result ] ;- Elan [ : - ) ]
[REBOL] parsing questions - newbie Re:(3)
hi elan thank you thank you!! just a couple of questionscan it be sent to an output file? and is everyline ending with a return? would the following do the output instaed of print result? i don't know where to put the result .. write %output.txt thanks again for your patience with a newbie keith
[REBOL] An appeal to keep /Core Re:(5)
As an example, REBOL modules seem to want to reside in a single home directory. Perl uses a mechanism where module naming structure and directory structure are parallel. Microware's OS9 embedded operating system uses a concept of "Memory Modules". Memory could be EPROM/FLASH/RAM in this context. There is a "Module Directory" much like your standard "DIR". You load memory modules as you need them, they get entered in to the Module Directory so that other processes can locate them (their contents are relocatable). The header of a module has a Revision Number. Say 8006 for example. At boot time the kernel searches out any modules and links the one with the highest Rev in to the MDIR. This allows you to burn in newer code in to EPROM with out having to erase the old code. There is also a link count of a module, as things need to use the resources of that module the link count is incremented (requested via MDIR search/link). They decrement the link count when done with what they needed. If the count becomes zero that memory is freed (when in RAM). My system is set up so that normally every thing is running from FLASH, but when debugging I can load a module with higher Rev into RAM to debug it. There is also a CRC 'wrapper' to check the integrity of the module at load time. Just some ideas to be pondered... This mechanism evolved to meet the problem of managing a growing body of standard modules - it wasn't gratuitous. While
[REBOL] Re: parsing questions - newbie
hi elan well i've looked at the parse section and can't quite figure it out... how do you nominate that you want the parse function to take place on a text file say "aeros.txt" rather than a string? and how do you specify it's location? and how would you strip off just what's after the colon and discard what is before the colon? when you parse files, can it be done on a folder of files? i have a stack of html files that i need to extract all text in a particular section and then change the table cells to tabs etc but i have a few to do and would like to run the script over the whole lot at once if possible. i can see no reference to how you parse files locally..there are only examples of web addresses or specifying a string. thanks for your help keith hi all i am new to scripting (rebol and python) and was wondering if it was capable of doing to the following and if so..how? the following is an example of what i need to strip and turn into a tab delimited file.. the entries are from a music database that is updated weekly..it is in lotus notes so i export from there and it dumps this file out with the new titles for the coming week (here the 19th June) i only need to get the rows with the double astericks at the start (i put those in for this post, they are not there in the normal file) and then strip the words at the start and then put a tab in between them so i can bring it into excel for the sales team to look at i would need a first row to describe each column also maybe something like Title tab Artist tab Cat no tab APN etc etc the tracklisting is a little more complicated as it has multiple tracks within the row..they are seperated by commas i think that it won't be that hard but i had no success in perl so i thought i might try rebol or python... thanks in advance keith FORM: Popular Recording CMTYPESWITCH: Popular RELOCORIGINAL: 55864A2603AC94ACCA2568F200224388 CMCOUNTRY_ORIGIN: CMGENRE_CODE: **CPTITLE: INFINITE POSSIBILITIES **CPARTIST: AMEL LARRIEUX CPOARTISTS: **CMCATNUMBER: 4948792 **CMAPN: 9399700067507 **CMARIAPRICECODE: C9921 **CMARIAMEDIACODE: 21 **CMARIADISTRIBUTORCODE: SMA CMARIAPACKAGECODE: **DMRELEASE: 19/06/2000 cMDateFormat: 19/06/2000 12:00:00 AM DMDELETE: cMDeleteStatus: No **CMLISTPTRACKS: GET UP,I N I,SWEET MISERY,SEARCHIN' FOR MY SOUL,EVEN IF,INFINITE POSSIBILITES,SHINE,DOWN,WEATHER,MAKE ME WHOLE,GET UP (THREAD HAD FUN MAIN MI,GET UP (MV MIG MIX (RADIO)) CMLISTPARTISTS: ,,, RELOCMEDIA: F73C80183A01A8D7CA2568F2002A5517 **CURMPRICE: 15.91 **CMTYPE: Compact Disc CMRECORDCOMPANY: SONY MUSIC CMPACKAGE: CMARIADISTRIBUTORHOUSECODE: cDistributorHouse: CMLOCALE: Y $UpdatedBy: CN=PPT/OU=AEROS/O=JUKEBOX $Revisions: 02/06/2000 05:42:22 PM,02/06/2000 05:42:22 PM ;- Elan [ : - ) ]
