AltME groups: search

Yeah. We have a pretty thorough test suite for modules, and all tests 
pass for a110. And I checked the tests for accuracy too :)

Maybe using the same name for the "isolate" option and the "/no-share" 
refinement would be a good idea.

It shouldn't be a problem once we have the documentation. The /no-* 
options were named consistently like that by Carl for a very good 
reason though, to set them apart from the other options. The /no-* 
options can't be specified from the Needs syntax; this was a deliberate 
design choice, as every one of the /no-* options breaks normal module 
behavior in specific ways that would affect the design of the module 
code. As such, these needed to be exceptional cases rather than normal 
behavior.

This is a distribution nightmare.

I strongly suggest that the default-suffix be changed to something 
practical which stands a chance of reaching consensus.

Module path searching only works with non-file! module names. I.e.
import 'foo

will search the system/options/module-paths for a file name %foo.reb. 
This search is a _very_ useful feature which we shouldn't rid ourselves 
of by stupid wars over which suffix to use.


As a module author, I want to use a suffix which I know will make 
using the module easiest for my target audience.


As a module distributor, I also want to make it easiest for my target 
audience to use the modules _and_ I need to enforce consistency within 
my distribution.


The only one who does not really care about the suffix is the actual 
user. The user just wants to use third-party modules without having 
to homogenise their suffixes first. But the burden of choosing a 
sensible suffix is currently imposed on the user. This does not make 
much sense.

To be more precise: having a default which is actually intended _not_ 
to be used does not make much sense.

Having a default which _is_ intended to be used would be a strong 
incentive for both authors and distributors to stick with this default.

.rez resource files. It's a pain.

Here's another interesting trick: Make %rebol.r a unnamed module 
by putting type: module in its header and not giving it it a name. 
This isolates the words in it in its own context instead of putting 
them in the user context, controls the visibility of its code, and 
makes it easier to free up the memory it uses because its context 
is thrown away afterwards. It's the perfect occasion for an unnamed 
module: run once, and done for effect.


%rebol.r is a great place to set your preferred system/options/module-paths 
and system/options/default-suffix, to delay-load commonly used modules 
and extensions that you have checked out already, and to patch or 
wrap anything that you need to.

I would like to see some support for automatic logging of events.


Rebol currently has two "hooks" to allow "Front-end" code to execute 
automatically in the REBOL.r and USER.r files.

I would like to see another "hook" to allow "Back-end" code to execute 
automatically whenever Rebol stops its current evaluations for any 
reason such as encountering the HALT, QUIT, or any error which causes 
Rebol to stop evaluation.  


This could allow for some kind of automatic logging of  QUIT, HALT 
or ERROR as well as capturing the error messages.  It would be nice 
to allow capturing of any other information such as the script name, 
computer name, current timestamp, and where in the script the evaluation 
stopped, and how it stopped.


I would use this to log all of my scripts that is invoked (put the 
code in REBOL.r file) and then the termination conditions defined 
so they could be triggered automatically.  With such a function, 
I could even have certain selected scripts send an automatic SMS 
messages to my phone if certain scripts errored out etc.



I'd like to propose a new function called WHEN that can be used to 
trigger code at a terminating event.

WHEN  block  /all

For any specified terminating condition, evaluates what follows it.

Arguments:

block [block!] - Block of terminating events (conditions followed 
by values)
Refinements:

/all - Evaluate all terminating conditions (do not stop at first 
true terminating condition)


The WHEN command would be used to define code to be evaluated whenever 
a termination condition of any kind occurred in which continued evaluation 
will stop.

Examples:
WHEN/ALL [

 HALT?	[ print "This script will HALT now" ]  ; code to be evaluated 
 before the HALT is evaluated

 QUIT?	[ print "This script will QUIT now" ]   ; code to evaluate 
 befoe the QUIT is evaluated 

 ERR?	[ print "An error was discovered"  ]   ;code to evaluate after 
 an error is captured, but before the message is printed
	END?	[
		  print "Script about to end"
		  if  now/time  >  23:00:00  print "Stopped after 11 pm"

  ]                                                              ; 
   code to evaluate whenever the current evaluation has stopped for 
  any reason
	]


