AltME groups: search

Keep in mind that I am not really participating in the R3 GUI effort 
right now either - I've been working at a lower level. I write LOAD 
:)

pekr:  I rely on objects for much of my work.   I hate the profound 
OOP theory (polymorphism and some of the dark OOP concepts), but 
like carl and most rebolers, agree that the primitive object is a 
very worthwile concept.  As is the case for many paradigm, they sometimes 
evolve themselves into such a complex form, that they lose sight 
of their original DNA.  


have you ever tried to support traditional OOP applications with 
multi-level inheritance and accross the board polymorphism, double 
inheritance and some other things like templates and more... it all 
starts out nice, then it locks you in.  you eventually get stuck 
by the framework being so much work to evolve, that you just keep 
adding new things instead of fixing the old.

hum,  tough answer... it would be a mix of time, desire, and past 
history.

that is, until I get a solution that works end to end.  Ubiquitous 
application of dataflow at this point, is still an experiment.

my prototypes encourage me to continue, since, I am always amazed 
at how it behaves in the end, but I have still to merge all of the 
solution into one bundle.  and no, its not simple, and yes it takes 
more code than what Carl will build in R3.  but in the end, I'll 
be able to interconnect a field directly to a web-servers' cgi-like 
page online, without actually needing to code anything.   one litlte 
line of code will allow both to interact with each other.


once all is done it will be easy to grasp, but currently, even I 
have some "challenges".  good thing is that in keeping with dataflow's 
programmatic simplicity, porting GLASS to R3 will be dead easy.  

so long as liquid works on R3. the most work will be adapting liquid 
globs to R3's gob! type, and even there, it could be pretty simple, 
if R3 has draw and its similar...

For the others: if I have the following piece of code

Rebol []
o: make object! [
	a: 1
	b: 2
	]
x: make o [
	C: does [print [a + b]]
	]
o/a: 2
x/c


I expect that changing o/a also its value is inherithed in the object 
X and X/C should give 4 as results.

Isn't that a bug?

it would work if you change o/a before you create the x object.

float-pair: context [
	x: 0.0
	y: 0.0
	set: func [value [pair! decimal!][
		switch type? [
			pair! [ x: to-decimal value/x y: to-decimal value/y]
			decimal! [x: value y: value]
		]
	]
]

then you would be allowed to do:
float-pair: 3.4
float-pair: 5x7


obviously, this is just a very simple and incomplete example but 
it should give you an idea of the concept.

btw, R2 we can create pseudo classes by implementing custom port 
schemes which include a concept of accessors.

[ This whole post is mainly in the R2 mindset, but is somewhat relevant 
also to R3. ]


The technique of setting words directly into the global context like 
this:

	context [
		set 'o ...
	]


I do not like, because this code is modifying its environment - it 
has side-effects - thus, it is non-modular, and does not scale.

Being non-modular means large software systems can't be built up 
reliably, because the cumulative effect of all those side-effects 
will eventually cause name-clashes in the global context, so that 
some word exported from one context will be overwritten by the same 
word exported from another context.

For example, suppose I've seen two graphics demos by two different 
authors. They each have an awesome graphics processing routine and 
I decide that I would like to combine both routines into a single 
program. They each wrapped their code up in a context and exported 
a word 'process-image, like so:

	; From author #1
	context [
		set 'process-image does ...
	]

	; From author #2
	context [
		set 'process-image func ...
	]


You can imagine that each of these "modules" also has a large amount 
of supporting code, local variables and functions, and each is in 
a large file on the respective author's website. Somewhere in the 
middle of each of these files, in the CONTEXT body code, are the 
SET lines which export the words into the global context.

When I write my program to combine both of these "modules", I will 
probably write code like:

	; Acquire all dependencies
	do %image-processor.r  ; By author #1
	do %super-gfx.r  ; By author #2

	; Create an image and manipulate it.
	my-image: make image! 400x400
	process-image my-image ...


and here I realise that there is a name-clash with the 'process-image 
word, which is set only to the value exported by the second author.
So what do I do?

Here are some theoretical approaches, which have their own problems.

1) I could reload each file just before use:

	do %image-processor.r  ; By author #1
	process-image my-image ...
	do %super-gfx.r
	process-image my-image ...


  Each "module" is not expecting to be used this way, so this has problems 
  like:

  - "Static" locals which are intended to remain in memory will be 
  lost each time the file is reloaded.

  - Performance could suffer; each file could be large, and many calls 
  to 'process-image might be done.


