CORE experimental 2.4.39
[1/26] from: jeff::rebol::net at: 22-Nov-2000 16:23
Howdy, REBOLs of the world!
REBOL/core 2.4.39 experimental is now posted for download
(most platforms). This version has a lot of fixes and
improvements. Please do download it and put it through its
paces. If all goes well, the more everyone bangs on this
build, the closer we'll be to next release version! :-)
The remaining platforms will soon follow, but probably not
until sometime next week.
-jeff
=======================================================
CHANGES --- REBOL/core 2.4.39 experimental
=======================================================
Added GET-MODES and SET-MODES for file and network ports. (These
functions are NOT documented at this time and are subject to change in
later versions. Use at own risk.)
Added fork selection to the /custom block for OPEN, READ etc.
Added /skip refinment to SELECT, FIND, UNION, INTERSECT,
EXCLUDE, DIFFERENCE, UNIQUE.
Added garbage collection of unreferenced open ports.
Added CHECKSUM/hash.
Removed /only refinement from DIFFERENCE (EXCLUDE is equivalent).
Numerous fixes, enhancements and optimizations for list! and hash!.
Added SYSTEM/SCRIPT/HEADER/CONTENT. When a REBOL script has the
field CONTENT within the REBOL header and CONTENT is set to TRUE, the
source code of the script will be placed in
SYSTEM/SCRIPT/HEADER/CONTENT if the script is evaluated with DO, or
included in the REBOL header oject found in the loaded block if
imported with LOAD/header (or LOAD/next/header).
Added NOW/precise refinement.
Added asynchronous 'wait-able DNS for Unix and Windows:
open dns:///async, then insert/wait/copy.
UNIQUE uses the /case refinement.
TO-BINARY of tuples now uses the tuple values instead of forming the
tuple.
LOAD/next/header now works as you would expect, resulting in a block
with the evaluated header followed by the rest of the script as a
string.
JOIN on binary values now joins as binaries, not formed strings.
Time! values can convert to integers and decimals.
Weekdays fixed in system/locale/days.
MOLD/only - does not include the outermost [] in the outer block.
WAIT now works correctly on /lines ports opened without /with.
WAIT now supports ports handlers (http, tcp etc.) in /direct mode.
Added 'awake field in port-spec and root protocol to
specify a block or function called when wait is about
to wake up. Used to implement background processing.
RANDOM now accepts series values picking a random item from that
series.
Subtraction of a date! value months bug fixed.
Indefinite extent fixed, more or less.
Numerous other bug fixes.
[2/26] from: larry:ecotope at: 22-Nov-2000 19:45
Hi Jeff
Just testing the new version. Excellent!!! I have one quick question about
the "indefinite extent" or "GC bug" being fixed. This test now works.
>> b: []
== []
>> use [x][x: 1 append b 'x]
== [x]
>> use [x][x: 2 append b 'x]
== [x x]
>> reduce b
== [1 2]
>> recycle
>> reduce b
== [1 2]
Great!!
But you wrote:
Indefinite extent fixed, more or less.
What are the qualifications? When does the "less" come into play?
Cheers
-Larry
[3/26] from: gchiu:compkarori at: 23-Nov-2000 17:47
On Wed, 22 Nov 2000 19:45:00 -0800
"Larry Palmiter" <[larry--ecotope--com]> wrote:
> *This message was transferred with a trial version of
> CommuniGate(tm) Pro*
> Hi Jeff
>
> Just testing the new version. Excellent!!! I have one
> quick question about
Where is it? http://www.rebol.com/xpers/xpers.html
I only see 2.4.37
--
Graham Chiu
[4/26] from: al:bri:xtra at: 23-Nov-2000 18:03
Graham wrote:
> Where is it? http://www.rebol.com/xpers/xpers.html
> I only see 2.4.37
The top of that page should be:
Updated: 22-Nov-2000/17:28:30-8:00
If it isn't, flush your browser cache?
Andrew Martin
ICQ: 26227169
http://members.nbci.com/AndrewMartin/
[5/26] from: jeff:rebol at: 22-Nov-2000 20:36
Howdy, Larry:
> Indefinite extent fixed, more or less.
>
> What are the qualifications? When does the "less" come into
> play?
Functions in the newest experimental do not exhibit indefinite
extent.
-jeff
[6/26] from: petr:krenzelok:trz:cz at: 23-Nov-2000 7:18
Whooo ho, Jeff, you are the messenger of some progress being taken even in
area of core technology development :-) Is REBOL/Express really so great
you folks are so silent last weeks? :-)
[jeff--rebol--net] wrote:
> Added GET-MODES and SET-MODES for file and network ports. (These
> functions are NOT documented at this time and are subject to change in
> later versions. Use at own risk.)
>
Does it mean they could be removed later? Or do you mean just change of
their behavior? What are these functions good for, please? :-) I tried
'get-on upon my mailbox port, but it does seem to want different kind of
parameter .... I was not succesfull even with file port:
->> file: open %novy.txt
->> get-modes file
** Script Error: get-modes expected modes argument of type: word block
** Near: get-modes file
> Added fork selection to the /custom block for OPEN, READ etc.
And - what does this one mean? :-)
> Added NOW/precise refinement.
>
nice ...
> Added asynchronous 'wait-able DNS for Unix and Windows:
> open dns:///async, then insert/wait/copy.
is the number of slashes correct?
There seem to be always something to improve :-) Now when above changes
will find it's way into REBOL/View? :-)
Very nice, RT, thanks for the update! Now how about other suggested and
really usefull additions as parser improvement, etc?
-pekr-
[7/26] from: gchiu:compkarori at: 23-Nov-2000 19:43
On Thu, 23 Nov 2000 18:03:46 +1300
"Andrew Martin" <[Al--Bri--xtra--co--nz]> wrote:
> The top of that page should be:
> Updated: 22-Nov-2000/17:28:30-8:00
> If it isn't, flush your browser cache?
>
Odd. Came up straight away this time.
Thanks,
--
Graham Chiu
[8/26] from: g:santilli:tiscalinet:it at: 23-Nov-2000 13:16
[jeff--rebol--net] wrote:
> Added fork selection to the /custom block for OPEN, READ etc.
Any info on this?
> TO-BINARY of tuples now uses the tuple values instead of forming the
> tuple.
What about integers?
> Indefinite extent fixed, more or less.
*THAT IS REALLY GREAT NEWS!*
(Well, that "more or less" scares me a bit, but it seems to be
working for simple cases... :)
Regards,
Gabriele.
--
Gabriele Santilli <[giesse--writeme--com]> - Amigan - REBOL programmer
Amiga Group Italia sez. L'Aquila -- http://www.amyresource.it/AGI/
[9/26] from: petr:krenzelok:trz:cz at: 23-Nov-2000 13:23
Gabriele Santilli wrote:
> [jeff--rebol--net] wrote:
> > Functions in the newest experimental do not exhibit indefinite
<<quoted lines omitted: 3>>
> fast as it is now... creating a whole new context for each
> function call isn't a good idea IMHO.
Hi Gabriele, what's the practical usability for indefinite extent?
Thanks,
-pekr-
[10/26] from: g:santilli:tiscalinet:it at: 23-Nov-2000 13:21
[jeff--rebol--net] wrote:
> Functions in the newest experimental do not exhibit indefinite
> extent.
You mean, using recursion? Well, I'm not surprised about this, and
I think this behaviour should not be changed. It's so simple and
fast as it is now... creating a whole new context for each
function call isn't a good idea IMHO.
Regards,
Gabriele.
--
Gabriele Santilli <[giesse--writeme--com]> - Amigan - REBOL programmer
Amiga Group Italia sez. L'Aquila -- http://www.amyresource.it/AGI/
[11/26] from: whip:cs:unm at: 23-Nov-2000 5:44
Howdy, Gabriele:
> [jeff--rebol--net] wrote:
>> Functions in the newest experimental do not exhibit indefinite
>> extent.
>
> You mean, using recursion?
In general, like:
f: func [/x][x: random 10 'x]
b: [] loop 10 [append b w: f probe get w] reduce b
You wind up with all the same number in the block, though 'x in f's
context had been 10 different random numbers.
> Well, I'm not surprised about this, and
> I think this behaviour should not be changed. It's so simple and
> fast as it is now... creating a whole new context for each function
> call isn't a good idea IMHO.
Right-o. The idea tossed around has been that functions can be
saved explicitly with the function attribute: [save].
-jeff
[12/26] from: whip:cs:unm at: 23-Nov-2000 5:54
Howdy, Gabriele:
> [jeff--rebol--net] wrote:
>
>> Added fork selection to the /custom block for OPEN, READ etc.
>
> Any info on this?
Though I included the changes doc in my email, I'm not the one who
made all of these changes! :-) Haha. Hope I didn't leave that
impression. (: As usual, it was a team effort, but also as usual, I'm
as new to some of this stuff as the next guy.
Fork selection is for Macs, being able to read and write the data or
the resource forks. This is important so that REBOL can write files
on a mac, while retaining creator types and all that stuff.
>> TO-BINARY of tuples now uses the tuple values instead of forming
>> the tuple.
>
> What about integers?
Nope.
-jeff
[13/26] from: g:santilli:tiscalinet:it at: 23-Nov-2000 15:13
nop wrote:
> Right-o. The idea tossed around has been that functions can be
> saved explicitly with the function attribute: [save].
Hmm... well, it might be useful sometimes, but I think you can
give this low priority in the to-do list. :-) If one needs a new
fresh context each time, one can use USE (now that it works).
>> f: does [use [x] [x: random 10 'x]]
>> b: [] loop 10 [append b f]
== [x x x x x x x x x x]
>> reduce b
== [5 2 10 6 7 2 3 2 4 5]
I'm happy now, ;-)
Gabriele.
--
Gabriele Santilli <[giesse--writeme--com]> - Amigan - REBOL programmer
Amiga Group Italia sez. L'Aquila -- http://www.amyresource.it/AGI/
[14/26] from: g:santilli:tiscalinet:it at: 23-Nov-2000 15:08
Petr Krenzelok wrote:
> Hi Gabriele, what's the practical usability for indefinite extent?
Hiding words and doing some very nice tricks. :-)
(It will be very useful until we get the MODULE! datatype)
Regards,
Gabriele.
--
Gabriele Santilli <[giesse--writeme--com]> - Amigan - REBOL programmer
Amiga Group Italia sez. L'Aquila -- http://www.amyresource.it/AGI/
[15/26] from: holger:rebol at: 23-Nov-2000 6:41
On Thu, Nov 23, 2000 at 07:18:00AM +0100, Petr Krenzelok wrote:
> > Added GET-MODES and SET-MODES for file and network ports. (These
> > functions are NOT documented at this time and are subject to change in
> > later versions. Use at own risk.)
> >
>
> Does it mean they could be removed later? Or do you mean just change of
> their behavior?
The API might still change. The functionality will remain though.
> What are these functions good for, please? :-) I tried
> 'get-on upon my mailbox port, but it does seem to want different kind of
> parameter .... I was not succesfull even with file port:
You can change port modes (binary vs string etc.), platform-specific
file properties such as permission bits or dates, and for sockets
things like type-of-service, lists of multicast groups etc. -- and a
lot more.
More info on calling conventions and supported modes once we have
made a final decision regarding the API.
> > Added fork selection to the /custom block for OPEN, READ etc.
>
> And - what does this one mean? :-)
open/custom %abc [fork "data"]
opens the data fork of a file,
open/custom %abc [fork "resource"]
opens the resource fork. At the moment this is just a "Mac thing".
> > Added NOW/precise refinement.
> >
>
> nice ...
Accuracy depends on the platform: Mac: one second (unfortunately),
Windows: one millisecond, all other platforms: one microsecond.
> > Added asynchronous 'wait-able DNS for Unix and Windows:
> > open dns:///async, then insert/wait/copy.
>
> is the number of slashes correct?
Yes. The first two slashes are optionally used to separate the
scheme from the hostname for "normal" DNS requests (e.g.
dns://hostname
), scheme-specific things such as DNS options
follow the third slash. Use for example
a: open/no-wait dns:///async
insert a "www.rebol.com"
wait a
copy a
close a
The same port can be used for multiple consecutive DNS lookups.
Just alternate between insert and copy. You cannot queue multiple
requests in the same port though.
> There seem to be always something to improve :-) Now when above changes
> will find it's way into REBOL/View? :-)
With the next release, probably.
--
Holger Kruse
[holger--rebol--com]
[16/26] from: pa:russo:perd at: 23-Nov-2000 15:27
<fontfamily><param>Helvetica</param>
On Thursday, November 23, 2000, at 01:54 PM, nop wrote:
<color><param>0000,0000,0000</param>
<italic></italic></color><italic> Howdy, Gabriele: </italic><color><param>0000,0000,0000</param>
<italic></italic></color><italic>> [jeff--rebol--net] wrote:</italic><color><param>0000,0000,0000</param>
<italic></italic></color><italic>></italic><color><param>0000,0000,0000</param>
<italic></italic></color><italic>>> Added fork selection to the /custom block for OPEN,
READ etc.</italic><color><param>0000,0000,0000</param>
<italic></italic></color><italic>></italic><color><param>0000,0000,0000</param>
<italic></italic></color><italic>> Any info on this?</italic><color><param>0000,0000,0000</param>
<italic></italic></color><italic> Fork selection is for Macs, being able to read and
write the data or</italic><color><param>0000,0000,0000</param>
<italic></italic></color><italic>the resource forks. This is important so that REBOL
can write files</italic><color><param>0000,0000,0000</param>
<italic></italic></color><italic>on a mac, while retaining creator types and all that
stuff.</italic><color><param>0000,0000,0000</param>
I think I could kiss the guy who implemented this feature... as soon as I can lay my
hands on Mac and Mac OS X versions :-)=
[17/26] from: pa:russo:perd at: 23-Nov-2000 16:39
<flushleft><fontfamily><param>Helvetica</param><x-tabstops><param>28L;56L;84L;112L;140L;168L;196L;224L;252L;280L;308L;336L;</param>
On Thursday, November 23, 2000, at 01:54 PM, nop wrote:
<color><param>0000,0000,0000</param>
<italic></italic></color><italic> Howdy, Gabriele: </italic><color><param>0000,0000,0000</param>
<italic></italic></color><italic>> [jeff--rebol--net] wrote:</italic><color><param>0000,0000,0000</param>
<italic></italic></color><italic>></italic><color><param>0000,0000,0000</param>
<italic></italic></color><italic>>> Added fork selection to the /custom block for OPEN,
READ etc.</italic><color><param>0000,0000,0000</param>
<italic></italic></color><italic>></italic><color><param>0000,0000,0000</param>
<italic></italic></color><italic>> Any info on this?</italic><color><param>0000,0000,0000</param>
<italic></italic></color><italic> Fork selection is for Macs, being able to read and
write the data or</italic><color><param>0000,0000,0000</param>
<italic></italic></color><italic>the resource forks. This is important so that REBOL
can write files</italic><color><param>0000,0000,0000</param>
<italic></italic></color><italic>on a mac, while retaining creator types and all that
stuff.</italic><color><param>0000,0000,0000</param>
I think I could kiss the guy who implemented this feature... as soon as I can lay my
hands on Mac and Mac OS X versions :-) </color></x-tabstops></fontfamily></flushleft>=
[18/26] from: petr:krenzelok:trz:cz at: 23-Nov-2000 16:44
Holger Kruse wrote:
> > What are these functions good for, please? :-) I tried
> > 'get-on upon my mailbox port, but it does seem to want different kind of
<<quoted lines omitted: 5>>
> More info on calling conventions and supported modes once we have
> made a final decision regarding the API.
... sounds impressive ... and Holger .... you're da network man - what about
description of print mold system/schemes/whatever fields? many interesting
items, i mean:
status: none
size: none
date: none
url: none
sub-port: none
locals: none
state: none
timeout: none
local-ip: none
local-service: none
remote-service: none
last-remote-service: none
direction: none
key: none
strength: none
algorithm: none
block-chaining: none
init-vector: none
padding: none
async-modes: none
remote-ip: none
local-port: none
remote-port: none
backlog: none
device: none
speed: none
data-bits: none
parity: none
stop-bits: none
rts-cts: true
user-data: none
awake: none
passive: none
cache-size: 5
user-agent: "REBOL 2.4.39.3.1"
> > > Added NOW/precise refinement.
> > >
> >
> > nice ...
>
> Accuracy depends on the platform: Mac: one second (unfortunately),
> Windows: one millisecond, all other platforms: one microsecond.
Mac doesn't offer better timers? :-)
> > > Added asynchronous 'wait-able DNS for Unix and Windows:
> > > open dns:///async, then insert/wait/copy.
<<quoted lines omitted: 12>>
> Just alternate between insert and copy. You cannot queue multiple
> requests in the same port though.
Will also other port types be made asynchronous?
Thanks,
-pekr-
[19/26] from: holger:rebol at: 23-Nov-2000 8:40
On Thu, Nov 23, 2000 at 04:44:51PM +0100, Petr Krenzelok wrote:
> ... sounds impressive ... and Holger .... you're da network man - what about
> description of print mold system/schemes/whatever fields? many interesting
> items, i mean:
> status: none
> [...]
Probably later :-). Some of these are internal, some are for specialized
ports...
> > Accuracy depends on the platform: Mac: one second (unfortunately),
> > Windows: one millisecond, all other platforms: one microsecond.
>
> Mac doesn't offer better timers? :-)
Mac does have better resolution for interval timers, but not for the time
of day timer. AFAIK only MacOS 9 offers a higher resolution for time of
day (1/65536 of a second), and only for certain newer Mac models. We
might support this in a future version. At the moment the requirements for
REBOL on Mac are MacOS 8 or higher and OpenTransport.
> Will also other port types be made asynchronous?
UDP already is (by its very nature): sending is asynchronous, within the
TCP/IP stack. Receiving can block (or not) depending on whether no-wait was
used.
TCP is "officially" asynchronous for receiving only, using no-wait.
Internally it is also asynchronous for connecting, accepting and sending,
mostly controlled through get/set-modes, but the API is not quite
finished yet (in particular for sending). It needs a little more work to
be "nice" to use :).
Higher protocol layers (HTTP, FTP) are currently based on the synchronous
root protocol
, i.e. they are synchronous by themselves. One of the
things we plan to do in the future is implement an "asynchronous root
protocol" which has all of the functionality of the current root protocol
(connect, read, write, proxy support, dialog parsing etc.), but is fully
asynchronous and handler-driven. An asynchronous version of HTTP could then
be implemented on top of that, which would, e.g., allow an arbitrary number
of parallel HTTP downloads in the background. Express already does something
like this, using its own asynchronous implementation.
--
Holger Kruse
[holger--rebol--com]
[20/26] from: petr:krenzelok:trz:cz at: 23-Nov-2000 21:56
----- Original Message -----
From: Holger Kruse <[holger--rebol--com]>
To: <[rebol-list--rebol--com]>
Sent: Thursday, November 23, 2000 5:40 PM
Subject: [REBOL] Re: CORE experimental 2.4.39
> > Will also other port types be made asynchronous?
>
> UDP already is (by its very nature): sending is asynchronous, within the
> TCP/IP stack. Receiving can block (or not) depending on whether no-wait
was
> used.
> TCP is "officially" asynchronous for receiving only, using no-wait.
<<quoted lines omitted: 8>>
> (connect, read, write, proxy support, dialog parsing etc.), but is fully
> asynchronous and handler-driven. An asynchronous version of HTTP could
then
> be implemented on top of that, which would, e.g., allow an arbitrary
number
> of parallel HTTP downloads in the background. Express already does
something
> like this, using its own asynchronous implementation.
Man, what are you waiting for? :-))) It would be cool to have. It's good
it's planned at least. Sounds like interesting addition for REBOL 3.0,
doesn't it? :-)
Cheers,
-pekr-
[21/26] from: lmecir:mbox:vol:cz at: 24-Nov-2000 2:55
After repairing the GC bug, Rebol is a *much* more elegant language!
Congratulations to RT. The /skip refinement is a big breakthrough too.
Jeff wrote:
> Howdy, Gabriele:
> > [jeff--rebol--net] wrote:
<<quoted lines omitted: 7>>
> You wind up with all the same number in the block, though 'x in f's
> context had been 10 different random numbers.
To celebrate the GC bug removal I wrote:
Rebol [
Title: "EFunc"
Date: 24/11/2000
File: %efunc.r
Author: "Ladislav Mecir"
Email: [lmecir--mbox--vol--cz]
Purpose: {
A function creating "indefinite extent" functions.
}
Category: [Advanced]
]
e-func: function [
{Indefinite extent func}
[catch]
spec [block!]
body [block!]
] [
set-args args set-fresh-args locals
] [
set-args: func [args-supplied] [args: args-supplied]
set-fresh-args: func [fresh-args] [
while [not tail? fresh-args] [
set/any first fresh-args get/any first args
fresh-args: next fresh-args
args: next args
]
]
locals: copy []
foreach item spec [
if all [any-word? :item not set-word? :item] [
append locals to word! :item
]
]
throw-on-error [
func spec reduce [
:set-args locals
:use locals reduce [
:set-fresh-args locals
:do body
]
]
]
]
Now, the Jeff's example behaves as follows:
>> f: e-func [/x][x: random 10 'x]
>> b: [] loop 10 [append b w: f probe get w] reduce b
5
4
9
10
5
7
6
9
6
6
== [5 4 9 10 5 7 6 9 6 6]
Nice, eh?
[22/26] from: lmecir:mbox:vol:cz at: 24-Nov-2000 3:36
Hi,
Gabriele wrote:
> > [jeff--rebol--net] wrote:
> >> Functions in the newest experimental do not exhibit indefinite
<<quoted lines omitted: 10>>
> > fast as it is now... creating a whole new context for each function
> > call isn't a good idea IMHO.
My research is showing me, that the opposite is correct: The "indefinite
extent" functions' behaviour is simpler/more natural/more useful for a user,
than the behaviour of its "definite extent" counterpart (that's probably the
reason, why Carl introduced "indefinite extent" to Rebol), and, moreover,
there *is* a way, how to make such functions faster, than the Rebol
functions are nowadays.
Regards
Ladislav
[23/26] from: g:santilli:tiscalinet:it at: 24-Nov-2000 14:50
Ladislav Mecir wrote:
[Func context extent]
> My research is showing me, that the opposite is correct: The "indefinite
> extent" functions' behaviour is simpler/more natural/more useful for a user,
> than the behaviour of its "definite extent" counterpart (that's probably the
> reason, why Carl introduced "indefinite extent" to Rebol), and, moreover,
> there *is* a way, how to make such functions faster, than the Rebol
> functions are nowadays.
This seems interesting... Would you mind explaining how? :-)
Regards,
Gabriele.
--
Gabriele Santilli <[giesse--writeme--com]> - Amigan - REBOL programmer
Amiga Group Italia sez. L'Aquila -- http://www.amyresource.it/AGI/
[24/26] from: ddalley:idirect at: 24-Nov-2000 9:15
On 23-Nov-00, Petr Krenzelok wrote:
> ----- Original Message -----
> From: Holger Kruse <[holger--rebol--com]>
<<quoted lines omitted: 9>>
> it's planned at least. Sounds like interesting addition for REBOL 3.0,
> doesn't it? :-)
Absolutely! If this would also increase transmission efficiency, this one
should be moved up on the to-do list.
--
---===///||| Donald Dalley |||\\\===---
The World of AmiBroker Support
http://webhome.idirect.com/~ddalley
UIN/ICQ#: 65203020
[25/26] from: lmecir:mbox:vol:cz at: 25-Nov-2000 18:34
Hi,
> [Func context extent]
> > My research is showing me, that the opposite is correct: The "indefinite
> > extent" functions' behaviour is simpler/more natural/more useful for a
user,
> > than the behaviour of its "definite extent" counterpart (that's probably
the
> > reason, why Carl introduced "indefinite extent" to Rebol), and,
moreover,
> > there *is* a way, how to make such functions faster, than the Rebol
> > functions are nowadays.
>
> This seems interesting... Would you mind explaining how? :-)
>
> Regards,
> Gabriele.
thank you for the question. First, I would like to show you an example
illustrating the benefits of the "indefinite extent" functions. They are a
tool allowing us to generate some useful parse rules:
a-b-rule: e-func [
{Generate an A-B parse rule}
a [block!] {A-rule}
b [block!] {B-rule}
/local res-rule
] [
[
[
b (res-rule: [to end skip]) |
(res-rule: a)
]
res-rule
]
]
{
Example:
a: [any "a" "b"]
b: ["aa"]
a-b: a-b-rule a b
parse "ab" a-b
parse "aab" a-b
}
not-rule: e-func [
"Generate a not A parse rule"
a [block!] {A-rule}
/local res-rule
] [
[
[
a (res-rule: [to end skip]) |
(res-rule: [])
]
res-rule
]
]
{
Example:
a: [any "a" "b"]
not-a: not-rule a
parse "ab" not-a
parse "b" not-a
parse "" not-a
}
For the above to work correctly, you should use E-func (my implementation of
indefinite extent
func) contained at: http://www.sweb.cz/LMecir/highfun.r
and the latest Rebol/Core experimental. If you recall my latest attempt to
write the above, you should remember, that the implementation was much more
complicated, yet it didn't behave correctly in some circumstances... (For
all fans of Highfun: the newest version contains corrected Cfor, new
Nm-use/E-func and simplified Curry/Refine.)
Now to the speed. The speed of the function evaluation is a result of a
trade-off. The Rebol function evaluation speed seems to be in relation with
the function modification speed. The faster you allow to be the
modification, the worse conditions you have to improve the evaluation speed.
I think, that there is a way, how to slow down the modification for the
benefit of the evaluation. In that case the evaluation speed for the
indefinite extent
functions can easily become higher, than the speed of
the "definite extent" functions evaluation now is.
Regards
Ladislav
[26/26] from: allenk:powerup:au at: 26-Nov-2000 15:54
----- Original Message -----
From: <[jeff--rebol--net]>
To: <[rebol-list--rebol--com]>
Sent: Thursday, November 23, 2000 10:23 AM
Subject: [REBOL] CORE experimental 2.4.39
> Howdy, REBOLs of the world!
> REBOL/core 2.4.39 experimental is now posted for download
<<quoted lines omitted: 7>>
> > CHANGES --- REBOL/core 2.4.39 experimental
> =======================================================
<SNIPPED lots of other great changes>
> Subtraction of a date! value months bug fixed.
Woohoo! no more warping to the year 23845 :-)
Any idea when using find/reverse with charsets might be fixed? (Feedback
#3681)
Cheers,
Allen K
Notes
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted