AltME groups: search

You are missing the point, why don't you read the THRU documentation 
instead of speculations?

parse [a b c] ['aAND'bAND'cEND]
hmm, yeah, you've got a point.

[any end]Êand [some end]

As we don't have warnings, I suggest these to produce errors. They 
can produce endless loops, and that should be pointed out in the 
docs, if they don't produce errors.
[opt end]

Yes, it's legit, but what's the point of this combination? At best, 
the programmer knows, what she does, and the combination will do 
nothing else than slowing the program down. At worst, the programmer 
misinterpret this combination, and since it doesn't produce an error 
or anything, it's a source of confusion. I suggest to make it produce 
an error.
[into end]
Produces an error today, so fine.
[set end ...] and [copy end ...]

I wasn't thinking of [set var end], but about setting a var named 
end to something, like [set end integer!]. Problem with this is, 
that now the var, end, can be used and looks exactly like the keyword, 
end, maybe leading to confusion. But after a second thought, maybe 
this being allowed is ok.
[thru end]

Making this produce an error will solve the problem with the confusion 
around, what this combination mean. And in the first place, it's 
a bad way to produce a 'fail' rule (in R2, in R3 it has the value 
true, and parsing continues). It's slow compared to e.g. [end skip].

If you're going to make a better parse, it might be good to take 
into account the efforts that have already started to improve it 
in R3. The R3 improvements need a little work in some cases, but 
the thought that went into the process is quite valuable.


[set end ...] or [copy end ...]: In R3, using any PARSE keyword (not 
just 'end) in a rule for other reasons triggers an error.
>> parse [a] [set end skip]
** Script error: PARSE - command cannot be used as variable: end

[any end] or [some end]: What Ladislav said.


[opt end]: The point of the combination is [opt [end (do something)]]. 
[opt anything] is no more useless than [opt end]. Don't exclude something 
that has no effect just for that reason. Remember, [none] has no 
effect as well, but it's still valuable for making rules more readable.

I almost agree. Here we use comma as decimal point. A few countries 
does that. So all data with money amounts have numbers with comma 
as decimal point here.

BTW, the limitation of CASE to just the next rule is not exactly 
necessary. I would like to point you e.g. to the description of the 
#localize-on #localize-off user-defined directive pair, which is 
defined so, that it will not have any problem with multitasking or 
recursion, yet the directives are not limited to just the subsequent 
value. (Robert plans to publish the source code and the documentation 
soon)

I figure it might be worth it (for me at some point) to do some test 
exports in native format in order to reverse-engineer the format, 
then write some code to generate that format ourselves. I have to 
do a lot of work with SQL Server, so it seems inevitable that such 
a tool will be useful at some point, or at least the knowledge gained 
in the process of writing it.

please guys keep in mind we can't fix all bugs at once. and we can't 
usually fix two "big" bugs at once (big means it takes a lot of time 
for Carl to figure it out). so we fix one big bug and many small 
ones (bugs that can be fixed in a couple minutes always have precedence 
because there's no point in making them stay for years on rambo).

Thanks, Gabriele.....My collection of REBOLs are a point release 
or two behind

is point #1

2.7.7 release

Call
dockimbel:

About CALL console window issue, the CreateProcess( ) win32 call 
has flags to hide the window. There just need to be set.

In the STARTUPINFO used by CreateProcess( ), just set in dwFlags, 
the STARTF_USESHOWWINDOW flag and set wShowWindow to SW_HIDE.

maybe add a new refinement and let the users decide when they want 
to see the console window ?
or maybe just /show

Paul:
Run is not enabled

Graham

Is anyone concerned that shell windows opened in Encap do not contain 
the correct window title?
Rambo #3660 ( reported march 2005 )

Brian

For me, the big question is what kind of release we will be doing:

- 2.7.7: Patching glaring bugs in a few natives, VID fixes, and continuing 
the backports and mezzanine fixes.

- 2.8.0: Backporting some of the R3 native changes (function, not 
infrastructre), and the above.

I think that the decision a long time ago was to focus on R3 as a 
priority, and just patch up R2 as necessary.

At the very least, I would want a 2.7.7 to have a version that fixes 
post-2.7.6 mezzanine bugs, and 2.7 series regressions vs. 2.6.3.

Henrik
We also need to implement BrianH's new window resize scheme.

Ashley,Anton, Brian, etc ... VID fixes

Graham
Fixes to prot-http to support put etc.

BrianH

SQL_FLOAT and SQL_REAL are converted the same way, just with different 
sizes. And yet SQL_REAL works and SQL_FLOAT doesn't, at least with 
SQL Native Client (an ODBC 3.5 driver). Perhaps that difference can 
point you in the right direction.

Henrik
view/new make face []
a: open/binary/direct/no-wait tcp://:9000
forever [wait reduce [ a 0.001]]


This produces a 16 byte leak when started. And when I move the window 
and click in it, I get a lot of 64 byte leaks.

Graham, thanks for copying over those priorities from R2-Beta to 
here. About how those choices were made and phrased:


The R2-Beta world was used when we still thought of REBOL being updated 
more rarely, in larger increments. This is no longer the case, we 
are adopting the rapid release model, though more regulary than the 
R3 alphas. We need to shift our thinking accordingly.


Rapid release means that each individual R2 release doesn't have 
to include fixes for every outstanding bug. We can and will triage 
and prioritize, and your favorite bug may be moved to the next release. 
Which won't be a problem because that's coming next month, or the 
month after. Minor point releases will not be a major deal from now 
on, they will be monthly occurances.


The overall plan for the R2 2.7.x series is to fix what we can in 
R2 in a way that doesn't break things. This won't be a ground-up 
rewrite, as we are doing one of those already. No major model changes, 
just tweaks. There is a lot we can tweak though, including natives. 
We are trying to avoid disruptive changes that affect scripts at 
runtime, except in cases where things just didn't work before. Almost 
all code that works on 2.7.6 should continue to work - that is our 
goal. Don't expect broken code to stay broken though :)


The 2.7.7 release will not be ambitious, we just don't have the time. 
The priorities are business model changes and low-hanging fruit. 
The one piece of major breakage from the 2.7.x series that needs 
fixing in this release is the installer. If you have other priority 
fixes that can't wait til next month, and you are willing to do the 
work in this week, please speak up.

2.7.7 release

Call
dockimbel:

About CALL console window issue, the CreateProcess( ) win32 call 
has flags to hide the window. There just need to be set.

In the STARTUPINFO used by CreateProcess( ), just set in dwFlags, 
the STARTF_USESHOWWINDOW flag and set wShowWindow to SW_HIDE.

maybe add a new refinement and let the users decide when they want 
to see the console window ?
or maybe just /show

Paul:
Run is not enabled

Graham

Is anyone concerned that shell windows opened in Encap do not contain 
the correct window title?
Rambo #3660 ( reported march 2005 )

Brian

For me, the big question is what kind of release we will be doing:

- 2.7.7: Patching glaring bugs in a few natives, VID fixes, and continuing 
the backports and mezzanine fixes.

- 2.8.0: Backporting some of the R3 native changes (function, not 
infrastructre), and the above.

I think that the decision a long time ago was to focus on R3 as a 
priority, and just patch up R2 as necessary.

At the very least, I would want a 2.7.7 to have a version that fixes 
post-2.7.6 mezzanine bugs, and 2.7 series regressions vs. 2.6.3.

Henrik
We also need to implement BrianH's new window resize scheme.

Ashley,Anton, Brian, etc ... VID fixes

Graham
Fixes to prot-http to support put etc.

BrianH

SQL_FLOAT and SQL_REAL are converted the same way, just with different 
sizes. And yet SQL_REAL works and SQL_FLOAT doesn't, at least with 
SQL Native Client (an ODBC 3.5 driver). Perhaps that difference can 
point you in the right direction.

Henrik
view/new make face []
a: open/binary/direct/no-wait tcp://:9000
forever [wait reduce [ a 0.001]]


This produces a 16 byte leak when started. And when I move the window 
and click in it, I get a lot of 64 byte leaks.

Thank you Carl, Brian for updating the Rebol/View. SSL/TSL has become 
such key module of any serious internet trafic during last decade 
that it's important to be part of the widely available version. I'm 
sure there are plenty of other important Fixes and new features on 
this release, but at this point  with my  limited knowledge of Rebol 
variants (still trying to learn all there is at the 2.7... ) it's 
the thing for me.

For R3, we can get TLS, because the code would be in the open source 
portion. For R2 only the mezzanine changes are open source. This 
means that you'd have to ask Carl about TLS support - and he'll probably 
point you to REBOL Consulting :)

what's the point of returning the prior value instead of the new 
value?

Just  a question of Rebol docs.. (at this point Rebol2 preferred), 
If I want to find all necessary (and possible) stuff of Serial port, 
where shoud I look? I woudl like to set various speeds on Serial 
port, also control DTR line manually..  That kind of stuff is needed 
on Propeller Downloader since it uses DTR to toggle microcontrollers 
reset line. And if possible in a way it is portable (no DLLs ?). 


(page 4 ) http://www.parallax.com/Portals/0/Downloads/docs/prod/prop/PropellerDatasheet-v1.2.pdf

so I can point to or find entry 34672 quickly in a debug session 
dumped to a file.

The point would be, were tables done correctly in RebGUI, that the 
pretty print formatting would come at cell rendering time rather 
than as input to the table. In the work I've been doing, Cyphre changed 
table for me so that it would allow sorting on strings that contain 
numbers.

I'm not yet to the point of agreeing that this is a registry problem.

But yes, good point :)

I have come across a strange problem with View 2.7.7 on Mac OS X. 
If I load a library, run a function from the library and then put 
the machine into sleep mode, Rebol crashes with a Floating Point 
Exception when the machine wakes up. Here is ahte console session:

>> mylib: load/library %Code/Pascal/libtestlib.dylib
>> add1: make routine! [a[int] return: [int]] mylib "myfunc" 
>> add1 12
== 13
>> Floating point exception


I compiled and tested the library under Windows, put the machine 
to sleep, no problem when it woke up. (I was running Windows as a 
Virtual Box VM).

Any suggestions?

ICarii, what I did, was studying DPaint filling the screen, and then 
figured out, how to do it. It's a scanline filling algorithm. In 
short, it goes like:


- Search left and right for other colors from the point clicked on 
screen. That defines the first scanline.

- Look at lines above and below starting from the end-points of the 
first line. This defines 4 new points to look at.

- Again search left and right for other colors. Make sure, the whole 
area between the end-points are searched.
- Put it all in some list, and continue, until the list is empty.

A good way to test it, is making a lot of vertical lines on the screen 
with spaces in between, and not drawing them all the way to the border 
of the image. Then fill from some point at the center of the screen 
and see, how the filling is being split up into many separate fillings.

ah - i went with a push/pop stack and a 4 point scan

my point is that install is very annoying for people who develop 
because it creates a dependency in the interpreter which cannot be 
rooted out.


I am not against the installer, i'm just against it being forced 
upon me, when the whole platform itself has no requirement for it


I have not started REBOL without it requiring an external file or 
socket in what 10 years... so really what is the point.  it just 
makes EVERYTHING complicated, like telling clients they have to fuck 
around with adding -qs all the time in their batch code, etc, etc.

That is platform-and-computer-specific. And the user files will be 
in a different place for each user - that's the whole point of them. 
Is it really so hard to put files in the standard user directories?

that's the point of having a full VM installed in the transition 
period.  yess it takes disk space, but at least you only keep the 
legacy things within the legacy environment.  they could have gone 
100% 64bit for example and not have to support 32 bit modes within 
the 64 bit and also distribute a 32 and 64 bit version, things like 
that where there are already many *current* apps which fail in one 
or the other.  my friend can't get her camera to work on windows 
7 cause its only compiled as a 32 bit app (drivers and all).  but 
she was forced to use a 64 bit win7 because of support issues.

but that's not a uri  ;-)   the point of the url datatype is that 
we shoudn't need to use "specifications" but uri paths.

nve - what is Henrik trying to point out imo, is the fact, that it 
is not that easy to change look of R2 VID and stay consistent. I 
think that with VID3 it is going to be easier, as the system is more 
and better abstracted. It might be easier to do the job for R3, than 
to R2. I believe R3 is going into beta sometimes ... when Carl re-appears 
 + 2-3 months :-)