2) I could set the first imported word to my own chosen word before 
importing the second "module". eg

	do %image-processor.r  ; By author #1

 process-image2: :process-image  ; Create an alias, as 'process-image 
 will be overwritten next line.
	do %super-gfx.r  ; By author #2

	; Now use
	process-image2 my-image ...
	process-image my-image ...


  But this means that a line of code has been created in the dependency 
  acquisition stage which has a complex interdependence between the 
  two "modules". They are not independent, and so individual dependency 
  acquisition lines can't be easily copied from this code and pasted 
  into a new script and expected to work right away. If copy/pasted, 
  the code will have to be examined, probably in great detail, to discover 
  what's going on and how to make it work. This will lead right back 
  into each source file, where the SET lines which export words to 
  the global context must be found. What great fun that will be in 
  a large software system built using many modules.


Another approach could be to try to bind each module code to a new 
context which contains the exported words, so they are isolated from 
each other... but this is complex.


All the above approaches are attempting to work around a single problem: 
that each "module" is exporting words where and when it likes, without 
consideration for the environment (other "modules", other global 
words etc.) This is "global namespace pollution" and the approaches 
above just introduce more problems in trying to work around it.


The solution to all this, is, in my view, for modules to declare, 
in the script header, the words that are intended to be exported, 
but for the module code not to actually perform the exports. This 
should be done by the user code, at its option. If a large module 
provides an API of 10 functions, then those function words should 
not be forced into the global context. The user script should be 
able to choose which, if any, of those words to import, and into 
which context it would like to import them. Additionally, the exported 
word value should be importable to a differently-named word, which 
can solve the name-clash problem we have above.

If modules do not use SET, but instead declare their "export" words 
in the script header, then digging through code to find side-effects 
should no longer be necessary. In R2, this requires that all module 
authors adhere to this type of module system, and declare their "export" 
words in a standard fashion.


In R3, I'm hoping the module system will develop into one which can 
enforce the modularity of modules, so that a user script can be sure 
that there were no side-effects introduced by loading any module.

Some comments about R3:
- R3 modules have the explicit Exports header in the spec

- IMPORT/only doesn't export the words into your current context, 
it just returns a module! reference.

- LOAD module! doesn't DO any of the code in a module, so you can 
examine the spec with SPEC-OF module!.

- If you import a module the first time with IMPORT/isolate then 
all of the words in that module will be local, even the SET 'word 
ones.

anton, slim doesnt expose ANY words in the global context.  module 
interdependency is assured even if they each need each other's code. 
 and the infrastructure is embeded, where its the code LOADING the 
module which decides what to include.  by declaring words in a module, 
that uses another module, you don't even expose those words.

this is available in R2 for 5 years now.

slim/load 'module-name version 


module-name is searched for in search paths and must match header 
name, or its ignored.

slim/load/expose 'module version [a-function another-function]


you can even rename the funcs as you are exposing them to enforce 
code to cooperate:


slim/load/expose 'module version [[module-name my-own-name] [other-module-name 
my-other-name]]

Izkata, that's not a bad approach, but it has these problems:

1) LOADing a module is not quite the same as DOing it. DO sets up 
the current directory and system/script object correctly. LOAD doesn't, 
so the module might not be able to inspect itself and know about 
its location etc.

2) In trying to avoid setting words in the global context, you're 
setting words in the global context. Now you must use paths to get 
to what you want. This should be at the option of the user script. 
Obviously, you're exercising that option in your example. You could 
also do it this way:

 process-image1: get in context load %image-processor.r 'process-image
	process-image2: get in context load %super-gfx.r 'process-image