Note:  HALT?, QUIT?, ERR?, END? are all logic values which become 
true depending upon how evaluations will be stopped.

END? will always be true and one of the other terminating conditions 
will always be true.

What do you think?

Sounds like a great idea, except the function name.

Perhaps something related to the timing of the event. The code specified 
here would only be able to be executed at the end of the interpreter 
process - intercepting a QUIT or HALT is a tricky business. Perhaps 
FINALLY would be a better name.

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.

The only thing that cannot be intercepted is when the OS itself closes 
rebol for any reason.  An example would be a user clicking on the 
[X] box to close the window.  Although it would be great to have 
a CLOSE? termination condition, I certainly understand that Rebol 
would not be able to intercept that.  Now that I think about it, 
the only way that Rebol could intercept a CLOSE? condition is if 
the window panel itself is under Rebol control through the GUI -- 
but even then, that may be a difficult proposal to implement.

WHENEVER is also a suggested name.

No, because it isn't whenever, it has to be at a particular time. 
Termination is good.

It isn't difficult for Rebol to intercept the window close event. 
Carl Sassenrath was asking recently (within a few months ago, I think) 
about whether to   allow interception of this event.

>> length? 4

** Script error: length? does not allow integer! for its series argument


I am proposing that this return NONE for any type which it can't 
deduce a length.


this is both usefull in practice and would make length? a truthy 
function.

this is the easiest way to know if a data element can be traversed 
via pick without having to first know if the datatype can be traversed.


the issue is that many types have indexed content but are not series 
(i.e. no "current" index).  so we can get the value or deny listing 
in one function call.

ex:

print-tree: funct  [data][
	i: 0
	either len: length? :data [
		repeat i len [print-tree pick :data i]
	][
		print mold/all :data
	]
]

Aha, interesting, and what if we just defined properly a dataset 
like:

    pickable!: make dataset! [series! ...]

it also prevents us from having to create sets of predefined filters 
which will:

    -be unknown and forgotten quickly (e.g. more things to remember, 
    bad)

    -might only really be usable by a very few functions to begin with. 
    (not very usefull)


(this relates to the alternative that ladislav pointed, using a dataset)

we still need to add an extra if before the length? all the time.

 ... actually you would just move the IF to the native part and you 
 will use the IF also in cases where you are pretty sure it's a series 
 and want just its length.

unless its a cat!

On one hand, I like the idea that a none LENGTH? means "this value 
has no length", on the other the idea of a pickable! typset (maybe 
a different name though) gives us the ability to use it in func specs 
and such.

I'm not ready to say change LENGTH? without further thought.

note, that this proposal is strictly related to functions which have 
an '? at the end.  


if we go ahead with changes to the style convention which clearly 
define what a "truthy" function is and state that ****? is generally 
used to define such a function, I think that we could clean up a 
lot of the guess work in how to handle this often recurring case.

e.g.:

a: make object! [a1: 1]
length? a
pick a 1

well, if an object has a length? why can't I pick it?  that is the 
error IMHO.  though this is not the debate I want to start ;-)

Maxim <If an object has length, why can't I pick it?>
Maybe they are like SQL tables.....
A table has a length, so this is valid

   select count(*) from ....   -- to get the length of the table (ie 
   number of rows)

But, in the absence of an ORDER BY the rows do not have a user-accessible 
sequence, so

  select first from ....   -- is not valid syntax, nor (without an 
  ORDER BY) is it even meaningful

(Sorry, I know you did not want that debate)

The fact, that the code actually cannot be used means, that your 
idea is not supported by a real usage example, and is not completely 
thought-out.

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.

