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

World: r3wp

[Core] Discuss core issues

Ladislav
12-Jul-2011
[1783]
This idea can only be expressed my way with my words.  

 - an error, again. This is not about "my words", this is about the 
 official documentation. You are free to not read it, and argue it 
 does not even exist, but that is not an argument for me
Steeve
12-Jul-2011
[1784]
The official documenbation  suffer the same bias. You're reacting 
like a monk in front off the holy bibble.
Ladislav
12-Jul-2011
[1785]
suffers the same bias
 - do not understand what "bias" you mean
BrianH
12-Jul-2011
[1786]
It's nice to have an official way to express a concept, but that 
doesn't help much if it isn't the common way that the community uses 
to express that concept. It doesn't help to refer to the manual if 
that manual has been rewritten since the last time the person you've 
been talking to needed to read it. Accept that there are community 
standard terms, and hopt that the better terms in the manual win 
out eventually, or at least before the manual is rewritten again 
with even better terms.
Andreas
12-Jul-2011
[1787]
To add more confusion to the mix, lit-arg(ument) and get-arg(ument) 
worked fine as terms in the past :)
BrianH
12-Jul-2011
[1788]
hopt -> hope
Steeve
12-Jul-2011
[1789]
the bias of having english words which can express several different 
concept
BrianH
12-Jul-2011
[1790x2]
Andreas, I like those :)
Steeve, the bias of using an ambiguous language like English to discuss 
a precise topic :(
Steeve
12-Jul-2011
[1792]
+1
Ladislav
12-Jul-2011
[1793]
Andreas, yes, those terms existed for quite some time....
Gregg
12-Jul-2011
[1794]
Those are my preferred terms as well.
Henrik
13-Jul-2011
[1795]
what is the fastest way to deep copy a large object?
Dockimbel
13-Jul-2011
[1796]
Try:
>> new: make object! third <object>
Henrik
13-Jul-2011
[1797]
it does not work for nested objects.
Dockimbel
13-Jul-2011
[1798]
Then, you probably have to write an recursive function that will 
copy all nested objects. Have you looked for such function on rebol.org 
and in power-mezz package?
Henrik
13-Jul-2011
[1799x2]
I need special functionality, so I will write my own.
Turns out it's far too slow.
Maxim
13-Jul-2011
[1801x2]
object creation/duplication in Rebol is very slow, the binding just 
kills it.  can you re-build your system with block?
(or parts of it ?)
Henrik
13-Jul-2011
[1803]
I'm going to copy the parts I need instead.
Oldes
20-Jul-2011
[1804]
>> select [1 2 2 3] 2
== 2
>> select/skip [1 2 2 3] 2 2
== [3]

Why the second returns a block?
Cyphre
20-Jul-2011
[1805]
iirc this is known behavior/issue in R2...has been unified in R3
Gabriele
20-Jul-2011
[1806]
Oldes, try it with a skip of 3 or 4 to see why a block is returned. 
Not very handy in the 2 case though... but I guess there was a desire 
to avoid special cases.
Maxim
20-Jul-2011
[1807]
/skip return records
i.e.  
>> select/skip [1 2 3 4 5 6] 4 3
== [5 6]
Oldes
20-Jul-2011
[1808]
I'm just missing MAP! in R2:

>> m: make map! [1 2 2 3]
== make map! [
    1 2
    2 3
]

>> select m 2
== 3
BrianH
20-Jul-2011
[1809x2]
Fortunately the /skip in SELECT/skip is ignored for map! in R3, so 
you can just use it in both.
Darn the R2 version does a copy/part. Silly differences.
Oldes
20-Jul-2011
[1811]
in R2:
>> make map! []
== make hash! []
>> m: make map! [1 2 2 3]
== make hash! [1 2 2 3]
>> select m 2
== 2

which is not what I woul expect
Geomol
21-Jul-2011
[1812x3]
Seems like map! is just redirected to hash! . Can be seen with
	? datatype!
, and that's probably confusing, as they behave differently.
Can also be seen with
	? "map!"
>> source to-map
to-map: func [value][to hash! :value]
Geomol
22-Jul-2011
[1815]
Is there an official documentation of
	make struct! ...
?

Is there documentation of constructs like #[none] ?
Pekr
22-Jul-2011
[1816x2]
http://www.rebol.com/docs/sdkug.html
see "External Library Interface"
Geomol
22-Jul-2011
[1818x4]
There it was, thanks!
I don't see doc about C datatypes in struct! spec block. I guess, 
it's the same rules as in routine spec block?
Example, where I use the C datatype, int:
	>> s: make struct! [i [int]] [42]
About constructs, off my head I have:
	#[none] #[true] #[false]

Are there others?
Gabriele
23-Jul-2011
[1822]
>> #[binary! "abc"]
== #{616263}
>> #[bitset! #{010203}]
== make bitset! #{010203}
>> #[block! [1 2 3 4] 3]
== [3 4]
>> #[email! "something"]
== something
>> #[file! "something"]
== %something
>> #[function! [a b] [a + b]]
** Script Error: none is missing its a argument
** Near: func [a b][a + b]

... and so on
Geomol
23-Jul-2011
[1823]
Is this documented anywhere?
Sunanda
23-Jul-2011
[1824]
Perhaps not, geomol. See this cc thread:
   http://curecode.org/rebol3/ticket.rsp?id=941
Ladislav
23-Jul-2011
[1825x4]
The "serialized" word is very inappropriate, e.g.:

    /all "Mold in serialized format"


does not say anything at all, since the format without the /ALL refinement 
is serialized as well (it is a text string).
Some other inappropriate notions:

   "serialized constructors", when used for #[none]


e.g. is a very unfortunate notion, since it is not a constructor 
(=a special function), not to mention, that it surely is not a serialization 
of such a function.
(my notes apply to the text of the curecode discussion to the above 
mentioned ticket)
Fortunately, according to Carl's note, the correct notion for the 
#[none] and similar formats seems to be:

    "specially escaped format"
Henrik
23-Jul-2011
[1829]
Does serialization not imply there is a reverse action for it? Only 
MOLD/ALL will allow that.
Ladislav
23-Jul-2011
[1830x3]
Hmm, that looks like a proper objection, but it does not take into 
account, that e.g.

    123


is a result of both MOLD as well as MOLD/ALL and it surely is serialized, 
while e.g.

    #[none]


is not just "serialized", it is a "specially escaped format", as 
noted by Carl
Moreover, MOLD usually does preserve REBOL code in the sense, that 
you get the same program when loading the result of MOLD more often 
than not.
While even MOLD/ALL does not look "reversible enough" for some functions, 
objects, etc.