there are a lot more tweaks like that... all working and being used 
for years by me... but everyone has always complained that REBOL 
has to stay simple... funny now that R3 comes out everyone is crying 
for features that have been available to all of you for years... 
 :-/

Anton - 1 just takes a do [] within the block, but I see what you 
mean, it is less intuitive

all I'm saying is that we've had a working model which does all of 
proposed R3 tricks for years.

(a part from "enforcing" the closed nature of the context)

brian: maybe a lot of the work for F2 forward already exists we could 
work together on this, if you want. ;-)

and I second the motion, that modules should be 100% tight closed 
by default.  its just a better habit to have by default... if god 
is going to talk to the pupils.

R2-Forward is mostly done, at least as of R3 circa a month ago.

Maxim, do you have a user in R3 chat? Otherwise I can post the original 
debug source of LOAD (not even posted there).

load: func [
	{Loads a file, URL, or string.}

 source [file! url! string! binary! block!] {Source or block of sources}

 /header  {Includes REBOL header object if present. Preempts /all.}

 /next    {Load the next value only. Return block with value and new 
 position.}

;	/library {Force file to be a dynamic library. (Command version)}
;	/markup  {Convert HTML and XML to a block of tags and strings.}
	/all     {Load all values. Does not evaluate REBOL header.}
	/unbound {Do not bind the block.}
	/local data content val rst tmp

][  ; Note: Avoid use of ALL and NEXT funcs, because of /all and 
/next options
	content: val: rst: tmp: none ; In case people call LOAD/local
	
	; Retrieve the script data
	data: case [
		block? source [ ; Load all in block
			return map x source [apply :load [:x header next all unbound]]
		]
		string? source [source] ; Will convert to binary! later
		binary? source [source]
		; Otherwise source is file or url
		'else [
			; See if a codec exists for this file type
			tmp: find find system/catalog/file-types suffix? source word!
			; Get the data, script required if /header
			content: read source  ; Must be a value, not unset
			case [
				binary? :content [content] ; Assumed script or decodable
				string? :content [content] ; Assumed script or decodable
				header [cause-error 'syntax 'no-header source]
				block? :content [content]
				'else [content: reduce [:content]]
			] ; Don't LOAD/header non-script data from urls and files.

  ] ; content is data if content doesn't need copying, or none if it 
  does
	]
	;print [1 "data type?" type? :data 'content true? :content]
	if string? :data [data: to-binary data] ; REBOL script is UTF-8

 assert/type [data [binary! block!] content [binary! string! block! 
 none!]]
	assert [any [binary? :data not header]]
	if tmp [ ; Use a codec if found earlier
		set/any 'data decode first tmp :data

  ; See if we can shortcut return the value, or fake a script if we 
  can't
		case [

   block? :data [if header [insert data val: make system/standard/script 
   []]]

   header [data: reduce [val: make system/standard/script [] :data]]

   (to logic! unbound) and not next [return :data] ; Shortcut return

   any [next any-block? :data any-word? :data] [data: reduce [:data]]
			'else [return :data] ; No binding needed, shortcut return
		]
		assert/type [data block!] ; If we get this far
	]
	;print [2 'data mold to-string :data]
	
	if binary? :data [ ; It's a script
		unless find [0 8] tmp: utf? data [ ; Not UTF-8
			cause-error 'script 'no-decode ajoin ["UTF-" abs tmp]
		]
		; Process the header if necessary
		either any [header not all] [
			if tmp: script? data [data: tmp] ; Load script data
			; Check for a REBOL header
			set/any [val rst] transcode/only data
			unless case [
				:val = [rebol] [ ; Possible script-in-a-block
					set/any [val rst] transcode/next/error rst
					if block? :val [ ; Is script-in-a-block
						data: first transcode/next data
						rst: skip data 2
					] ; If true, val is header spec
				]
				:val = 'rebol [ ; Possible REBOL header
					set/any [val rst] transcode/next/error rst
					block? :val ; If true, val is header spec
				]
			] [ ; No REBOL header, use default
				val: [] rst: data
			]
			; val is the header spec block, rst the position afterwards

   assert/type [val block! rst [binary! block!] data [binary! block!]]
			assert [same? head data head rst]
			; Make the header object

   either val: attempt [construct/with :val system/standard/script] 
   [
				if (select val 'content) = true [
					val/content: any [:content copy source]
				]
			] [cause-error 'syntax 'no-header data]
			; val is correct header object! here, or you don't get here
			; Convert the rest of the data if necessary and not /next
			unless any [next block? data] [data: rst: to block! rst]
			if block? data [ ; Script-in-a-block or not /next
				case [

     header [change/part data val rst] ; Replace the header with the object

     not all [remove/part data rst]	; Remove the header from the data
				]
				rst: none ; Determined later
			]
		] [rst: data] ; /all and not /header
	]

 ; val is the header object or none, rst is the binary position after 
 or none

 assert/type [val [object! none!] rst [binary! none!] data [binary! 
 block!]]

 assert [any [none? rst same? head data head rst] any [val not header]]

 ;print [3 'val mold/all :val 'data mold/all :data "type?" type? :data]
	
	; LOAD/next or convert data to block - block either way
	assert [block? data: case [
		not next [ ; Not /next
			unless any [block? data not binary? rst] [data: to block! rst]
			data
		]
		; Otherwise /next

  block? data [reduce pick [[data] [first+ data data]] empty? data]
		header [reduce [val rst]] ; Already transcoded above
		binary? rst [transcode/next rst]
	]]
	
	; Bind to current global context if not a module
	unless any [ ; Note: NOT ANY instead of ALL because of /all
		unbound
		(select val 'type) = 'module
	][
		bind/new data system/contexts/current
	]
	;print [6 'data mold/all :data 'tmp mold/all :tmp]
	
	; If appropriate and possible, return singular data value
	unless any [
		all header next  ; /all /header /next
		empty? data
		1 < length? data
	][set/any 'data first data]
	;print [7 'data mold/all :data]
	
	:data
]

wow, that's a pretty massive func!  :-)

I guess a lot of what load used to do is now in the transcode native?

what!!  a command version!?!?   ;-)

{Force file to be a dynamic library. (Command version)}

No command version. That is just a reminder.

does load/header/next only give back a header object?

That would be a good change.

brian, still a bit puzzled by you last /unbound comment

Yes, but cluttering up our heads with a muddle of confusion instead.

(That's a bit of a strong word. I should say the function should 
not be considered complete until such variable names are removed.)

(sorry, went offline for a moment)

I do word recycling myself, but only in repeatedly used functions... 
but load being used just a few times per script, such optimisations 
seem a bit excessive, but then if that code was taken from Carl, 
he does pretty excessive optimisations all the time.

TMP is just that, a temporary variable. It has no special meaning 
that isn't mentioned in comments.

I think VAL has a right to exist (with that name), because just after 
it is first set, you don't know whether it's a header block or not. 
You have to check. At the moment you have determined that its value 
is a script header, then you can do:

	hdr: val


which does mean you now have two locals, HDR and VAL, but I don't 
know any other way of preserving the clear and unambiguous meaning 
of a variable.

BrianH, I'm very glad you put those comments around the use of the 
TMP variable. But keep in mind, when quickly checking the source 
of a function in the console, the comments are lost. Not very convenient 
for quickly understanding how something works and returning to your 
workflow.

Well, this is one of those functions that *has* to be as bulletproof 
and efficient as possible. Even Carl defers to my judgement on LOAD. 
I try to make it easy to read, but there's no point about worrying 
about lost comments when the source is a CHAT 26 LF away.

You appear to be doing a very good job of it, overall, don't get 
me wrong. I wish you'd see my point of view with respect to other 
(future) users who will view the code in the console, not in some 
source file locatable somewhere if you're lucky and the RebDev chat 
server is still running.

is there a none returning version of assert... a bit like first vs 
pick ?

yess apply that is a great addition to R3   8-D

must be a bit slow though... is it?

Plus it disables the special treatment of 'a and :a declared parameters.

Is there a way in R3 to "capture" error messages when using ATTEMPT, 
or some other command.
i.e.
>> WRITE %missing/File.txt to-binary "test string"
** Access error: Cannot open: %missing/File.txt reason: -3
** Where: WRITE
** Near: WRITE %missing/File.txt to-binary "test string"

>> ATTEMPT [WRITE %missing/File.txt to-binary "test string"]
== none

Is there any way to get the error message from the ATTEMPT?

in R3 is there a way to intercept the write event before the send 
occurs - and if not, is there a way to force a send before another 
write takes place in an Async queue?  I'm getting an issue where 
multiple write events are being cached and sent all at once (about 
10 write events per second).

Is there any advantage to using set/any over a set-word ?

Ah, I see now *a* set-word!. :-\  Consider an unset! result:

>> if error? err: try [()] [print mold disarm err]
** Script Error: err needs a value
** Near: if error? err: try [()]
>> if error? set/any 'err try [()] [print mold disarm err]
== none

Is there any way in R3 to optimize code such as 


 out: insert insert insert insert insert [] 'fill-pen color [text 
 vectorial] 0x0 "hello"


?  I think the appearance of n INSERTs is kind of ludicrous. People 
are doing this for performance reasons, so the usual way we would 
optimize the code (which produces an intermediate block), isn't an 
answer.

I've forgotten if R3 has any way. (A quick look at APPLY and MAP 
doesn't seem to bear any fruit.)

it's not more fast than using a reduce or a compose.

---> thus, does become a speed issue.

Or have a method of reducing only the items in a block as they are 
being applied, without generating a new temporary block to hold them.

i think a reduce that can not creates a new block is not interesting, 
because the same block can not be anymore reduced next.

so, you can't use it in a loop

but an insert fonction which can reduce all the values from a a block 
before adding them, is quite interesting.

yes ok for the name REPEND, but we need a native func with no reduce 
inside

Anton, is there a reason COMPOSE won't do what you need here?  If 
the objective is to avoid creating a temporary block, compose does 
it.

Ammon, both COMPOSE and REDUCE generate a new block.

I'm seriously beginning to loose faith in R3. As I see it, there 
are still a lot of bugs on the lowest levels, and most development 
is going on far above that level. It's like a tall building, where 
new windows are put in on the 123 floor, while there are still many 
cracks in the basement. I guess, it'll take years at best, before 
we see a stable R3 on major platforms at the same time.

The lowers levels should then have been tested better, before going 
into higher levels. When you fix a bug on a low level now, it could 
have significal influence on higher levels, so more tests and probably 
new bugs. Problem is the low levels are hidden from us.


Memory problem on OS X concern me a lot. Also today I wanted to do 
some test on issue! datatype, and get strange results. Like doing:

i: #
insert i "abc"


If low level series handling like this has bugs, then I'm very concerned.

Henrik, when I made Canvas RPaint, you helped a lot with testing. 
And I didn't move ahead, before everything worked completely. That's 
the way to do large projects.

I'm not sure I understand this concern. Clearly there is a bug, and 
Carl usually fixes those, but only if they are reported to Curecode.

I tried in r3-alpha to make a list of things, to be tested, with 
a hierarchy from a description from Carl. (The r3-status.r script) 
But it didn't happen the way, I had in mind.

I don't think it would have less bugs. More bugs would have been 
exposed, but the rate of fixes would be roughly the same. We already 
have a rigorous testing system in place, only it has not been used 
much yet. I think it's because Carl is too busy designing the remaining 
subsystems.


What's important at higher level development, is not to use workarounds 
for bugs, but await proper fixes.

And there are many parts that are sitting unfixed, because they await 
a proper solution (compiler issues), such as the many problems with 
image!.


BrianH has also done a ton of work, spoonfeeding Carl with reports 
and fixing dozens of issues with LOAD and TRANSCODE, so to say that 
things are closed, is not true.

Geomol - I have to object. Before complaining about the way the projects 
is run, please check the following:


 - do you really understand, how the project is being run at all? 
 Because quite frankly, you are not using fair arguments here imo. 
 I can agree, but only to some extent, that things are being done 
 in a chaotic way. But - being close to Carl and trying to listen 
 to him and COMMUNICATE with him, I can understand the aproach he 
 takes. 


- one of your false arguments is, that putting things into CureCode 
is not helpful - CureCode was chosen by Carl and the community as 
a streamlined channel for bug reporting. Now please don't tell me, 
that even some low level bugs are not reported? There is a changelog 
which simply proves you being wrong.


- Before some releases Carl asks BrianH to change CureCode items 
rating to fix most important stuff - so how comes that our aproach 
does not work? Please post bug reports, talk to Carl or BrianH to 
raise the importance - doesn't following section show we finally 
got our requested - release early, release often?
http://www.rebol.net/wiki/R3_Releases


- and to be honest - you are one of persons being added to the r3-gui 
world. Some time back Carl had to add even lamer like me to the list 
:-) - and you know why? Because he was not getting much of response. 
He nominated top community gurus to help with the GUI. Actually, 
the same happened during the Gab's VID3 project - only me, Henrik, 
and BrianH commented. It seems to me that some ppl prefer to chat 
about science and belief systems instead of helping to develop R3 
;-) (I am not dismissing anyone's right to come here to chat about 
anything - this place is really a rebol pub where we meet, but the 
other worlds were specialised, yet lacked the input from community, 
even if asked for help)


