AltME groups: search

Doc: "The only support I expect is R2 C-level bugs fixing."


Don't forget mezzanine bug fixing and the backports, which are community 
support. No new C-level features are likely, except for backported 
tweaks to the natives. New mezzanine-level features we can add ourselves, 
but remember that R2 is in compatibility mode right now. We shouldn't 
break the existing R2-compatible code if we can avoid it, since that 
compaatibility is the main advantage of supporting R2.


Future releases of R2 will have even more backported functions from 
R3, but these will be in a separate file of the source. It is likely 
that this separate file will need to be loaded if you want to use 
its functions, so there will be no new predefined words by default. 
You can load the file if you want to make your code more R3 compatible. 
This is likely the best way to ensure compatibility.

I've workaround it. It was only appearing on resetting workers using 
USR1 signal. Now I've fixed it and it seems ok. I'll release the 
fix tonight, so everyone can test it.

It is gzip data, and the to-binary was a hack.  It doesn't work either 
way.  I thought the REBOL script in the library, gunzip.r might work 
for me, but it is a rather crazy script that I don't quite understand, 
but the GUN in GUNzip.r shot me in the foot.

decompress wants a string, and binary is a string, so that's what 
made me think to do to-binary...

With all the retrospection going on, can I somehow get whole current 
namespace/memory image/state of rebol interpreter as a block and 
save it to a file for example?

ot at least all "user-namespace" , for example I define dew functions, 
and few variables, then I run app for a while, can I at some point 
get values of all my words ("variables" + functions) and "export" 
them

(and Doc)

Janko, what a lot of us do when we build a script is create one large 
object and build our functions and values off of it.

yes, I agree... I am asking because if this could be done then you 
could use rebol in a same way as smalltalk and factor are which are 
"image based" languages ... this brings some interesting usages..

for example a server that can replicate itself... or save it's state 
and then run from exactly same state, or in games, editing them without 
restarting... editing "live image" which should be possible because 
you can redefine words in rebol, but then you need to save whole 
current state.

Janko, I had left to shower and eat lunch.  Sorry, but you need to 
check the status on the left.  Often times we just disappear.  That 
is kinda what is nice about Altme in a sense is that you know when 
someone is available or here now by the status.

usage example: 

>> codes: [ [ a: 12 + 23 b: a + 100 c: b * a ] [ t: join "aaa" join 
"bbb" "ccc" find t "b"  ] ] 
>> para-do codes
35
aaabbbccc
135
bbbccc
4725
== [4725 "bbbccc"]
(it collects results of all blocks when done and returns them)

also.. something para-do could be made so that it would send code 
blocks to multiple rebol processes via tcp or pipes maybe and collect 
results back

it can do 1000 blocks with 5 expressions in 0.03s on my (little slower) 
comp , 10.000 in 0.25s , 100.000 in 3.75s ... so it seems stepping 
the blocks is not horribly slow, and I am sure my func could be made 
better

clearly, it could be faster but i'm not sure of the interest of such 
thing. If i want a small granularity in a process, i build tiny functions 
and push them in a to-do stack

ouch Brian, one second more and it was my reply :)

Tomc, you can't do copyless and get subseries, but you can build 
a block of before and after references.

The resluting block will be pairs of references to the beginning 
and end of his subseries. He can then get any subseries he needs 
by referencing it using the beginning and references with the /part 
option of COPY or INSERT, though using CHANGE or REMOVE will mess 
up the offsets of any subsequent references unless he is referring 
to a list! type.

a rose by any name ....  new and block both end up with the data 
so it is still copying

Ahhh! I see  hmmm  I think all I will  need to do is reorder *between* 
references and subject those  sub-blocks 
 to further partitioning

The new block is really an index (in the database sense). You can 
sort and manipulate the index, then use the result to build a new 
version of the data if you like.

positions get messed up if and only if the end points of the sub 
range are shuffled in the sort ...

and as their index can be known  beefore hand they can be reset if 
needed. i think

However, sorting the index won't change any of the references that 
the index is pointing to, because the underlying data doesn't change. 
Once you are done sorting and manipulating your index you can commit 
the changes, which means building new data from the index references.

all movement between (and including ) two reffrences stays between 
those same two reffrences