There will always be a name conflict somewhere. That is why we have 
an override policy. Of course anything unexpected will be surprising, 
but in this case the unexpected thing is that there was a name conflict 
in the first place, not the behavior of the system in reaction to 
the conflict. That is of course assuming that the developer has read 
the docs, and that we have written them, neither of which I am really 
assuming at this point.

Strangely enough, the whole point of the lib runtime library is to 
manage overrides. That is why we don't have explicit import by default 
too.

You can load your extensions delayed. Beyond the pre-delayed extensions 
the "user" should probably not be loading them. Unless the user is 
you, at which point you know. Modules are imported into the system, 
they aren't sandboxed.

At which point it makes a _lot_ of sense to not artificially hide 
an R3 extension's nature as dynamic library and just use the platform-specific 
conventions.

I've used a few applications which have their own extension names 
simply because there is a lot of overlap in names and clashing with 
the OS is very easy at some point.

I want to be able to setup a R3 config file that says:

extensions-dir:  %/some/path/


and then R3 will only ever load extensions from there.    the extensions 
can do whatever they want, but we have a controled point of entry 
within REBOL.

afaik, systems allow paths on dlopen.    rebol would simply always 
ask for libs with paths... 


in fact, on windows, that is how you are supposed to do it, probing 
the registry first to get proper paths for libs.

