r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[!REBOL3-OLD1]

BrianH
27-Apr-2009
[13566]
He mentioned the real sizes at some point (in a blog I think), but 
I don't remember the exact numbers.
Steeve
27-Apr-2009
[13567]
don't remember that
BrianH
27-Apr-2009
[13568x2]
For my code I find that I only need to think in terms of number of 
copies, or preallocation. On an algorithmic level you can save orders 
of magnitude in memory overhead (space and time) by controlling the 
number of copies.
The FOREACH changes in alpha 49 were done to reduce memory overhead, 
for instance.
Steeve
27-Apr-2009
[13570]
Don't force me to disassemble the binary to know that, otherwise 
i'm afraid that Dockimbel will kill me.
BrianH
27-Apr-2009
[13571]
Same with exposing COLLECT-WORDS so it can be used instead of BIND/set 
into a temporary object.
Steeve
27-Apr-2009
[13572x3]
Oh the FOREACH overhead has been reduced ?
nice news
not anymore  bind/copy with FOREACH ?
BrianH
27-Apr-2009
[13575x2]
The BIND/copy overhead is still there, but being able to use FOREACH 
on map!, object!, module!, port! and error! means that you don't 
have to generate a block! copy of those types in order to work on 
them. Plus you don't need the EITHER or CASE to screen for those 
cases.
In general the size of the code block passed to FOREACH is much smaller 
than the size of the data passed to it.
Steeve
27-Apr-2009
[13577]
foreach works now on ports ? are you sure of that ?
BrianH
27-Apr-2009
[13578x2]
In theory, but I think it works on the port fields as if it were 
an object, not on the returned data.
I haven't checked though.
Steeve
27-Apr-2009
[13580x2]
Uhm, was not my request, it would be more usefull to be able to use 
FOREACH as an ACTOR in a scheme.
So on data, rather than to populate properties of an object port
BrianH
27-Apr-2009
[13582]
Yeah, I didn't request that either. Did you file a CureCode ticket 
for FOREACH on ports? I recall some overly general ticket you filed 
that was requested to be broken up iinto individual tickets, but 
not the individual tickets.
Steeve
27-Apr-2009
[13583]
have to
BrianH
27-Apr-2009
[13584x3]
Ticket 556.
You might be a little late here - port! has been added to the any-object! 
typeset (I can't say for sure). You gotta file tickets if you want 
to get things done.
At least on a native level. On a mezzanine level you can do it yourself, 
as long as it's a good idea :)
Steeve
27-Apr-2009
[13587x2]
uhm, the any-object! type is troublemaker
Port should not be in it, to allow functions to behave as scheme 
actors
BrianH
27-Apr-2009
[13589]
It's not a type, it's a collection of types (typeset!). In this case 
a collection of the types that act like objects.
Steeve
27-Apr-2009
[13590]
i'm aware of that, don't do a disgression
BrianH
27-Apr-2009
[13591]
It's just there so you can use it in function specs for functions 
that act on objects to let them act on other object-like things, 
when they are being sed in object-like ways.
Steeve
27-Apr-2009
[13592]
I'm not sure, but i just think there is a difference in the way of 
treating the argument any-object! and object!
In the first case the port is populated like an object.
In the second, the function is usable as an actor for schemes.
It's really different use cases, I hope i'm wrong here.
BrianH
27-Apr-2009
[13593]
If you want FOREACH to work on ports in a certain way, you need to 
write a ticket for that. Mentioning it here won't accomplish anything, 
as Carl almost never sees the stuff we write here.
Steeve
27-Apr-2009
[13594x2]
see the arguments of COPY by example
copy don't use any-object! because of that
BrianH
27-Apr-2009
[13596x2]
COPY hasn't been changed to use any-object! - that may yet happen, 
but any-object! is too new for it to have propagated yet.
I doubt it, as COPY doesn't act on error! and task! in an object-like 
way.
Steeve
27-Apr-2009
[13598]
if i understand correctly how Carl managed generic behavior for the 
any-object! argument, COPY will never be changed like you think
BrianH
27-Apr-2009
[13599]
I doubt it
Steeve
27-Apr-2009
[13600]
Because it would remove the use case of COPY as an actor.
BrianH
27-Apr-2009
[13601]
Um, no it wouldn't. It would just allow error!, task! and module! 
to be copied too (which would be a bad idea).
Steeve
27-Apr-2009
[13602]
we will see, i just hope you're right here
BrianH
27-Apr-2009
[13603]
Typesets are just shortcuts for adding all of the types they contain 
to the function spec. They have no inherent meaning.
Steeve
27-Apr-2009
[13604x3]
ok
so actually they
you say Typesets are useless :)
Ladislav
27-Apr-2009
[13607]
hi


as far as I know it is possible to convert binary to decimal in R3. 
Is there already a reverse conversion?
Steeve
27-Apr-2009
[13608]
to binary!
BrianH
27-Apr-2009
[13609x2]
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.
Steeve
27-Apr-2009
[13611x3]
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 ?
Henrik
27-Apr-2009
[13614]
interesting that to-binary works for decimal, but not money.
Steeve
27-Apr-2009
[13615]
bah, you can store a fixed point decimal, what the need to store 
money ?