and yes the span (# of columns) is the same  for sorting and skipping

the initial offset  (which column)  the sort is on changes, but that 
is 
sort/skip/compare/part  ref1 span   column  ref2

Brian's concern is what does this sort do to ref5 and ref 6  position. 
are they still valid.

time to experiment

thanks Brian and Steeve. good night

how can this avoided?


does a object! defined within a object! (embedded) breaks with the 
clone/ingherit rule?

calling a function within a object! which e.g. changing a value within 
the embedded object!
changing the parent AND the child object!.

template: make object! [
	obj-in-obj: 	make object! [a: make integer! 0]
	b: 		make integer! 0
	c: func [val] [
		obj-in-obj/a:   val
		b:		val
	]
]  

wcopy: make template []
probe template
probe wcopy
wcopy/c 1000
probe template
probe wcopy

what I am doing wrong here?
and is there any easy way to clear a object at once
without resetting every single variable in the object

I have a big loop (20.000+) which fills many objects with datas.
the objects contains also functions writing and calculating
data within other objects (all within a global context/object). 

each loop is a new run, so I need a new or cleared set of objects 

for every loop. looks like cloning doesn't work for me (see above). 

I could reset every single value, but this will cost me a day minimum.

do I overseen some simple solution here?

Why you do not make your template just an unevaluated block and then 
you always generate a new object or you never change your template, 
just the descendants ?

You need a 'make-deep function that (recursively ?) digg into the 
copied object and copy each subobject it find. I'm sure people arround 
have one in their HD (not me).

YES! thx a lot graham and paul. it works.

TomBon, keep in mind that you can create the spec for an object and 
use it as your template as well.

yes but the objects also containing functions and nested objects 
etc. graham approach is very compatible with the current codebase 
I have so far but thx for reminding me with this paul.

What was confusing me is assignment and how it works with lit-word

It's always felt consistent to me - the context is being evaluated, 
and lit-word!s reduce to word!s, word!s reduce to functions and values, 
while other datatypes reduce to themselves:
>> X: [{One} 'Two]
== ["One" 'Two]
>> ? X/1 ? X/2
X/1 is a string of value: "One"
X/2 is a lit-word of value: 'Two

>> X: reduce X   ;Here is where typing it in on the terminal evaluates 
to
== ["One" Two]
>> ? X/1 ? X/2
X/1 is a string of value: "One"
X/2 is a word of value: Two
>> X: reduce X
** Script Error: Two has no value
** Near: Two

...and the reasoning behind lit-word!/word! acting differently is 
that those are special datatypes where other values can be bound 
to them

(I participatted in this discussion already one time and it also 
seems consistent to me)

Paul: I think Brian or Henrik told that time that 'word is "active" 
something and rebol reduces it when encounters it in the same way 
as it would auto-reduce function a: get-two not assign it to a (at 
least that was my compilation of it that time :) )

and we all know that blocs don't get evaluated / reduced by itself 
so [ word ]  stays [ word ] even fi word is undefined or func or 
anything so [ 'word ] also stays [ 'word ]

That makes no sense to me Janko.  By the way it was me and Henrik 
that both thought it was inconsistent.

Paul, it is consinstent:

read first word - it's >lit-word?<
evaluate it - it's a function that takes one argument

read second word (first and only argument for that function) - it's 
>'test<
evaluate it - lit-word! evaulates to word!
pass it to the function - word! is passed, not lit-word!

See I read the documentation on lit-word? and it states:

Returns TRUE for lit-word values.

yes, I get this delete example :) good point ,... I would have to 
look in what manner I used blocks with "random" words (if I did) 
to see what could happen..  I did some when I was playing with dialects.. 
and to store data in [ key "value" ]  manner

is make-two a function ? it is but when you write it it gets evaled 
to 2 and if you write >>function? make-two<< you get false , same 
here it is but it get's evaled to word

And REBOL does see 'test as a lit-word.  A trace shows this:

>> string? 'test
Trace:  string? (word)
Trace:  'test (lit-word)
Result: false (logic)
== false

Does this help?  X contains the code you see and type, the lit-word! 
typed in.  It gets reduced to its word value..
>> X: [type? 'one]
== [type? 'one]
>> type? X/2
== lit-word!
>> do X
== word!

how do you make this trace (I never used it, and also don't understand 
what exactly it shows)

And the interpreter converts it to a word! before passing it to 'lit-word?

Rebol, the interpreter, sees a lit-word!.  Trace shows this.  It 
*then* evaluates it to a word!, *then* passes it to lit-word?, and 
lit-word? never sees the original lit-word!

first is function! that gets evaluated. it takes one argument - block! 
that argument is also evaluated and block! is evaluated to block!. 
then it returns first value of that block. this value is not evaluated 
- but that's ok, it's 'first's behaviour

But it's better to submit it as a wish into CureCore and see what 
Carl means

Izkata, I'm sure that REBOL is written in C language and in C we 
use a char type for this.  So it is possible to detect the ' character.

And here?
>> get-word? :test
== false
>> type? :test
== lit-word!

If you want DO to just get a value and not treat active values as 
values, use a get-word expression. This is evaluation model stuff. 
You need to be able to distinguish between the data that your code 
is working on, from the data that your code *is*, itself.

The difference is between your data:
>> ['a]
== ['a]
and the data of the DO function:
>> 'a
== a


Just because your code is data, doesn't mean your code is *your* 
data. It is actually DO's data, and DO interprets its data as what 
we think of as the REBOL syntax. I didn't see you complain that the 
set-word! in your code was treated as an assignment, or that the 
word! print is treated as a function call. The treatment of lit-word! 
values *in code* is no different from those.

It looks like what Paul wants is for lit-word? to take its argument 
literally. eg:

	*lit-word?: func ['val][lit-word? :val]
	*lit-word? 'hello ; == true


but this ends up causing problems, as discovered elsewhere with functions 
taking arguments literally, eg:

	my-val: first ['hello]

 *lit-word? my-val ; == false    <---------- Unexpected because MY-VAL 
 taken literally.

and


 *lit-word? first ['hello] ; == ['hello]     <----- Unexpected because 
 FIRST was not evaluated.

Paul, in REBOL 'test is a lit-word!. The problem is that you are 
getting datatypes and evaluation rules mixed up. When you are evaluating 
your own data, you can treat lit-words any way you like. When DO 
is evaluating *its* data (what you would call normal REBOL code), 
it treats lit-words as active values. Active values are normally 
evaluated when DO encounters them - the only exception is when they 
are just retrieved from some word they are assigned to, either using 
GET, or DO's shortcut for GET: get-words. All of DO's active values 
work this way.


And there is a good reason DO treats lit-words as active values: 
If there were no active lit-words, DO wouldn't be able to refer to 
word values without breaking words as variables, and normal REBOL 
code would cease to function.


When I say that it is not a bug that lit-words are active values, 
I am understating things. What is really the case is that lit-words 
being active values is the *entire reason for their existence* - 
if they weren't active values, there would be no point to them at 
all. Oh, and REBOL code wouldn't be able to work with its current 
syntax.

I have no beef with DO and how it works elsewhere.  Again, only how 
lit-word? and other functions work in that regard.

and 'test is a lit-word

You aren't passing 'test as an argument to LIT-WORD? whenn you do 
this:
lit-word? 'test
==false

What you are doing is *evaluating* 'test and then passing *that* 
value to LIT-WORD?. There's a difference.

When, you've typed something at the console:

	>> 'test	

, and you press Enter, it is as if this is happening in a script:

	do ['test]


The result is equivalent - a lit-word reduces to a word, which is 
returned.

yes, and
>> lit-word? 'a
can be written as
>> do lit-word? do 'a
or 
>> (lit-word? ('a))

I made one that works like I want and it doesn't use lit-word? at 
all

And many agreed with him are wrong also.

Here is what BrianH said:


You aren't passing 'test as an argument to LIT-WORD? whenn you do 
this:
lit-word? 'test
==false

What you are doing is *evaluating* 'test and then passing *that* 
value to LIT-WORD?. There's a difference.

Brian is saying that 'test would get evaluated to a word and *THAT* 
value is then in turn passed to lit-word? function.  But that isn't 
the case.  Because if it was indeed a word! at that point then there 
is no way my function could detect it as a lit-word!

You can use that also Doc and it still works.

And that is what it does, right? So no problem there?

Just add one function:


quote: func [
	"Returns the value passed to it without evaluation."
	:value [any-type!]
] [
	:value
]


And you can pretend that there are no lit-word!, get-word! or set-word! 
types. It needs R3's get-word! parameter semantics though.

Paul, you have answered Henrik's question: make logic! works like 
C code, returning true when C would. TRUE? returns true when REBOL 
would treat it as true, not C. TRUE? is useful for AND, OR and XOR 
as well.

It was Carl's function, and he *needs* it for his code, so TRUE? 
will definitely be a mezzanine, not a library function.

So in R3, zero is true and other than zero is false? I remember something 
about this. Why was it made this way?

I think TRUE? provides equivalent evaluation to TRUE or FALSE in 
the case for IF and EITHER. Often you won't need to convert some 
type to logic! in order to evaluate it with IF or EITHER, but TRUE? 
allows you to display what IF and EITHER would evaluate to and it's 
necessary for PICK. I did not know it was different from make logic!, 
but to me it this difference just makes TRUE? more valid and important 
in general.

Paul, in R2 and R1 as well. The code is exactly the same.

Just do one script and you can start porting your code. And it works 
in 2.6.2.

Paul has deciphered the plan. I think it should stay a separate script. 
It breaks tons of R2 code. I expect that we won't be doing a 2.7.7 
soon, and when we do it will just be compatible bug fixes. The future 
compatibility stuff will be in the R2-Future collection.

And no new natives in future R2 versions, just compatible fixes to 
errors in existing natives. The only changes will be to make less 
behavior cause errors. And you can include R2-Forward in one line 
of code now, in 2.6.2 even.

Brian, I suggest not waiting for Carl and just offer a library of 
 all the mezzanines that can be incorporated by just 'DOing the script 
to import them.

Mezzanine code has license restrictions. I can only release this 
at all because I wrote almost all of the original mezzanines and 
didn't assign copyright to REBOL Tech or Carl.

Henrik, the R3 changes to the graphics and port models are not supported. 
The post-2.7.5 R2 VID changes are not R3 compatible (nor is any R2 
VID or RebGUI code) so they should go in another file, which I think 
should still be external if it would break existing R2 code.

The whole point of this is to make new R2 releases mostly unnecessary, 
and nothing to wait for for most people.

Yes, and then release it. Don't wait for a new R2 release.

I have some plans for such a kit, but it depends on if I will get 
time to do it and if it collides with R3 GUI development. It involves 
removing some parts of the current VID, like the WindowsXP style 
buttons and making SET-FACE and GET-FACE uniform for all styles. 
Also adding some new styles and the new resize scheme would go under 
that. It would make VID way less painful to use.

It's about half done and I have a bunch of code files for this. I 
was going to use it for a large VID project, but it has been dropped, 
cutting away 6 months of work for me (phew!).

BrianH, what happened to the idea of including prebol in R3? And 
if it goes in, would it be included in R2-Forward?

A1: Still under discussion, and won't happen before the module rework. 
A2: Yes.

For that matter, after the module rework so will modules, to the 
extent that I can do it. Probably based on Gabriele's code if I can 
convince him to MIT it - his code is currently BSD, and BSD's non-promotion 
clause may be at odds with the extensive attribution I've put in 
R2-Forward. That's why I used MIT: BSD licensing is too restrictive.

The same goes for pre-open-source Java and .NET code on the MS runtime 
instead of Mono: No GPL2 code, and no static linking of LGPL2 code, 
even if you do provide the source. You gotta use an exception like 
Classpath to use (L)GPL2. (L)GPL3 fixes this.

wow, thanks. Now I understand rebol put inside the second elemet 
"-" and not between the first and the second.

Probably based on Gabriele's code if I can convince him to MIT it 
- his code is currently BSD, and BSD's non-promotion clause may be 
at odds with the extensive attribution I've put in R2-Forward. That's 
why I used MIT: BSD licensing is too restrictive.

 - Brian, first, you are being paranoid about BSD, second, the license 
 for my code has not been decided yet and I have no preference for 
 BSD over MIT over anything else.

You can always take a windows path, or UNC path and convert it

to-rebol-file \\bens2000as\c$\myTestdir

Cheyenne is listening on port 8002 and gives a 404 if a browser is 
used.

I've asked the user to install Firefox and make it the default browser 
to see if that helps.

So, if the user has an empty value in the registry for the default 
browser, I guess that would cause this ...and :arg1 would be the 
browser .exe

kib2: "Does that mean that we can use unicode encoding with the help 
of r2-forward ?"

No, I only can only spoof datatypes that don't exist in R2, and R2 
has a string! type. The code should be equivalent if the characters 
in the string are limited to the first 256 codepoints of Unicode 
(aka Latin-1), though only the first 128 codepoints (aka ASCII) can 
be converted from binary! to string and have the binary data be the 
same as minimized UTF-8.

There are ASCII? and LATIN1? functions that test, char!, string!, 
binary! and integer! in exactly the same way as the R3 natives, and 
a UTF? function that tests the BOM. When ENCODE and DECODE are written 
in R3, I'll backport them too if I can, though they probably won't 
generate string! values.

See the notes for what can and can't be supported. The unsupported 
list may grow or shrink with changes to R3 or more information.

What is the etiquette for using metadata in a REBOL header?  Here's 
some scenarios:

A) From Viewtop:

	REBOL [
		type: 'index
	]

	title "My RebPage"


This is clearly ok, and a good way for an application to determine 
the disposition of data - in this case a Dialect.

B) I use this for QM modules:

	REBOL [
		type: 'module
		exports: [do-something]
	]

	var: 1
	do-something: func [val][val * var]


This adds a little more, as the 'exports block is more than just 
an 'id, it's contents are bound to the application.  Moreover, 'exports 
is not in the standard header.


C) A hypothetical dialect definition with some 'do code (I'll use 
VID to demonstrate):

	REBOL [
		title: "My Application Window"
		type: 'vid
		locals: [mybtn myarea]
		on-close: [save-all quit]
		options: [resize min-size (config/min)]
	]

	h1 "My Small App"
	myarea: area "Some Text"
	mybtn: btn "Submit" [save-all]



Now obviously all these cases can be fleshed out with R2, but is 
this abuse of the header?  There's still no security issue 'loading 
the file, indeed it takes a special handler to actually execute the 
code.  But again, is this taking the header where it shouldn't go? 
 What of R3?

my own rule was, if its something you can edit and don't want to 
have to "look" for in the code, its ok.