give me your perceived disadvantages.  I've been pulling my own weight, 
but I'm not seeing alot of points related to LENGTH? and other such 
funcs...  I'm not talking about a specific function chain.

Generally, it looks, that REBOL is headed towards "less error triggering" 
approach, and I don't feel any of the changes as a problem, so, you 
may be right. But, there should be some limits, where to stop. One 
of my limits is the usage of NaNs in REBOL, I prefer clean errors 
triggered to NaN dissemination. So, in that case, I know where my 
preferred boundary is. In case of LENGTH? and INDEX? function, I 
am not totally sure, but I am sure, that any change to the existing 
state is expensive (postponing the release, taking resources needed 
to solve more important problems, ...) So, I would support such a 
change only when I would get really convincing arguments.

yes, in such a sense (expensive change), I understand.  


I will wait for brian to step up and get his opinion.  I know we've 
spoken about this somewhat before, but not as head-on, for myself... 
 With the recent talk about naming, IMHO it has put a new light on 
the possibility for this to be a bit more appreciated, adding ? at 
the end would now mean something concrete.


let it be known that I do like errors, I am not against errors, I 
have been putting less and less error recovery in my code to make 
sure it crashes and I fix bugs early.


its just that I can see many if not most ****? functions (my own 
included) being truthy and this is very usefull to facilitate  control 
flow.  This, as oposed to always putting error handlers in places 
where the error is only used as a negative reply, for which we can 
supply, IMHO, a reasonable value/standard.

another proposal:


have info? support more datatypes.  it would be very nice for a single 
function to return information about any datatype in a single call.

ex:
>> a: make string! 1000
>> a: next append a "12345678"

== make object! [length: 7 index: 2 size: 8 buffer: 1000 references: 
1]

the references would tell us how massively this string is being used 
within the application and allow us to track if we are leaking data 
in a way that it will never be able to GC it.

...and, the GC is able to collect a string no matter how many references 
refer to it

on objects info? could just return all the various reflective properties 
it has (words-of spec-of) and a few more like ram being used by object. 
   all types would benefit from this sorely lacking feature in REBOL.

(generally, reference counting is not a true garbage collection)

cyclical references is a problem with any sort of algoritm.

yeah but for a garbage collector its a major issue.

You can understand the whole referencing business as a kind of a 
graph - A refers to B, B refers to C, C refers to A, ...

ok, just read a few papers on current GC techniques (including MS's 
pretty competent algorithm)

anyhow... we are a bit off topic from my original post.    I now 
understand why GC is very slow on large datasets.

but its still possible to get that information, maybe it could be 
a refinement, as well as one for MEM stats (if its also heavy to 
resolve)

no but traversing the "heap" (which is what I am guessing he is doing) 
he can count all references to a particular item.  and YES it wil 
be slow.  but for debugging it could be EXTREMELY usefull.  even 
more would be returning all the items which the GC has encountered 
which have references)

but, taking into account, that it is not needed (the GC does not 
need to know that), it would be a waste of time/code

REBOL isn't heading towards less error triggering as a rule (though 
there may be less in practice); it is headed towards making errors 
trigger on more useful occasions. The principle is that errors are 
your friends, and if they aren't, we need to reevaluate them on a 
case by case basis. In some cases we have made things trigger an 
error in R3 that didn't in R2, with the hope of overall benefits 
in security, stability and debuggability. We even added ASSERT to 
explicitly trigger errors.

In the case of LENGTH? and INDEX?, we are only allowing them to return 
none when passed none, using none as the equivalent of SQL's unknown, 
not N/A. And even those are a bit iffy - we are only planing to allow 
those to have fewer intermediate none checks when doing none pass-through 
on FIND and SELECT return values. However, the disadvantage is that 
errors aren't triggered close enough to the source of the error. 
Hopefully they will be triggered later by ASSERT calls.