- in order to get more ppl involved in R3 development at native level, 
it is clear where do we need to get - we've got R3 chat to be base 
of new Altme, new BBS, new DevBase. In March plan Carl clearly outlined, 
that in order to get sources out, we need rebin, plugins. They are 
now postponed due to modules, security, but still a high priority. 
How do I know? Because I was not lazy and asked Carl the specific 
question.


- we also get improvements on other fronts - we have got new streamlined 
Docs. I suggested Carl to add community section, then also new R3 
section to rebol.com page and to produce detailed changelogs. These 
all are small steps, but steps which make a difference.


Now please tell me - how complaining here can make situation any 
better? How many bugs have you posted, how many rebdev messages you 
have asked to Carl? Why don't you talk about your concerns with Carl? 
He will respond to you, like to me or anyone else - either via chat, 
or via a Blog article.


As for me, I am quite fine with how R3 is progressing last few months. 
Yes, we are slow on the whole project, but we are still doing a good 
progress imo.

Responding to Pekr's comments:


- I've communicated with Carl privately before. Starting on the OS 
X port more than a year ago is one example. Lack of info back to 
me made me stop. It's in a group in r3-alpha, you don't have access 
to.


- About CureCode, I didn't argue, it's not helpful. I don't care, 
what bug report system is used, as long as it works. Curecode is 
one of the best such systems, I've seen. Yes, low level bugs are 
reported. That's not the problem. It doesn't make much sense to me 
to work on a building (in lack of better metaphor) at the 123 level, 
when the basement isn't stable. Question is, how long this situation 
will last, before I see a stable version across platforms. My guess 
is years, therefore my concerns.


