World: r3wp

to binary!

Typesets are really useful - do you want to write all of that out? 
Plus, they are implemented as bitsets, so they are really efficient.

The backported version of typesets in R2-Forward is implemented as 
blocks of datatype! values - not as efficient.

find any-object! type? :value
Uhm cool, i completly forget that point

ok i changed my mind, it's useful

working with parse as well ?

interesting that to-binary works for decimal, but not money.

bah, you can store a fixed point decimal, what the need to store 
money ?

A lot of stuff doesn't work for money! yet - we have a stack of deferred 
tickets for money!, not as many as for vector! though.

vector vector vector, FIRST !!!!

We'll get to them - right now we're working on lower-level stuff.

no rush on money from my perspective. just pointing it out.

something lower than vectors ?
What could it be... neutrinos ?

Lower-level in terms of core functionality. R3 is weird - there are 
some mezzanines that are lower-level than some datatypes :)

What !!! Some mezzanines are lower ?
it's a joke right ? ahah

(i forgot that LOAD was a mezzanine now)

to binary for money: it does not make as much sense as for the decimal! 
datatype, since the datatype is accurate. what would you need it 
for?

For that matter, half of DO is mezzanine, or rather "intrinsic" - 
what we call REBOL code called internally by native code.

Ladislav, I have no idea. What do you need to-binary on decimal for?

file storing in a compact format

We will have rebin for that.

rewhat ?

yes in some decades

ReBin - binary encoding for REBOL values. Carl is working on it now 
- as the new host interfaces require it. We will have it very soon.

to-binary on decimal is actually the only method how to obtain the 
precise representation of a decimal. For money! mold suffices

If Rebin store slot values, it will not be compact, same memory overhead.

To binary! furnish a more compact way to store data, with a speed 
issue indeed

Don't assume that it will store slot values. The reason that Rebin 
is being used in the host interface is to make the internal layout 
of the slot values something you don't see, so that it can change 
for different platforms.

Rebin is supposed to be compact - that is its other purpose (reducing 
line overhead for network protocols).

ok ok, nice draft

Could it mean that we will store complex data structures (nested 
series and object without duplicated values, like MOLD do) ?

actually it would be a true reversal mold

(loadable mold)

In theory, that is its intention. In practive I don't know about 
binding issues.

so if i take another example, i could do a save in rebin format of 
the screen gob, then reload it and being in the same state i was 
when i saved it ?

cool feature for graphic applications

That does sound cool.

because i am

it would be a new way to make screenshots

and your screenshot contains the whole application, you can test 
it  in the state it was when i done the capture

is that not a too powerfull feature for  humanity ?

Carl could be afraid and not release it

That would be affected by binding issues. Rebin is still partly in 
Carl's head, under development. I can't answer some things :(

it was actually Geomol on 8-Apr, who too refused to submit bugs, 
as those might not be corrected anyway


Pekr, I don't refuce to submit bugs! I have submitted bugs after 
we discussed it here. I just see little point in submitting bugs. 
And I have the practical problem with finding time to submit all 
the bugs, I could. But I do something, I consider even better than 
submitting bugs in the current situation. I have done some development 
lately, that test the REBOL scanner deeply. I have collected all 
my findings in a document, that I'll give to R3 developers, when 
I'm finish. The scanner is just one part of REBOL though.

That would be great, thanks :)

If you want to really test the scanner, test TRANSCODE. There is 
already one bug ticket in for a change in TRANSCODE's behavior, and 
I know of another bug that is worth reporting. If we find more bugs 
that we can fix, that would be great.

I just see little point in submitting bugs.


If you are talking about bugs in stuff that is mostly designed but 
not fully implemented (like money!, or maybe vector!) then they are 
worth reporting if they haven't been reported already - just don't 
expect an immediate fix, since we may not be working on those yet.


If you are talking about bugs in stuff that is still being designed 
(like the GUI) then reporting problems in R3 chat is better. 


If you are talking about bugs in stuff that hasn't been designed 
yet but may have a placeholder (like task! or utype!) then don't 
bother.

If you are talking about bugs in what we are working on (there's 
a roadmap) or requests for new behavior then report them asap :)

I don't like the behavior of parse regarding hyphens after delimiters, 
although it's the same as in R2 and there said to be needed for parsing 
csv data
 
>> parse/all {, ", ,} ","
== ["" { "} " "] ; this is as I expect

>> parse/all {, ," ,} ","
== ["" " " " ,"] ; I would expect == [""  {" } " "]

Do you mean double-quotes? A hyphen is this: -

sorry, then double quotes