And point well taken: you don't want the "system paths" searched, 
esp in the context of Win32.

My whole point is: you want those paths _preferred_, but ultimately, 
if you don't find an extension in those paths, you should just fall 
back to the OS loader's search path mechanism.

While there wouldn't be a point to the OS managing REBOL modules, 
because it doesn't know what they are

prudent to stick with the standard .so extension

 - I'm having a little trouble understanding this, but maybe that 
 comes from too much experience with platforms where it has been demonstrated 
 that there are advantages to distinguishing between different dynamic 
 library types by using different file suffixes. The "standard .so 
 extension" means that these differences get put somewhere else in 
 the filename. But I can see your point with libraries like System.Data.Sqlite 
 that support more than one calling convention in the same file, so 
 that the R3 extension API would just be added to a system dynamic 
 library that is otherwise meant to be called by non-REBOL code - 
 incorporating its own wrapper extension.

Most words won't be "global" unless they are exported from a module 
(at which point they will be in the lib context) or system internal 
(sys context). User script words are in a task-local user context 
(once we get that working), and module words are in module-local 
contexts. I'd be shocked if most callback functions weren't at least 
module-local, or often in hidden inner contexts.

Cyphre - just some friendly opinion exchange, hopefully you will 
be able to understand my explanations (which don't necessarily represent 
my exact point of view):