maxim I vote for your proposal legth? to return none if the argument 
can't be traversed  could be a test on the type of the tested thing 
but arfter ready your  way to present this I'm kinda convinced ... 
As for the GC discussion I very liked the " it doesn't work like 
this but I don't know anything about how it works" isn't that a mutual 
exclusion ?

We don't know the exact algorithm, but we know a lot about it, and 
that it's proprietary.

that's the kind of high level discussion that should conclude by 
a high level documentation about memory management and gc predictions 
... but probably better wasting the oportunity ... once again. I 
would not ask why?

I think adding a system like generational would be a big benefit 
to REBOL.  my guess is that Carl has a twist on this idea.

it's not the first time we have this discussion years ago we had 
this discussion about GC and memory management it's a cyclic concern 
and a cyclic discussion until we don't DC it :) ( Document & Collect 
it)

and because memory isn't released to the OS very often, I can make 
a fair guess that the GC doesn't compact on collect.

and clearly speaking about guru level stuff and not having a begining 
of a trail on such an issue makes me crazy just because noone wants 
to do this basic effort ...

unless Carl did a document about it, which would be very nice.  (hint 
hint ... RM-Asset guys?  ;-)

maxim hum you know you do a splendid documentation full of stupidities 
to make Carl go on verbose mode and correct it that's what it's called 
preach the false to obtain the true :)

spycology... hahaha... typo or not, its a good word.

The main reason that we haven't speculated on it is that it doesn't 
really matter what the real algorithm is, since it's internal and 
can't be swapped. All that matters is externally determinable traits, 
like whether data can move and when. Any moving collector requires 
a lot more effort to work with C libraries and extensions; that includes 
copying and generational collectors.

brianh in fact we had speculate alot of it with steeve and maxim 
around  spring 2009  when we were researching area-tc ... at that 
time i should have done a completly stupid high level documentation 
full of speculations maybe by now we would have better view on this 
particular topic

the extensions API actually marshals all of that so the internals 
of the GC don't really affect the host kit that much.  


A part from the raw image! data, we don't really have any reason 
to believe that any pointer we share with the core is persistent.


In any case I don't rely on it, because AFAIK Carl has insinuated 
that we never really have access to the internals and pointers we 
get are actually interfaces, not interal references (for security 
reasons).

the issue is that the GC does affect my code a lot in big apps and 
I'd like to know exactly when and how it works so I can better guess 
when its about to jerk my code in an animation or while I'm scrolling 
stuff.

exactly when and how it works
 - there are at least two reasons why this is what you can't get:


1) *when* the GC works is "unpredictable" from the programmer's POV 
(depending on other code, etc.)

2) It is (or may be) subject to adjustments or changes, without the 
programmer being able to detect such changes, so why should he know?

3) programming for a specific GC variant should be seen as a typical 
bad practice - why should you want to make code that is supposed 
to work only in specific circumstances? Not to mention, that you 
actually cannot do that anyway, since the GC should be programmed 
to hide any implementation details

Refcounting w/ cycle detection or or a hybrid refcounting + tracing 
approach certainly can.

But in various bits and pieces of REBOL documentation it's hinted 
at that the REBOL GC being a tracing mark-sweep variant. And I seem 
to recall that Carl affirmed this at least once, but I don't have 
any link to the source handy.

also If it has several heaps, or tricks like generations, or whatever 
, we can optimise the code so that we make it work in the "best case" 
of the GC instead of the worst case.


right now all I know is that the GC is very disruptive in very large 
apps (in R2) because you can actually see the application jam for 
a noticeable amount of time when there is animation or interactive 
things being done.

Alas, that kind of problem is exactly why you don't want to rely 
on the implementation model of the GC. One thing we know about the 
GC is that it is the stop the world type. If we need to solve the 
problem you mention, we would have to completely replace the internal 
memory model with a different one and use a GC with a completely 
different algorithm (generational, incremental, parallel, whatever). 
That means that all of your code optimizations would no longer work. 
If you don't try to optimize your code to the GC, it makes it possible 
to optimize the GC itself.

