World: r3wp

I read it. I was saying that *as a hard rule* platform-specific behavior 
is reserved for only a few functions in R3. For other functions it 
is a bug. I'm not satisfied until that bug is at least reported. 
Am I clear now?

Feel free to report it.

Nobody will correct it, though, since it is generated by the MS compiler

Andreas, I am not qualified to do so. I haven't read the standard, 
don't know the code involved, and don't run Linux.

Ladislav, why can't you write your own formatter, or use a consistent 
third-party one? At least when you detect a known error during config?

Brian, you are perfectly qualified. mold/all 0.1 on Windows differs 
from mold/all 0.1 on Linux. If you are only satisfied when this is 
reported as bug, feel free to report it.

But I can't say which is the buggy one.

Ladislav, why can't you write your own formatter
 - I can do so in GCC, but not in MS C, sorry

Brian, you don't have to.

(unsupported)

Report the observed difference and the expectation that this should 
not differ. The rest is up to whoever feels qualified to contribute 
more detailed observations and/or implementing a fix.

Andreas, sorry, CureCode doesn't let you report a platform-specific 
bug without specifying the platform. I can't just say "it's not consistent" 
without it being a useless bug report. We need a report from a person 
who is qualified to make an expert decision.

At the very least, it means that any report I make would have to 
be rewritten (or comments to the same effect) by Ladislav, or someone 
equivalently qualified.

I can admit it is a bug, by I cannot really correct it in MS C without 
"too much expense"

http://www.curecode.org/rebol3/ticket.rsp?id=1633

See, that was not so hard to report, was it?

Just like I have to rewrite all of the bug reports about R3's module 
system before they can be useful. It sucks, but we need an expert.

Now it is in the system, on those more knowledgeable on the matter 
can refine it.

Ladislav?

What do you mean by "too much expense"?

Well, sure, it is a report, but, as I said, I am not going to correct 
it (would be too expensive)

That's not a problem. If it is not possible to fix, Carl or someone 
else can decide that this behaviour is ok and mark it as won't fix.

To implement my own formatter, MS disallows me to use the best datatype 
for it

So, I have to use their formatting function, which produces this 
result

Please put that in a comment of bug#1633 - it might help justify 
not using MS's compiler.

Ladislav, I would like to see how you write that formatter under 
GCC, Is that too much code that you can't show it us ?

If so, forget it

Hmm, I should not do it, I suppose.

But, the principle is quite simple: multiply the number by a "suitable" 
power of 10 and convert the result to integer. The trouble is, that 
you need to use a high precision multiplication and power.

(which is unsupported in MS compiler)

You mean, you don't do it using an incremental way, each digit separatly 
?

No

What version of the MS compiler is being used? Can it be upgraded, 
and would that help? Can the Intel compiler be used, or the DMC++?

Only "ancient" versions of MS compiler support the extended precision

GCC should suffice. And as Carl is already using it for the Host 
Kit, it may also be possible.

Max: this is very funny. normal MOLD, afaik, is only there for backward 
compatibilty. i personally almost always use /all, when i don't use 
it it's because i'm molding something i just loaded or something 
like that, eg. i know that i don't need the /all, bet even if i used 
it it would make no difference at all.

it's very very hard imho to come up with reason NOT to use /all...

if you try to DO a script saved with SAVE/all or MOLD/all, it will 
fail if it contains functions or objects.
 - show me an example.

The primary purpose of SAVE is to save scripts that are to later 
be processed by DO.

 - weird, i always use save and load to save and load data. but, even 
 if that was the case, save/all would work just as well, so this is 
 a silly argument.

Hmm... I recall saving rebol objects with save/all and not being 
able to load them again properly

but SAVE is not only for DED, THAT is my point.

 - in that case, SAVE/ALL is *BETTER* than SAVE. there is no argument 
 about that.

some problem with functions inside objects or something

If you write them out directly in that syntax, you are mixing paradigms.

 - that makes NO sense. I write them directly MANY times because it 
 saves useless evaluation of DATA

Brian: your #[function! ] example is something I have ALWAYS pointed 
out as a bug and you ALWAYS countered by saying it is a "security 
feature" which i still thing is a very stupid thing to do (doing 
that as a "security feature")

SAVE and MOLD are explicitly designed to be newbie-friendly

 - I though Carl had realized, that "newbie-friendly" is the worst 
 thing you can do to a language. I hope others realize this as well, 
 as soon as possible...

Graham: show me ONE example of something you can LOAD but then breaks 
when you SAVE/ALL it back.

SAVE is *not* able to serialize arbitrary REBOL data. that is a known 
problem that Carl did not consider important enough to address, since 
he prefers using dialects to interchange data instead of just moving 
around the internal representation a program may be using.

User friendliness
 is in the eye of the beholder. I consider this:

>> block: [none #[none] true #[true] 0.1 0.10000000000000002]
>> print mold/all block

[none #[none] true #[true] 0.10000000000000001 0.10000000000000002]
>> print mold block
[none none true true 0.1 0.1]


as a problem for me, trying to give me wrong informations, as well 
a a problem for a beginner, who may not even be able to find out 
the informations he obtained were wrong

CureCode #1634, add a "me too", if you like

Gabriele, I also always use /ALL, when molding.    as I stated, I 
was playing devil's advocate, in which case I helped improve the 
case for SAVE/ALL being better.


 but I'm not sure its a good thing to break the symmetry between mold/all 
 and save/all.  


IMHO if we change one, we should change both.  IMO this is a better 
solution.


but this doens't change the fact that MOLDing is severely limited 
in many ways.