- most ppl here are well aware of the fact, that RMA is a business 
entity, and hence has absolute right to do what makes sense for its 
business. The trick is, that in the end, it does not work for ppl, 
I will tell why later.


- The point above is even more difficult to understand, as RMA is 
offering its work for free, yet ppl still complain to something (including 
me of course)


- What might have failed is, that ppl might think, that accepting 
SCRUM method will mean, that we have finally found a viable model 
for  general R3 development, which will allow Carl to stay available 
 to small agile team of developers, isolated from the noise.


- Ppl were expecting GUI to probably appear in 2-3 month period. 
Althought Carl's GUI worked mostly on the surface, it was something 
ppl could experience. RMA's aproach is much broader aproach to usability 
and architecture. But - that resulted into refusal to provide usable 
demo. There was some attempt to provide style browser, but it was 
highly unusable to attract ppl.


- RMA seems not to understand (or it is not its priority) the importance 
of visuals. You surely remember the "design sells" claims, which 
are know for ages. Do you remember your Rebcon AGG demo? So much 
joy, so much applause. The current look of the GUI and its metrics 
just ruined the "hmm, nice" first look experience, and for no apparent 
reason, then constantly repeating "the skin will be done later". 
If so, it should not have been changed in the first place. (After 
porting the demo, my next area to play with is to try to play with 
material system, etc., and box-model style metrics)