- r3-gui. Again it doesn't make much sense to me to work on GUI, 
if the core has many bugs.


- You list many topics in monthly plan. Development is going on at 
all levels of the building. I would start by making a solid basement, 
then make my way up. Making any level finished, before going to the 
next. It's just another way of doing things. I have good experience 
doing it the way, I try to describe.


- About docs. It's about time, something is done with the docs. I 
had huge problems figuring out, even how to test R3 back in the r3-alpha 
days. Docs were confusing, lack info, etc. Some months ago I tried 
to figure out, if I could port Canvas RPaint to R3. I stopped quickly, 
when I couldn't find the docs to do even simple things.


Well, you ask, why I complain. Initially I just said, how I felt. 
Loosing faith in the project. I really hope, it'll happen one day. 
But as I see it, it'll take years. I feel like sharing this view 
with others. Then you can use it as you wish. I need to figure out, 
what I'll do with my own development.

It is not the time (yet) to do solid porting to another systems by 
ourselves.


Good info! I should have known that 1.5 years ago, when porting was 
a topic.

Question is, how long this situation will last, before I see a stable 
version across the platforms ...

 - I don't know, noone knows. The thing we need is - testing. So - 
 find a bug, file a bug, talk to Brian or Carl, make it a higher priority, 
 it will get fixed.