BrianH, if I deliver an application to a client and he says to my 
face... why does it jerk every 2 seconds?


I really don't care about if the GC might change.  right now I can't 
do anything to help it.


if it changes, I will adapt my code to it again.   This is platform 
tuning and it is inherently "close to the metal", but in the real 
life, such things are usefull to do... 

just look at the 1 second boot linux machine in that other group.

something like this document (which has a Best Practices at the end) 
would be really nice.


http://vineetgupta.spaces.live.com/blog/cns!8DE4BDC896BEE1AD!1104.entry

obviously, since the GC is a "stop the world" system, I can't fix 
everything, but I might be able to help it along a little bit.

I'm hoping that we might get a better collector when we work R3 over 
for concurrency.

easier being a relative term  ;-)

It might be the other way around. It's harder to stop a multitasking 
world than it is to stop a single-tasking one...

How about a minor addition to/restructuring of the comparison functions:
- equal?
- equiv?: equal + binding

- strict-equal?: equal + type + case + alias + decimal  (but _no_ 
binding)
- srict-equiv?: strict-equal + binding
- same?: as currently


(See http://www.rebol.net/wiki/Comparisons#EQUAL.3Ffor the status 
quo.)

What we seem to be missing at the moment is a comparison function 
with ignores binding but is otherwise "strict" in the sense of type/case/alias/decimal 
precision.

If we had such a function, the discussion around #1830 and related 
issues (such as a more useful map! type) would be much easier.

Either in the default case, or with a /case, /strict or /whatever 
refinement.

Framed this way, this discussion would be a lot easier, imo; and 
probably more fruitful.

That is a seperate issue that needs its own ticket. FIND and SELECT 
use their own code, so they can only follow the same rules, not use 
the same code.

That is an implementation problem, not a design issue

I am OK with a DAG for the equivalences, but would prefer the exact 
decimal comparison to go in the EQUIV?, STRICT-EQUIV? branch.

Fine with me, but most likely only a minor issue.

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

If you want I can write up your reshuffled hierarchy as a CC ticket. 
I think Carl would like it, ans the binding issue has bit him in 
the past.

(Or a renamed /case option. A bit hypothetical due to backwards compatibility, 
but mentioning it for the sake of completeness.)

Yes, I have a suggestion: my explicit wish was to wait with this 
for Ladislav's feedback.

I put in a request for Ladislav's feedback in a ticket comment, and 
in other AltME worlds where he works. Including the RMA world, where 
they write code that would be affected by this.

Unlike here, tickets can be tweaked based on feedback. We needed 
a baseline to start with.

Unlike here, extensive CC discussions are a mess.

They're a mess here too, but are more useless because they can't 
be searched as easily once they drop off the history, and the relevant 
people who would make the changes aren't generally here that much.. 
CC is a much better place for this kind of thing.

And it's really simple: I wanted Ladislav's feedback here first, 
before we write up a ticket and litter it with useless comments. 
Again, please respect that in the future.

At least I don't know of a way off hand to prove that.

Actually, that feature might go away. The ALIAS function has been 
a big hassle in R3 because of the lack of a central system/words 
repository. We are likely to keep the aliasing facility for internal 
use to implement case insensitivity, but the ALIAS function to do 
other kinds of aliasing may go away.

Hmm, I would prefer the current state, then:


- == is what I would use frequently, while I would not want to use 
=? in place of it, because of the difference

- the change would require quite a lot of work, and where is a guarantee, 
that a new idea does not occur in a couple of weeks again?

>> a: 42
== 42

>> alias 'a "b"
== b

>> equal? 'a 'b
== true

That reminds me, need to check whether there is a ticket to remove 
ALIAS.

Also, get rid of the *NOT* mentions in the main body. If at all, 
mention that in a remark at the end of the ticket.

Interesting. How does that happen? I thought SAME? just did a bit-for-bit 
comparison.

(Maybe add a blank linke before the - EQUAL? item.)(