- Ppl are well aware, that RMA is mostly on its own, and that even 
SCRUM methog did not work in regards to keep Carl attracted to such 
method in the long run. We are now facing the worst ever period of 
R3 development, where Carl apparently has some other projects, and 
R3 is almost stalled. Ppl are clever enough to realise, that we are 
being fed with some mid-time blogs, which should keep us distrated 
from the facts (huh, rebol file suffix importance anyone?), and we 
are also facing rushed releases as A111 is, and 2.7.8. was. You are 
free to not agree, but that is how I personally feel about the situation 
towards the RT. In the past I would probably write some letter to 
Carl, but I am at the point where I think, that RT is effectively 
burrying R3 under month by month. So - Carl is not able to find free 
time to continue with R3 development on a regular basis, and noone 
is denying his right to personal life, but - the fact is, that R3 
situation is at least - worrying. We wait for the beta plan for more 
than 4 months! If someone does not have time to even think how to 
proceed, then it is probably time to close the shop ... or open-source 
... but that will not happen. So - welcome the Amiga fate ... 


- And before someone else adds it, I will add it myself, as I believe 
I have my points right :-) Amen! Could I be wrong? Of course I could. 
You can easily state - hey, the situation is not like that, we know 
Carl works on this or that. Well - RMA knows, but that's it - the 
rest of the community is kept in information embargo from Carl. And 
that is difficult to deal with for many of us, who really like REBOL, 
and would like to see some coordinated development and the light 
in the end of the tunel once again ....

And now also - back to point 5, away from politics :-)


- New resizing model. Will API change too? Or is is just internal 
change, so I don't need to care about it, apart from knowing, that 
in some cases, resizing model will be more efficient?


- Is RMA building any commercial app using R3 GUI right now? Because 
I still might miss something, but style-wise I find it difficult 
to imagine, how it could be used. (Tables, lists, tree, area, tabs 
missing or buggy?)

Yes, it was your latest version. Other than Ladislav going on about 
it, this point is not worth discussing. The discussion clearly shows 
that Jocko helped me solve this situation

Ladislav, thank you for the link http://www.rm-asset.com/code/level1/r3-gui/
. The point is that this link is a presentation page, referring to 
a second one (downloads) which at last leads to http://www.rm-asset.com/code/downloads/files/r3-gui.r3
... the link that I used from the beginning. And so far I have no 
means to check if the file that I use is the latest one. Are you 
sure from your side that this file has been updated, and corresponds 
to the version issued 28th, january ?

yes, in real life buttons change colour neither when you point at 
them

electronic switches which are physical objects do change color if 
so designed

- I guess, that it does not suffice to point at them, you have to 
at least touch them,don't you?

I've done a few quite complex CSS setups working with jquery, and 
at some point, CSS selectors become very brittle because the priority 
rules become a bit hard to properly prioritize.   


To reflect this, in some setups not all browsers actually match the 
same CSS selection rules.

I prefer that max-size have some meaning. So if the size is set outside 
of max-size, the size should be constrained to max-size. That is 
the whole point of having a max-size setting in the first place. 
If a style has a max-size setting below max-int/max-int it should 
be there for a reason, and max-size can be overriden explicitly in 
the layout so it doesn't constrain unnecessarily.

as you can see from the discussion between Henrik and Ladislav - 
 not even RMA has unified point of view on how some features could 
be designed. So what is problem with me not eventually agree with 
what you cook behind the doors? :-)

Two notes:

- RMA is neither me, nor Henrik

- RMA has a unified point of view, it is the one you can observe 
when examining the published code and docs, all other things are 
just speculations

What users poll are you talking about? I do remember some, and when 
I can't take any preference, I don't participate. OTOH I put many 
comments in here. In fact - R3 situation is so "devastated" from 
the community point of view, that there is very little ppl participating 
in actually anything R3 related. Even in time of Carl's GUI, I might 
be the only public tester, may 1-3 other guys I remember. Where's 
all 300 ppl registered here with testing and comments? How much of 
input you get from any other person?

What I can see though, is a kind of syndrome of a developers, who 
live behind the closed door, and then wonder if another point of 
view is presented. It very often ends with statements like "you can 
take Carl's code, and do your own GUI". And I am far from alone receiving 
such a reply. And THIS is what I call as an insult, to ppl expressing 
different pov on the direction taken.

Maybe we're just tired of user polls, or we don't have the time to 
dig into this. If you don't have a clear view of what a good GUI 
should be, and therefore need polls, then maybe use some time to 
get a clear view. Only suggestions. :-)