Do you think, the time will ever be right for people doing such ports 
to all different kinds of OSs? A situation, where the OS-dependent 
parts of R3 will be open source and documented. I have my doubts.

The way I see it (now)is R2 is just a product thatI bought that gives 
great value. But who knows.... tomorrow there might be this awesome 
language called "Zen" and after 2 years I am so good with it... you 
get the picture :-)

So the answer to your question is - yes, I really think we are months 
at max away from the source releases and real porting efforts. In 
the meantime, do what Maarten suggests - just sit and watch, and 
accept things being just an alpha, not a beta ...

Pekr, I just started my old r3-status.r from the r3-alpha world.


One of the top priority bugs in that is #60 division by zero. I went 
to Curecode and read about the bug dated 4-Jun-2007, and I tried 
it in latest R3. It's still there.


Another high priority, #115 dated 11-Jun-2007 has status waiting. 
Waiting for what?


A third is about money! datatype, #250. Currency now seem to be removed 
from R3, so it can't be tested anymore. So R3 will not have currency?

etc...


So you see, there are lots of things to put in rock at the lowest 
level. So no need to discuss all the higher level things (from my 
viewpoint), before those lower levels are fixed.


An example of backward development or bad planning or whatever. The 
issue! test, I just wrote about. It seems to be because of unicode. 
So the plan for all this wasn't made, when the issue! datatype was 
programmed? Now what? Do we have to roll all back and do heavy testing 
again at the lowest level?

