AltME groups: search

e.g. - some time ago I did this comparison - http://www.xidys.com/btn-comparison.jpg

I'll do one at a time and have you review it

its funny cause through all those years of working on glayout, I 
never really took the time work on the actual aesthetics, that was 
not the point of GLayout... and since its built over VID... well 
we can effectively rework all and reuse most VID styles.


  somehow, I find, with the looks derived from henrik's previous tests, 
  where very close to what I would have done myself (hehe henrik and 
  I have to meet at devcon... I think we'd have much in common) Glayout 
  has found itself a simple yet elegant look.  The latest version have 
  started to work a bit more towards looks, and now the highlight is 
  used throughout, so one can change one line and switch  the default 
  golden color to anyone... I'm trying out grey blue these days.

sorry to cut in... but you where all talking about a subject I like 
so much.  I wish I had more time to make GLayout flashy... alas, 
like Anton, I work more on the the actual featureset and api, allowing 
anyone a vast array of tools he can reuse in his styles...

I think I'll leave button for now, because I don't really know what 
else to add to it yet. I will probably go around all elements over 
time and when I reach the last one, I'll start going over them again 
for more polish.

build#60 committed to SVN. Added Henrik's button widget with 2 minor 
modifications:

	1) Over color defaults to colors/over
	2) All of init inlined into the effect facet


The first change is self-explanatory, the second follows the principle 
that init should do as little as possible (facet code is evaluated 
once while init code is evaluated every time the widget is used). 
This change has one subtle side-effect, the "Refresh Display" button 
of %tour.r no longer works for all widgets (button in particular). 
This will be fixed in a future build.


One thing to note about the new button widget is its default size: 
15x6 instead of 15x5 units. This should not be a problem for most 
buttons, but may have spacing/alignment issues for inline buttons.


Note that the button change necessitated a small change to request-date 
which is now working again.

Time to clean up radio-group and drop-list. With radio-group I'm 
contemplating getting rid of all the ID code and making it default 
to:

	data [1 "Opt 1" "Opt 2"]


if no option is selected. You'll still be able to start with no option 
selected (either by specifying none or 0), it's just that having 
no option selected by default is confusing to new users.


For drop-list, I want to fix some of the remaining bugs and add the 
two changes discussed above; clicking anywhere in the area to activate 
the drop list and pressing DnAr to activate it by keystroke. The 
first change could really confuse folks used to changing focus by 
mouse click so I'm thinking of making it an option, say "options 
[click]". Comments?

I'm updating DocBase GUI docs.


1. Changing the links at the bottom of each of the pages to point 
to a single template so that they are automically updated across 
all pages by changing one document.
2. Adding [[Category:GUI]] to each of them.

3. If I have time I'll start working on a VID2 to 3 document that 
describes what changed.  Things like face/parent-face is now parent-face? 
face.

Yes, however I think they need to be more exact. It looks like it 
could be related to the old rich text bug I saw a long time ago.

there is actually a built-in similarity to counter:

to-time 78
== 0:01:18

Just imagine any base instead of just !24.60.60

I've just been busy lately. Carl fixed/documented a lot of things 
in alpha 37 for me, but I'm in crunch time at work now. Soon.

It's a simple state machine.  It's taken me a long time to grok what 
can be done with such a system but now they are starting to dominate 
my code.

Heh.  Or rather I don't know why SOME was ever working but I saw 
it work once.


parse "  ^- this is a test!" [s: any ws e: (probe copy/part s e) 
to end]

ANY appears to work all the time though.  Strange.

Then, it's not related, the parent is not associated with the ANY 
rule. So that, the ANY rule can failed and the parent will be executed 
each time

But i don't use this. Useless memory overhead (by creating a new 
gob) each time.

The process now is to clean up the skin, making it as simple as possible 
first (no gradients or prettiness for now), so Carl will be able 
to approve it and so I've started from scratch, fetching in the styles 
one at a time. During this process, I've exposed a few problems and 
solved those, so it was a good idea to do that.

i use it all the time

using classes in liquid I was able to go over 1 million nodes in 
a decent time frame, under 400MB.  using prototypes, I wasn't even 
able to allocate 100000 nodes.

I worked with CA Visual Objects, which is trongly typed OOP. Most 
of the time you are trying to find out your way of how to obey system 
limitations. I hate that stuff. But - my question is different - 
with your  strong experience - why don't you just help with R3 GUI? 
;-)

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

[ 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.

no I have so litle time to play with R3... I barely have time to 
chat here...  life, work, kids, music, glass, et al... life is full 
enough withough R3 yet  ' :-/

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.

actually, most rebolers tend to grow the same habits in time :-)

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.