I looked into it quickly, and I would at this point go for just have 
panel, letting vertical be a layout-mode option. Reason: K.I.S.S. 
(and vertical is an option anyway). And if you support user-defined 
styles (I'm not sure, you do, as I'm not very much into R3 GUI), 
then programmers can just make their own vpanels, if they need it. 
If I, as new to some GUI, can get it up and running in a very short 
time, because it's so simple, that's a huge benefit.

If you don't have a clear view of what a good GUI should be, and 
therefore need polls, then maybe use some time to get a clear view
 - interesting point, should make a note

I think that RMA resolves the situation somehow. My final proposal 
is:

- panel/vpanel
- panel as container name plus style, stays as is

- remove word "panel" from content handling functions. I never like 
three word function names btw :-)

This is just my opinion, your point of view might vary ...

One of the attractions of #1 is that it makes it easy to implement 
"default handlers" at some point higher up the hierarchy. For example 
based upon an  "esc pressed event" (if one were to exist.) and you 
had designed a panel with four buttons. If you wanted to close the 
panel when the user pressed esc, you would simply have a single "handler" 
for the panel which would receive the event.


I'm sure that this isn't  the best example and apologise in advance 
for my ignorance of REBOL3-GUI and its common terms.

It's a good point though Steeve.

how powerfull is a table style? I expect it not being full grid capable, 
as Cyphre did in the past, however what's the basic functionality 
to expect?


- column sorting - two state, or three state? (I don't like when 
I can't get back the original sorting = unsorted), but that's just 
my point-of-view, and not importan feature initially
- column filtering like in MS Excel
- how much data the table handles?

As for me - "I would like to help", and I will at some point, at 
least with testing. But got my own project 2Zone moving, awaiting 
LED Screen arrival and needing to do many arrangements. I can't surely 
code tree-view,but I can test, even privately, for anyone who asks 
me. Not much next 3-5 weeks though ....

Hi, first thanks for making and open sourcing power-mezz. 


I am trying to use load-html and am getting some strange results 
if sems it makes for example recursing [ html [ html [ html  ..... 
]]] on my simple html input (and on real one that I tried). I prepared 
two examples to make the point as clear as possible.


http://paste.factorcode.org/paste?id=2263(notice the stack owerflow 
error)

I don't know, but know that I need wchar at this point and don't 
have it:

https://github.com/rebolsource/r3-hostkit/blob/f331c6a46947e6e5afedc90f3d375bcd3f7ad8a1/src/agg/agg_truetype_text.cpp#L696

I can only say that Carl set the default, but I haven't seen any 
published scripts by him that use it. Good point, Andreas. Too bad 
we can't settle on .r, because R has taken that extension in most 
standard tools, and OSX uses .r for something else.

It was an expression I saw used at the beginning of R3 project. It 
was meaning "make things as easy as possible for non-programmers" 
like e.g., graphic designers, hence "bob the artist". "John the programmer" 
is an expression I used to make the point (I was thinking about John 
Carmack ;-)).

The last time i looked at Paul Graham's arc, that seemed to be stalled 
as well.  the point is that this is a huge undertaking for any single 
person

Onetom, that error has been reported already and fixed in R2/Forward, 
but it hasn't made it into R2 yet. Here is the revised MAP-EACH:

map-each: func [

 "Evaluates a block for each value(s) in a series and returns them 
 as a block."
	[throw catch]

 'word [word! block!] "Word or block of words to set each time (local)"
	data [block!] "The series to traverse"
	body [block!] "Block to evaluate each time"
	/into "Collect into a given series, rather than a new block"

 output [any-block! any-string!] "The series to output to" ; Not image!
	/local init len x
][
	; Shortcut return for empty data
	either empty? data [any [output make block! 0]] [
		; BIND/copy word and body
		word: either block? word [
			if empty? word [throw make error! [script invalid-arg []]]

   copy/deep word  ; /deep because word is rebound before errors checked
		] [reduce [word]]
		word: use word reduce [word]
		body: bind/copy body first word
		; Build init code
		init: none
		parse word [any [word! | x: set-word! (
			unless init [init: make block! 4]
			; Add [x: at data index] to init, and remove from word
			insert insert insert tail init first x [at data] index? x
			remove x
		) :x | x: skip (

   throw make error! reduce ['script 'expect-set [word! set-word!] type? 
   first x]
		)]]
		len: length? word ; Can be zero now (for advanced code tricks)
		; Create the output series if not specified
		unless into [output: make block! divide length? data max 1 len]
		; Process the data (which is not empty at this point)

  until [ ; Note: output: insert/only output needed for list! output
			set word data  do init

   unless unset? set/any 'x do body [output: insert/only output :x]
			tail? data: skip data len
		]
		; Return the output and clean up memory references
		also either into [output] [head output] (
			set [word data body output init x] none
		)
	]
]