If you don't watch Chat, you probably also missed Carl's info - he 
is working on a list of items, which will turn R3 into beta.

Geomol, I'm not sure why it surprises you that R3 takes a long time 
to build. It's always been difficult to determine exactly when R3 
would be considered stable. Building the GUI was a very quick way 
to expose multiple bugs of which some are solved (including some 
nasty memory related crashes).

OK, then don't sit and wait, but please try to be constructive. Or 
in other words - don't try to be a Pekr :-D

Geomol, we're not dealing with a business system that you would potentially 
have to pay millions for (yet!). That's why it makes a lot of sense 
to write some apps now for it.

I made r3-status.r script based on that list from Carl. So no, not 
ignored.

I also worked with someone in r3-alpha to do tests, that would make 
all those low levels a green ok in r3-status.r.

Eh, there is many docs written by Carl, that are forgotten. DocBase 
became a mess, it needs serious clean up (e.g. all docs about VID3 
should be removed, it confuses ppl). When I told to Carl, that we 
need release notes, he told me he needs to think about doc structure. 
So I pointed him to one year old Doc of his (earlier alphas) and 
he told me he forgot about the doc :-)

Pekr, only the framework and a few smaller tests. That was when Carl 
was talking about how huge an undertaking these tests would be.

I still regard it being a good start for further test submissions 
...

What I mean is, let's take first point in Carl's list. Scanner bugs. 
Are there any? Is
--1:23

a bug? Yes, it is. I don't have time to find all these low level 
bugs, but it seems, I easily find some of them, when I start looking. 
So problem maybe is, that people are not looking, and Carl don't 
document, how people can look for these things. It's because the 
whole thing is closed to some degree.

Henrik, I'm sharing my view in hope, it can bring R3 to a stable 
version across platforms at some time. I guess, I've made my point 
now.

unreported bugs will remain unfixed. period.


