World: r3wp

Having "problem" status means that there is some (possibly temporary) 
reason it can't be solved at the moment. Then you look to the comments 
for why.

As to #1081, I merely pointed out the inconsistency, and did not 
advance a solution. The more inconsistencies, the more documentation 
is needed, and the more there is for the user to remember.

As for why it might be misguided, that is because the stated purpose 
of that request - recovering the module in serialized form - is definitely 
impossible, and would be a major security hole if it were possible 
(which is part of why it is not).

Ah, you're meijeru, cool. Nice to chat with you :)

The system wouldn't let me make meijeru my username on Altme, even 
though I requested Altme membership through rebol.org where I also 
known as meijeru.

The problem with getting rid of inconsistencies is when they are 
there for good reasons. In most cases you reported, they were not.

On modules again, I said already I accept the non-recoverability. 
But mold/all is there (also) for providing the fullest information 
about the value possible.

Why don't you try the settings change for the user color...

How's that (black now)

Cool. Back to modules, that is why the ticket was undismissed. It 
was only marked as a problem because one alpha temporarily made it 
even worse (later fixed).

Look at #1081 - Carl asked you a question that you didn't answer. 
Having no answer to that question is why it is still problem status.

meijeru: dunno what rules here are. I always agreed that ppl should 
be able to choose their nick-name here, but some other had different 
opinion on that IIRC. But maybe we could ask for change, as you are 
here for short time yet ....

BrianH: I answered the question now -- for me, explicit specification 
has precedence over implicit specification.

Thanks for that - now Carl can decide (this is in his purview).

Carl has announced the applicability of logical operators to type(set)s 
for a77. At first sight, this duplicates union ( ~ or) intersect 
(~ and) and difference (~ xor). Then again, both sets of operators 
are also defined on bitsets, so there is consistency in this duplication, 
and I suspect that typesets are really bitsets, internally. However, 
there is one extension: and/or/xor may have a single datatype for 
their second operand (also for their first???). This is not the case 
with union etc.

Typesets are bitsets internally, but they are immediate types, while 
bitset! is a reference type. This puts an upper limit on the number 
of built-in types - based on the number of free bits in a value slot.

I think your assessment is accurate though.

There are some occasions where the behavior of an op! or action! 
is different depending on what datatype its first argument is. Actions 
dispatch based on the type of their first argument only, so making 
the behavior work with the types reversed might require double-dispatch 
to work. This is a similar situation to that of Smalltalk classes.

hmm, it seems Carl did not succeed to resolve Plug-in interface, 
so we are getting some "simple method" ....

It's also possible that excessive complexity was the problem that 
needed resolving, and the "simple method" is the solution :)

yes. It is now at least clear, we will see soon :-)

A quick update on plugins - http://www.rebol.net/r3blogs/0226.html

nice

What's bad about a simple plug-in solution?

Only bad if simple = limited

maybe it's time for a beta version, as most features are in its place 
then?

still need modules and more bug fixes

I think that when we hit beta, people might expect to start writing 
production scripts with it. So we have to be sure that the important 
areas won't change too much between beta and final.

Two questions about calling other programs /scripts:


* when is CALL going to get some refinements -- like /wait and /output 
?

* what is the point of:
     launch none 
    ?

AFAIK:

* CALL might or might not get refinements - it may be a better strategy 
to just fix CALL so it doesn't need them. In any case, changes to 
CALL are likely to happen after the host code is released, since 
that is where CALL is implemented.

* What is the point of <anything about how LAUNCH behaves>: It's 
due for a complete redo - none of its current behavior is intended.

First docs appeared - http://rebol.com/cgi-bin/docs.r?do=sumlog

BrianH: I miss call/output, call/wait refinements at least ....

I also don't understand, why the regressioin of 'call happened.

Thanks for the explanation, Brian.

hmm, no IO, callbacks this time .... I look forward to REBOL gurus, 
bringing some usefull features to R3. However - it is more than clear 
that this type of interface is not for all. So - I still look forward 
for vastly improved DLL interfacing method, which allows even ppl 
like me to have some usefull things done ...

Does anybody know the reason that money! is not included in the list 
of immediate datatypes for plug-ins?

Following on from asking about CALL and LAUNCH.....Is TASK meant 
to be any thing other than a placeholder in the current alphas? All 
it does for me is crash the console.

Does anybody know the reason that money! is not included in the list 
of immediate datatypes for plug-ins?
 - money! is not 64-bit datatype

Money: Well, but it should be possible to exchange it as a struct 
or whatever is needed. And we can provide some C-level code to handle 
the internal format.

I somehow can't understand, what is the difference between a plug-in 
funciton, and for e.g. C level function wrapped into DLL call (R2 
way)? The example provided in doc shows rather complicated aproach 
of how such function has to be constructed. You simply can't write 
it your way? There has to be some reason for it :-)

Pekr, there is no regression: CALL in R3 is an entirely new function, 
which uses an entirely different, lower-level method to call stuff. 
I don't know whether the /output and /wait methods are possible with 
the new method, or whether they will be necessary once CALL is fixed. 
Right now CALL is a placeholder - the implementation is going to 
be in the host code (read: open-source), so development has been 
put on hold on CALL until the host code is released (which is intended 
to be soon).

Tasks are pretty much placeholders for now, but are intended to be 
included in the final R3. The model isn't settled.

Is there a problem with getting operators?

>> get to word! "="
** Script error: = word is not bound to a context

Using get-word syntax works:

>> :=
== op!

Ditto:
>> get to-word '=
== op!

The get-word syntax has a problem with the <> operator:

>> a: :<>
** Syntax error: invalid "word-get" -- ":"

Sunanda, so making string to words and making lit-words to words 
isn't quite the same, it seems!?

>> (to word! '=) = (to word! "=")
== true
>> (to word! '=) == (to word! "=")
== false

Strange!

>> type? to word! '=
== word!
>> type? to word! "="
== word!

Yes --  not sure why. Brian knows the internals.

Re broken syntax. QUOTE can help, eg:

>> get to-word  '<>
** Syntax error: invalid "word-lit" -- "'"

But:
>> get to-word quote <>
== op!

:-) QUOTE
(never heard of that one before)