Is there a point in allowing refinements like this?

/1a

Hm, maybe what I call integer refinements shouldn't be allowed at 
all, as I see no point in them. I can't get the desired path using 
integer refinements as in:

>> to-path [blk /2]
== blk//2

The correct way is:

>> to-path [blk 2]
== blk/2

So if integer refinements are useless, what's the point?

Crashes under OS X too:

>>  -1 * -2147483648
Floating point exception

well, difference in types is expected, its the point of having dynamic 
typing.  I don't think its a required feature for type casting to 
result in symmetric uses of other functions.    I expect to-from 
one type to another to be as symmetric as possible, but not what 
they mean in another context of usage.

I like that PICK is stopping point for none propagation. PICK data 
none should trigger an error, because otherwise you couldn't tell 
the difference between that and PICK [#[none]] 1.

We keep adding more points of none propagation, and every time we 
add one it makes more errors propagate further away from their point 
of origin. This makes it harder to figure out which code caused the 
error where none wasn't screened for or checked for, making it that 
much more difficult to debug.

The precision didn't change. The date! type has fixed precision, 
not floating point. All missing parts are 0.

My point is that I think it's an optimization that has bitten more 
than a few people

Keep in mind that times in REBOL and most other systems are fixed-point, 
not floating point. There is no loss of precision.

That is why there is a proposal for R3 to make all such options be 
specified at the point of call, not globally. Any global option like 
that would be protected from modification, or else it wouldn't be 
allowed.

Regarding the "meaning" of ordering. If we examine some of the orderings 
you eventually might find "meaningful" we can come to the conclusion 
that they are not the only alternatives possible, and thus are actually 
"meaningless" as well in that respect. To support the "most meaningful" 
ordering for the specific data SORT supports the /COMPARE refinement, 
which proves the point, that even the ordering one user finds "meaningful" 
may lack "meaning" for another.

Ladislav, all human languages are highly polysemous.

In the previous contexts, the words : "lit-word argument" may be 
deciphered as:
1) A passed  argument which is a lit-word (your point)
2) An argument that is declared as a lit-word (Brian's point)

The Brian's words are clearly meaningfull in this context, It's only 
you Ladislav who  decided that your personnal semantic representation 
was the only one possible. You couldn't be more wrong.

An argument that is declared as a lit-word (Brian's point)

 - again, an error. An argument, that is declared as lit-word looks 
 as follows:

    argument [lit-word!]


, while an argument, that is partially evaluated is declared as follows:

    'argument [any-type!]

Good point Brian

The point is the lack of user types in rebol and also the lack of 
performances (GIT compilation needed)

I maybe understand the reason to have things like #[none], #[true] 
and #[false] to specify those values, if someone choose to redefine 
none, true and false.

 - as far as I am concerned, you are missing the point, Geomol. My 
 thoughts:


1) there is a Data exchange dialect in REBOL, which is the main REBOL 
dialect (considering the fact, other REBOL dialects are derived from 
it).


A sidenote: the "Data exchange dialect" name may not be ideal. (this 
name is used in the http://en.wikipedia.org/wiki/REBOLarticle). 
Maybe, following the same "naming procedure" as for other dialects 
we could name it the "Load dialect"?


2) In the Data exchange dialect (or Load dialect, whichever you prefer), 
the

    none


expression is a word, and you do not have any means how to express 
the #[none] value, except for this specially escaped format, the 
same holds for #[true], #[false], #[unset!], etc.

I think that Ladislav's point of view can be simply exemplified:

>> type? first [none]

== word!

>> type? first [#[none]
]
== none!

and perhaps made clearer with an example using #[unset!]:

>> type? unset!       
== datatype!
>> type? first [unset!
]
== word!
>> type? first [#[unset!]]      
== unset!

The data exchange dialect is a good point to have constructs. Then 
my logic goes:


REBOL values can be divided in two groups, 1. the ones with a non-ambigious 
lexical representation and 2. the ones without such lexical representation. 
Datatypes of values in the second group include:


unset! none! logic! bitset! image! map! datatype! typeset! native! 
action! routine! op! function! object! library! error! port! event!

and maybe a few more depending on what version of REBOL. The rest 
is in the first group.


It would make sense to have constructs for the values in the 2nd 
group. Then I look at some examples of constructs:

#[string! "abc"] #[email! "[abc-:-d]"]


Those are not necessary. If it's because all values can be represented 
as constructs, then why doesn't this work?

>> #[integer! 1]
** Syntax Error: Invalid construct -- #[


And how would values of type native!, action!, op!, etc. be represented 
as constructs?

I'm not convinced.

Pekr, yes exactly, it would work, because NEXT here means something. 
My point is, the same can be said with values like NONE, TRUE, FALSE 
etc. So why have constructs?

I think, that the point here is the Geomol's question:


I still ask myself, if all those constructs are really necessary 
taking the amount of work and time used into account.


The answer is quite simple, it is as with any data the Load dialect 
can represent:


- many data representable by the Load dialect aren't "really necessary"

-- other languages can usually represent less data types than the 
Load dialect can

-- the Load dialect did not have the escaped format from the start, 
and could do without it


- without the escaped format, the Load dialect cannot express values 
of the logic! type


- it is useful to be able to express values of the logic! type in 
the Load dialect
-- some languages have the advantage of being able to do that

-- it is confusing to use a word like true in the Load dialect, when 
meaning the logic value, since in the Load dialect true is a word, 
not a logic value (notice the example, where Geomol confused words 
and their values)

-- the expressibility of the logic! datatype in the Load dialect 
enhances the expressivity of the dialect, which is why it is useful 
to have it, similarly as for any other datatype expressible

-- the expressibility of the logic! datatype enhances the reflexivity 
of REBOL, since 

--- this way, the Load dialect can express values that would be otherwise 
inexpressible in it, while being used in the Do dialect

--- that means, that the Load dialect would not be usable to "speak 
about" logic values in a direct way

I'm not sure to see your point.

But If you want to see if the series are the same or not you have 
to use same?
Actually, Your trial does not  prove your claim

You have a point here

Would TERMINATION be a good name as well.  


I would imagine that Rebol would have a common exit point (a place 
in the executable where all terminations go) before control is handed 
off to the OS.  If that is so, then the suggested code could be placed 
there, which should simplify intercepting QUIT or HALT.  To be more 
consistant, I'd like to amend my ERR? proposal to be "code to be 
evaluated after an error is captured and printed" instead of before 
being printed.

Lad you are well placed to know that iterating over ANY random data 
list in ERBOL will require special cases in EVERY single algorythm 
you can think of.  every datatype has its own idiosyncracies.  


in a way, this is the point of datatypes in REBOL. They aren't generic. 
 so I don't expect them to behave so in the first place.

but the GC can only be speculated to.  so there isn't alot of point 
in documenting assumptions.

That's the whole point of this proposal.

That's a bigger problem than binding, believe me. Exact decimal comparison 
makes floating point code nearly unusable by normal programmers.

Strangely enough, it's not binding or exact decimal comparison that 
are at issue with FIND or strict-map! either, it's case and type. 
Nonetheless, this would make it easier to point to the distinction 
between STRICT-EQUAL? and STRICT-EQUIV? when talking about those, 
precisely because those aren't at issue.

I don't want to emphasize the aliasing thing or otherwise the ticket 
would need editing if/when ALIAS goes away. Still, good point.

I don't see your point with SWAP

That does not prove your point

I don't see the benefit to the propsal at this point.

The internal representation of the Document is the hard point.
Incremental parsing means caching some infos during parsing.

What to cache, what not to cache, and in which form, that is the 
question.

Went through the Parse Proposals list and tweaked the Priorities 
section to double as a status list. Unfortunately, some of the rejected 
proposals must have at some point been removed from the proposals 
page. We wanted to document them and why they were rejected, so they 
don't get proposed again. I may have to go the history and find the 
rejected proposals that were deleted and restore them to the page, 
so they can be rejected explicitly with explanations.