Reported bugs at low levels will also remain unfixed for years, it 
seems. That's one thing, I try to point out here.

Reported bugs at low levels will also remain unfixed for years, it 
seems. That's one thing, I try to point out here.


And BrianH works with prioritizing bugs for Carl, which could be 
a reason why some bugs you see as important are not fixed.

And BrianH works with prioritizing bugs for Carl, which could be 
a reason why some bugs you see as important are not fixed.


Ok, maybe that prioritizing is whong then? I don't know. I only know, 
it has been going on for years now, and as I see it, it will continue 
for years.

Where do I find those #60, #115 and #250 tickets? I can't see a bug-base 
in r3-alpha, just in terms of r3-gui, and those tickets don't match 
... are they in CureCode?

pekr, the R3 bug database was moved to Curecode back in January. 
The R3 GUI bug database is not published, because the GUI is considered 
too alpha to keep a bug database for.

Geomol has to be someone else, probably Pekr. Maybe Pekr has stolen 
Geomols account here. Hmm, but then I should know about it. Hmm, 
but that would mean, that I have a schizophrenia :-)

Henrik - then it is just a question of asking BrianH to raise its 
priority, no? The question is, if we are talking about bugs, which 
are holding us back?

Carl does not monitor this Altme world for a long time already ...

That's fair enough. To make a bug report requires a substantial allocation 
of time and concentration. You have to check that it really is a 
bug and not a misunderstanding, that it isn't already reported, which 
requires searching through the database, and actually writing the 
bug ticket.

Oh, no, I already wrote the bug. :-)
Yes, it's a lot of work to report bugs.

What frustrated me during all of R2 development was finding a bug 
that really threw a spanner into the works of some application I 
was making. I would report the bug, but it wouldn't be fixed for 
a long time, basically forcing me to abandon the application, or 
workaround in an extremely time-consuming and ultimately fragile 
way. What I would have liked was access to Rebol source code so I 
could just find the bug and fix it. The amount of work I put into 
workarounds... gee whiz.

For R3, I haven't gone to the same effort. I just don't want to go 
down that road again.

Having said that, it appears to me like R3 is steadily getting on 
its feet. If the linux rebol console can get some more user friendly 
features like arrow key history etc., for example, then that would 
make things easier. Only recently the scroll buffer was introduced, 
thankfully.

I attracted Bobik to R3 once again. He was waiting, and waiting, 
and then he went into pissed off mode. So I told him to concentrate 
upon R2 (he is now using RebGUI) and Python, and just take R3 as 
- "might be" a good thing in the future. We now have good chat about 
the progress, and there IS a progress, although it might seem to 
be slower than we might wish for ...

R3 is whole new architecture, and in few years, it is goint to be 
cool. As Maarten said - maybe some completly new stuff appears, which 
blows us all. But so far, I still can see the chance for R3. There 
is not much change with Python, Perl, Ruby, Lisp, Scheme, PHP, whatever 
- no revolution happening - each technology has its place. There 
is also not revolution with the web aproach. So, just a patiecne. 
And those impatient - forget R3 for one year, then come back and 
investigate the situation, to stop your frustration ...

Why do you see it as frustrating? I it because I tell the truth? 
I hope, people dont live in a fantasy world and wait and wait for 
years.

Geomol - on one hand you claim, that you don't have even free time 
to report a bug, not to mention to help with R3, while on other hand 
you claim, that you look for a platform/language to port your app 
too (which surely is huge effort)? This sounds like a discrepancy 
to me ...

Pekr, I've tried to help for a long time in r3-alpha. For years. 
I've had my fingers into C source for Windows, trying to figure out, 
what's going on. I've just come to a point.

Rubbish, Pekr! :-)

I wanted to help. But I won't sit on 123 floor in a building with 
unstable basement. How should I suppose to test my work? Think! :-)

I will sit on a 123 floor with unstable basement because the view 
is beautyfull  ^^

shadwolf! :-) I love that! And I'm also a person, that like to live 
my life dangerous. But I'm also practical in many ways.