Most of the bugs in lower levels of R3 are found through higher level 
development, so that will likely continue. Also, getting things right 
is more important this time around. Please don't use it in production 
environments yet.

I think, it would have less bugs, if lower levels were tested better 
before moving on. Doing it that way, you'll end up using less time 
on the whole things, before it's finished.

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.

I have access to all worlds I know development went in - r3-alpha, 
r3-gui, and I of course remember your effort. It is not the time 
(yet) to do solid porting to another systems by ourselves. So far 
only Carl does some ports, bu those should be regarded being experiments.

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.

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.

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).

I would feel, I was wasting my time doing that.

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.

Nope, as I see it, there are so many bugs, that I would use all my 
time posting to Curecode. I don't have that time.

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.

Pekr, look at the bugs in Curecode and look at the test priority 
list by Carl. The bugs are reported, and they are not fixed for years. 
And new low level bugs emerge now and then. My guess is, because 
they way, the whole thing is run. Work on all levels of the building 
at the same time. Not good.

I will report this then. I'm just trying to tell you, I find lots 
of bugs. I would need to not use R3 at all (or R2 for that matter), 
if I should report everything. I don't have the time. I try to report 
all the really low level ones, I find. I see no much point in reporting 
higher level bugs, because they often dissappear in system development, 
when the low level ones get fixed. In most cases, I write about the 
bugs here in AltME.

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.

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.

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 ...

Geomol - ppl who do nothing for R3 do wait. Others try to help here 
or there, as their time permits ....

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.

Geomol - anyway - if we talk about R3 and open-source, then remember 
that only host-parts plus View are going to be open-sourced. The 
language itself (which is the culprit of bugs you are pointing out) 
is going to be closed source anyway. So the only thing we can hope 
for is, that at least not caring about host code and View Carl will 
have more time to spend on the kernel.

