Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

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