World: r3wp

It feels like forever. But it is really cool now.

I really like how you've evolved the system and its doing all of 
what I wanted slim to do minus one or two little things, which I 
can easily graft over modules as they are .

The next step is to publish the test suite in DevBase, then finish 
it, then make it work with loadable module systems.

it
 being the test suite.

Look at bugs 1721, 1722 and 1723. They are all fixed in the new version 
that is done but not built yet.

I like 1722

in 1723... did you really have to rewrite stuff, or just use the 
newest code?

The boot exts loader does its own importing, for efficiency. As such, 
it wasn't much code to rewrite.

I posted the ticket after I did the work.

Just added this note to #1722: "Note: This ticket is not a dup of 
#1177. We made the same error again with a new module system. We 
have a better solution this time though."

it would be nice if the rename options supports none, to allow explicit 
reloading of modules going thru the whole motion.

And it was a two-word fix :)

since you are telling it none, its not a security hole you chose 
to ignore the name.

That won't work for IMPORT, but might work for sys/load-module with 
a little care. Not sure about that one though.

DO does the reloading already though.

why woudn't it work with import?

Import doesn't have a rename feature on purpose, as a simplification. 
IMPORT is supposed to be user-level automagic stuff. The real work 
is done by LOAD-MODULE.

ok then... rename to none should be supported by LOAD-MODULE  ;-0

For one thing, renaming something already imported is an error. And 
a lot of the time IMPORT is just giving you access to stuff you already 
imported earlier with Needs.

though the stated default reaction in your CC ticket is the best 
course of action

(for import)

If you want the reloading, use DO. DO works on scripts and modules 
both, and does them every time. It even tries to import the module 
after it is created. This is everything that you were requesting 
out of reloads. What it won't do is override a loaded module in the 
module list that is the same version or newer, but you can import 
those directly using IMPORT options.

The override rules in the system module list are sacrosanct though. 
You can load and use modules, but you can't override modules in the 
system list without following the rules.

You don't have to import to the system list for modules to be useful 
though. Look at IMPORT's /no-lib refinement. (After a110 comes out 
and it is fixed)

well the idea of supporting none is that they are not put into the 
system list to begin with, whatever their name or path.

so I guess that is what /no-lib does?

IMPORT/no-lib does that.

ok so I'll shut up now   ;-D

What /no-lib does is converts a module to a private module. It does 
a full import directly into the user context instead of importing 
through lib. It doesn't even go into the system modules list as a 
reusable prebuilt module, which named private modules otherwise do.

Which reminds me, I need to add that last bit to the tests.

R3 win console: Thanks for everyone who tested. So it looks it works 
for you, cool. Note that the character output should be correct but 
the default console font doesn't support all the chars. You might 
try to use Lucida Console font in the console properties which should 
give you more(but not all) valid characters or get some other unicode 
capable console font from the net...

Fork.... earlier discussion of INF is here:

   http://www.rebol.org/aga-display-posts.r?offset=0&post=r3wp771x5711

As Brian says, best place for any proposals for Carl to consider 
is here:
    http://www.curecode.org/rebol3/ticket.rsp?id=1717&cursor=1


The range of possible approaches extend from INF always throws an 
error to INF is a first class value. Somwhere in the middle is INF 
acting like UNSET! -- something you can use, but must be handled 
with great care.

...approaches extend from INF always throws an error to INF is a 
first class value. Somwhere in the middle is INF acting like UNSET!...

 - I do not think this describes the situation. I see it differently, 
 thinking, that there are only two consistent alternatives (the current 
 state is inconsistent, as everybody agrees with):


1) inifinities are not REBOL values (this state existed before FP 
pairs were introduced). I am pretty sure, that the description "INF 
always throws an error" is misleading, exactly because such a value 
does not even exist in REBOL


2) infinities exist in REBOL. In this case, they have to be "first 
class values", but, of course, they are not handleable by all functions, 
since e.g. +INF + -INF is not defined

Infinities seem to exist only by accident right now: the two known 
methods of generating an INF could be declared by Carl as bugs, and 
all INFs banished.
Or they could be fully REBOLised in ways that we find useful.

It would be interesting to know:


- what is the popular demand, i.e. which variant is preferred by 
the majority
- what are the reason for such preference

As far as I am concerned, I slightly prefer 1), just since I already 
got used to it in R2.

(I have no large objections to introduce infinities to the decimal! 
datatype, though)

I really dislike having to support infinity.  it might be sexy for 
scientific stuff, but rebol doesn't have the scientific or statistical 
math muscle to make that any more viable than trying to support complex 
& imaginary numbers as first-class types.

supporting infinity opens up a can of worms IMHO.  if one really 
needs to do heavy math stuff, its probably better to use C and professional 
math libraries via an extension.

I almost agree with Maxim here. I think there should be a clear definition 
of REBOL 3 math *can* and *cannot* do. Leave the complex numbers, 
symbolic math and infinity to modules and extensions.

Actually, infinities, are not that much "scientific stuff" as it 
may look at the first sight. Anything you can do with infinities 
is not hard to do withouth them as well.

Nevertheless, since infinities are supported by IEEE754, it is actually 
(IMO) easier to have them in the language than not.

I mean "easier for the implementor of the interpreter", not more 
user-friendly, of course.

Cyphre - I re-tested with all possible special czech alphabet chars, 
and even with default font in console, it worked OK. Or was I just 
lucky, and your note was more general, e.g. that such a font can't 
support all possible chars in different than czech language?

BrianH: I just looked into Delayed extension note is CC - cool guru 
stuff :-) btw - do I understand it correctly, that unnamed modules 
will be named in module list, according to the filename? But what 
if there is unnamed module, which is not loaded from file?

Pekr, yes you are lucky because czech chars are present in the default 
font. Chars of other languages can have problems so they need the 
Lucida COnsole font or even better one.
The current situation of the win console is:

-we can have core.exe as 'console app' which will work as the 'prototype' 
I released for testing

-we can have view.exe as 'GUI app' which will always open own console 
window (even from cmd.exe)


(If we make the view.exe as 'console app' there will be always quick 
console window blink during execution where only GUI window is shown 
initially)

I don't like blinks :-)

Couldn't we just have view.exe, which is basically core with delayed 
View extension? That would not probably work, right?

same difference

first: it does not really matter for the graphics if the binary is 
compiled as console or gui app. keep that in mind