But - one thing worries me anyway - R3 http scheme is out for how 
long - 2 years? And we don't even have proxy for it. Not to mention 
other protocols. So if we (community) can't find some time to do 
other schemes, where's our help then? The thing is, that schemes 
stuff is really difficult. I can imagine myself doing some easy styles, 
but surely not complex thing as network protocols :-(

R3 is a work in progress it's normal to not already do heavy things 
with it. But at same time not using it doesn't help to find the problems 
it has to solve them

I'll tell you, the only thing lower-level than code is code docs. 
I'm so glad Carl took some time to redo the manual :)

I will go so far, that I even think that some part of the community 
became so ignorant, that making R3 fully open sourced would not change 
a bit of this situation. Some real work is needed, and ppl here complain 
that they don't have time to even scan sources of available info. 
Now tell me, how the same ppl are supposed to do any quality code 
for R3, even if it would be open-sourced? Once again - GUI is open-sourced, 
protocols are open-sourced, yet ppl don't even care to test or give 
a feedback.

plus you have to take in note motivation is it affortable to spend 
time in a no one cares and use language ? on extrem thinking you 
can go there too ...

and more the time pass worst is the situation the bugs piles up to 
the sky and you never see the end of fixing them

It's like when carl opens RAMBO some years ago the goal was to get 
some tickets time to time to do some bug fie time to time but as 
teh community worked alot on tracking bugs and doing suggestion the 
number of tickets was massive do you think that's the same thing 
being alone to solve 10  bugs than being alone to solve 4000+ bugs 
?

you contradict yourself. I am not talking about not being open sourced 
at all - I have nothing about open source products. I am just saying, 
that even if R3 would be open-sourced nowadays, the situation would 
not be much different, but some ppl behave like there would be the 
difference. The only difference is in the attitude - some ppl are 
not willing to invest their time = money into closed source product.

I read this whole discussion. I understand what Geomol is complaining 
about building and making it stable from bottom to top. That is a 
probably good eigeneering practice, but this is a little different. 
IMHO Carl and others don't just have to *code up* the R3 but they 
have to *design* the R3  (it's concrete implementation, it's core 
API, 1000s details) and there are a tons of small decisions to make 
all the time and you have to see and work on it from many angles 
so whole thing will come together well. IMHO

Ok so now I think this point is been integrated by Carl but he started 
to build lot of information source broker for all teh needs of the 
current task  but as an outsider (yes unfortunatly I'm not in god's 
Secrets...)  it's hard to retrieve relevant information and knows 
what's going on .. that's not to be hard with anyone that's just 
a matter of fact and to have discussed that matter a countless time 
with many ppl in the community (lame outsiders as Pekr would say) 
I'm not the only one feeling that way

I understand you, I am not frustrated about R3 because I don't wait 
for it ... R2 is the product for me , I at this time only care for 
what I can with some certanty use in production and R2 has tons of 
libs, examples, cheyenne .. and as a language it's also more interesting 
and hides more stuff that I can comprehend so exploring what can 
be done with R2 is still exciting to me.

If I had more free time I would probably also be more active in R3 
(at least bitching about it :) but I am at the stage where I need 
to produce stuff .. and I am happy I can use rebol for this

yes, I understand that... I was waiting for R3 for years ( I just 
used rebol for smaller stuff here and there at that time ) and frankly 
I was sure R3 is vaporware.. it's a 1 man design process with benefits 
of it and also limitations

and you see some things not advancing for long time like unicode 
support (i'm not even sure that will be a profit to r3 well as i'm 
an idiot i'm certainly wrong on this point)

If I were waiting for R3 I would be in an uncertain position too, 
but as Pekr said .. if you have some time you can participate more 
actively probably

denefits would be since there is only one guy with the vision of 
what he wants and how he wants it the creation process will go smoothly 
but the thing is that since the past years the R3 is started many 
 ideas in R3 have been changed a lot of time (like VID)  abd bothing 
ensure us that in the month comming another idea will pop and so 
one making R3 a never ended project

Pekr, I remember Carl mentioning this a long time ago: DECOMPRESS 
reads first how long the item to decompress is, then allocates memory 
and then attempts decompression, so it's a deliberate design choice 
for memory limited embedded devices.

for example for the area-tc (which renders full live colored text) 
during long time I expected to organise the date to parse or the 
line as hash! to be able to locate them faster  (since my data structure 
was pos char color making hash getting the position as indice was 
a good idea (well a much better idea was proposed by steeve simpler 
but all mighty efficient)

shadwolf - then it is time to start to move your project to r3, no? 
I think that View kernel itself might be in slightly better shape 
than in R2 (but maybe I am wrong - I noticed some font ugly display 
problems)

Pekr r3 doesn't exist ... I know i'm a stubborn moron  ^^ that's 
my way to be 1st it's on R2 complete and full wrokking then i will 
adapt it to rebGUI then i will do REBOL IDE then in that time R3 
will be official released and i will do the port

pekr font ugly problem have been solved in a way and if font ugly 
issues are not of my consern you want to blame someone blame CArl 
since the time we say him that there is still bug in R2 and he doesn't 
 want to fix them ... in that matter you can see R3 as a way for 
carl to escape the pain of fixing  R2 countless bugs

but gtk+ is 10 time the  size of a rebol VM ...

maybe doing a server/client style project ... but even then we need 
 people to maintain that solution to fit the gtk+ cahnges through 
the time

the day Carl say R3 is stable get it I spend the 100% time I have 
to port area-tc that's a fact

That's a possibility. I'll try to compress your script tomorrow if 
I have time (it's late here) and see if it segfaults.

Interesting...


I'm using blocks to manage a lot of name/value pairings which I will 
sort and copy/part the top x items.  I was hoping to be able to utilize 
the speed of map! for doing this.  Maybe I should use map! while 
creating/modifying and then when it comes time to pull top x items 
I could convert it to a block...

It works in R3 of course. I just haven't had the time to backport 
the changes in the last 9 alphas (in two weeks) to R2-Forward yet..

I use junction points on Windows all the time - it makes all sorts 
of things tolerable :)

READ/text seems like a lock, sorry. You may think that text is just 
another data format, but it is the *most common* data format, and 
tends to be processed in large quantities. You say that codecs can 
be chained, but they currently can't - you can apply them one at 
a time, with all of the intermediate forms in memory at some point. 
If we do text the way you ask, then every load of text for processing 
will have the additional overhead of a full duplicate of the ram 
and two series moves, plus a few lines of code. READ/text is a shortcut 
that will save a *lot* of overhead during what may be REBOL's most 
common operation.

as to %user.r - my only use for it is so that certain functions I've 
defined that I use a lot (pad, time, fold, Logfile object, etc) are 
automatically loaded in any script I want them in, as well as a terminal 
session.

Pekr, the reasoning behind blocking patches is the same reason there 
is no browser plugin - R2 is insecure, and R3 won't be. Every patch 
that you can make in your %user.r is what malware running on your 
system can make with your user permissions.


The goal is to have tons of REBOL hosts around. Every application 
with a plugin interface could have a R3 host as a plugin. R3 is going 
to be able to generate programs now, not just scripts. It'll be a 
real development tool.


The problem with all this is that being able to patch the runtime 
using %rebol.r or %user.r, so can anyone else, and you won't know 
about it. Can you say exploit? We already had a false positive for 
R3 this year, an old alpha mistakenly marked as malware. We don't 
want the next time to be for real. The only way to avoid that is 
to make R3 secure.


The way to make something secure is to make the behavior of your 
code predictable. That means making your requirements explicit.

I'm confused. Time to read some documentation...

Re: chunked, I don't know, it was working fine last time I tested 
it. Something probably has changed in R3 in the meantime.

Actually the auto encoding was cousing me some problems some time 
ago. I'm not sure if it was fixed. Also with the auto encoding urls 
there is a problem, that for example the second @ char in Pekr's 
url must not be encoded.

Ladislav (continued from Rebol vs. Scheme), FUNCTOR currently isn't 
being used by any mezzanine code, so if we want to change it now 
is the time. If we go with your initialization block idea:

- The initialization would have to be performed at function creation 
time, not first call.

- The init block would be only the starting spec for the static object, 
not  the final spec. We'd need to still do the search-for-setwords 
that FUNCT does, or there'd be no point to including FUNCTOR.
- I'd suggest that the parameters be in spec, init, body order.

re Functor:

* in my opinion it does not make sense to initialize static local 
variables during function call, since they are static and therefore 
supposed to persist, so the only time suitable for the initialization 
seems to be the function creation time

* the initialization (IMO) can perfectly serve another purpose: all 
initialized (during function creation) variables shall be static, 
while the other variables shall be dynamic IMO

making the set-words in the body persistent is a must

 - let me disagree with this. I think, that the INIT block is a must, 
 since the function cannot initialize the static variables as noted 
 above. OTOH, every variable not initialized during the function creation 
 time should be automatically dynamic, since it does not make much 
 sense to have it uninitialized when using it as static

FUNCT sounds perfectly logical and usable as is, but I really cannot 
imagine the usage of a persistent value that cannot be initialized 
at function creation time

Actually, we are going to make a DEFAULT function, but that is one-value-at-a-time 
until DO/next works.

Remember that the user won't be specifying the init block most of 
the time, just the body. Internal code would specify the init.

when I used a static local variable, I always initialized it at the 
function creation time using my Lfunc. I am sure I wouldn't touch 
a function with static locals not having proper initialization.

So far FUNCTOR hasn't really been used, so now is the time to change 
it if we are going to do so. The variable capture is a must though, 
since it will be used where the spec can't be specified by the user.

now that we have FOREACH on objects, it could be a good time to ask 
on the blog or in chat.

There are people who won't participate at all because there is no 
GUI client for R3 chat (which sounds completely ridiculous to me), 
  

I'm suprised that so many people are happy to work with a non-gui 
client.  If one asks for volunteers to spend their time, and create 
a retro environment for them to work ... you're not going to get 
the optimal result.

Steeve, in may experience the Curecode reporting system is far more 
effective than RAMBO.

There is clearly a lot f effort (thanks, Brian!) put into analysing, 
categorising, prioritising and fixing issues raised via Cuecode.


Not everything, of course I've added issues that have languished 
a long time, and some that have been dismissed. But they are outweighed 
by the ones that have been fixed in a few days.

It may be a lottery, but it is winnable :-)

I guess Ladilsav can answer your question about the ease of back-porting 
to R2 but I would guess that it's c code which means it is likely 
to be a long time before it would get back-ported.

For my code I find that I only need to think in terms of number of 
copies, or preallocation. On an algorithmic level you can save orders 
of magnitude in memory overhead (space and time) by controlling the 
number of copies.

it was actually Geomol on 8-Apr, who too refused to submit bugs, 
as those might not be corrected anyway


Pekr, I don't refuce to submit bugs! I have submitted bugs after 
we discussed it here. I just see little point in submitting bugs. 
And I have the practical problem with finding time to submit all 
the bugs, I could. But I do something, I consider even better than 
submitting bugs in the current situation. I have done some development 
lately, that test the REBOL scanner deeply. I have collected all 
my findings in a document, that I'll give to R3 developers, when 
I'm finish. The scanner is just one part of REBOL though.

Also the GUI is only working under Windows at this time.

view-text is broken quite some time. But when you try to use your 
own gui, you really have to use load-gui first ..

Here are my results:

>> include %timblk.r
== 1.55177304964539E-2
>> x: 1
== 1
>> t: [1]
== [1]
>> t/:x
== 1
>> t/(x)
== 1
>> pick t x
== 1
>> time-block [t/:x] 0,05
== 4.09841537475586E-7
>> time-block [t/(x)] 0,05
== 4.84228134155273E-7
>> time-block [pick t x] 0,05
== 2.98023223876953E-7

showing, that PICK is the fastest

Here, only the length of the code block is explaining the time difference 
(7, 6 or only 4 instructions to interpret).

So, if the following is faster it's because the code block evaluation 
take less time IMO (3 instructions) :

>> x: 1 dt [loop 1000000 [t/(++ x)]]
== 0:00:00.172