r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[Core] Discuss core issues

Ladislav
21-Aug-2005
[1694x4]
Re DEFAULT. It looks, that a version with implicit variable may be 
more popular:

default: func [
    {Execute code. If error occurs, execute fault.}
    [throw]
    code [block!] {Code to execute}
    fault [block!] {Error handler}
] [
    either error? set/any 'code try code [
        fault: make function! [[throw] error [error!]] fault
		fault code
    ] [get/any 'code]
]
this one uses 'error as the error variable
note: although it looks safe, it may become a victim of the GC bug 
I described in RAMBO group recently. A slower but safer implementation 
is:

default: func [
    {Execute code. If error occurs, execute fault.}
    [throw]
    code [block!] {Code to execute}
    fault [block!] {Error handler}
] [
    either error? set/any 'code try code [
        do make function! [[throw] error [error!]] fault
    ] [get/any 'code]
]
sorry, correction:

default: func [
    {Execute code. If error occurs, execute fault.}
    [throw]
    code [block!] {Code to execute}
    fault [block!] {Error handler}
] [
    either error? set/any 'code try code [
        do make function! [[throw] error [error!]] fault code
    ] [get/any 'code]
]
Volker
21-Aug-2005
[1698]
gc-bug: i prefer the function which overwrites itself cares about 
that, else a lot code will be bloated. caring means plug somewhere 
reachable from global context, like dont-gc-me: :me
Ladislav
21-Aug-2005
[1699x2]
the above code is exactly the case where your suggestion cannot help
moreover, it is more bloated, than the actual solution used
Volker
21-Aug-2005
[1701]
yes, could not get me own function there. but would not reload myself 
by 'default then.
Ladislav
21-Aug-2005
[1702]
sorry, I don't understand the last post?
Volker
21-Aug-2005
[1703]
i would not use default when i know i would trigger the gc-bug.
Ladislav
21-Aug-2005
[1704]
the last version will not trigger it
Volker
21-Aug-2005
[1705x2]
the only time i trap about that bug is when i do a script i did before, 
thus overwriting the loading function.
and in that case i prefer to care mayelf isntead of forcing every 
tool to be aware of it.
Ladislav
21-Aug-2005
[1707]
you don't overwrite the function at all - Rebol functions are anonymous 
in nature, it is just an interpreter bug
Volker
21-Aug-2005
[1708x2]
ok, overwrite the only reference from the global context.
if a safe version is no effort or even shorter, thats ok, will not 
stop that.
Ladislav
21-Aug-2005
[1710]
did you notice why the former version above may become a victim of 
the GC bug while not looking like overwriting the reference?
Volker
21-Aug-2005
[1711x2]
hmm, started re-reading just a moment before. thought maybe i miss 
something.
No, i dont see how. everything is referenced from locals. as long 
as you don't overwrite 'default itself, it should work?
Ladislav
21-Aug-2005
[1713]
actually not, the problem is this:

default [1 / 0] [default [2 / 0] [...] print mold disarm error]
Volker
21-Aug-2005
[1714x2]
but i missed the point anyway, thought 'default takes care if i overwrite 
my own function. to hasty. its because of its own created function 
i guess.
oh, recursion. and locals on the recursion-stack are not checked 
too?
Ladislav
21-Aug-2005
[1716]
aha, it *may* work, I didn't check it
Volker
21-Aug-2005
[1717]
Hope with your bug-example Carl has an easy (and thus quick) time 
to fix it :)
Ladislav
21-Aug-2005
[1718]
when we use DO method, we are *declaring* the function as anonymous 
and the interpreter takes care, the only problem may occur, when 
the interpreter handles the function as *named*, although that shouldn't 
matter, because every Rebol function is essentially anonymous
Volker
21-Aug-2005
[1719x2]
it matters because the gc does not scan the c-stack correctly i guess. 
and its using c-stack for nesting.
so the anonymous reference there does not count, is overlooked. You 
need another one, usually that from the functions name. kill that, 
next gc bang. 'do takes more care somehow.
Ladislav
21-Aug-2005
[1721]
actually DO names the function as its argument in a sense, that is 
why the original name isn't needed
Volker
21-Aug-2005
[1722]
hmm, native functions could have argument-lists like normal ones, 
and then its "named" in that list? could be.
Ladislav
21-Aug-2005
[1723]
funny, isn't it?
Volker
21-Aug-2005
[1724]
:-)
Anton
22-Aug-2005
[1725]
I believe, since you can expect the crash to be fixed some time in 
the future, that the solution is to provide both versions of the 
function, the fast, vulnerable version commented, and a note explaining 
when to switch from the slow, safe version to the fast, vulnerable 
version (preferably with test code to prove if your interpreter has 
the crash or not).
Volker
22-Aug-2005
[1726]
To me the "sfae but slow"-version with 'do looks more elegant. i 
doubt it is slower. but i may compare the wrong sources, lots of 
them..
MikeL
22-Aug-2005
[1727]
Topic - needs or includes.... I am just cleaning up some scripts 
and want to use the dynamic load capability that I thought was enabled 
by pre-requisite setting in the REBOL header.    The only link I 
can find is to the Values.R in the library.   Is there a standard 
approach to this?   Now I am using Carl's %include.r from the script 
library but it does not check for prior loading.
Geomol
23-Aug-2005
[1728]
I don't think, it's initially possible to check, if a certain script 
has been loaded or not. One approach, that is often seen in C includes, 
is to have a big 'if' in the script around all the code there, which 
checks on a define, and inside the 'if' define the thing being checked 
on.


I'm searching for a good 'include' myself from time to time. One 
where it's possible to include something without full path. Maybe 
variables like system/options/path, system/options/home or system/options/boot 
should be used.
Ladislav
23-Aug-2005
[1729]
wrong, my include does it
Geomol
23-Aug-2005
[1730x2]
:-)
Ladislav, clever approach with the included block! Thanks!
Ladislav
23-Aug-2005
[1732]
check the latest INCLUDE now, http://www.fm.vslib.cz/~ladislav/rebol/include.r
Geomol
23-Aug-2005
[1733x2]
How do you include "include.r" in your projects? Something like putting 
it in the home directory and type:
do join system/options/home %include.r
It should be part of REBOL.
Ladislav
23-Aug-2005
[1735x2]
yes, I put it in %user.r together with a definition of a suitable 
INCLUDE-PATH
OTOH, if you mean how can I build a script containing INCLUDE, it 
can be done too, the easiest way is to use #include-string for that 
to prevent the "execution" of the preprocessor instructions defined 
in %include.r
Geomol
23-Aug-2005
[1737x2]
The new Core 2.6.0 in View 1.3 is running the user.r found by the 
environment variable APPDATA, it seems. On my Windows computer, it's 
in C:\Documents and Settings\John\Application Data\rebol\ , even 
if I install REBOL/View in E:\rebol\view\. Is it a good way of doing 
it? I find it a bit confusing.
WinXP, that is. I wonder, how it is under Win98, Win2000 and Linux?
MikeL
23-Aug-2005
[1739]
Thank you Ladislav.  More than I had hoped for.   p.s. is there much 
of a penalty for using include/check instead of include?
Ladislav
23-Aug-2005
[1740x3]
I didn't measure that but it doesn't matter to me, because Include 
isn't used often anyway
I think, that it is unnoticeable
the slowest part of INCLUDE work is read anyway
MikeL
23-Aug-2005
[1743]
Great then I will use include/check as the default usage and may 
save some slow file access time in sub-modules.  Thanks again.