AltME groups: search

If you need it to be robust, and talk to mtuliple versions of Outlook 
(e.g. used by others who may have a different version), consider 
using Redemption. It is robust and well worth the money IMO.

I know that a companny has built a full integration to outlook supporting 
more than a single version of outlook... AFAIK they used Anton's 
com lib .

florin, it might just be a config issue.   did you get the comlib 
to do anything within excel?  IIRC Anton's comlib has a few examples 
for excel and word.  getting that to work first will make outlook 
attempts a bit easier.

Dumb question: How is it that I solve this?

>> set to-word "a" 2
** Script error: a word is not bound to a context
** Where: set
** Near: set to-word "a" 2

There's probably some easier way than this, I hope:

>> x: 1
== 1
>> set bind to word! "a" 'x 2
== 2
>> a
== 2

wow rebol has become perharps a bit too picking about binding?

did someone forget that REBOL is supposed to be "simple" ?

LOAD loads and binds strings except being told otherwise with /UNBOUND:

>> set load "a" 2
== 2
>> set load/unbound "a" 2
** Script error: a word is not bound to a context
** Where: set
** Near: set load/unbound "a" 6

I don't think it's especially picky the way this is.

because we now have unbind and generally much more control over the 
binding, I would have thought that auto-binding to user context wouldn't 
be such a big issue.

May I withdraw my suggestion? Don't use is in tight loops:

>> dt [loop 100000 [set load "a" 2]]
== 0:00:02.017813

>> dt [loop 100000 [set bind to word! "a" 's 2]]
== 0:00:00.079424

well, then there has to be a better way to do that. some kind of 
default-bind.

I just discoverd this func...    

utf?

in some fonts the u looks like a w... hehehe

set bind/new to word! "a" self 2
or
set bind/new to word! "a" system/contexts/user 2

Max, it's a dialect: 'ut th' fu'?

Though perhaps we could have a WTF? error-related func.

A refinement for SET might be very handy for the unbound scenario, 
and BrianH may chime in with the design logic to help clarify.

yes.... wtf? as a small undocumented easter egg could be a nice little 
rebol detail   :-D   

basically it could be an alias for why?

Maybe combined with a stack dump? That is, when you say WTF? you 
need all the help you can get. And the refinement for even more info 
would be /!. ;-)

>> test: func [/a] [all [a 'a]]
>> test/a
== a

>> test/A
== a

>> test: [a 1 A 2]
== [a 1 A 2]

>> test/a
== 1

>> test/A
== none


This is dowright unexpected, I'd consider it a bug, what do you think? 
You'd better curecode this, I guess.

MAx: "did someone forget that REBOL is supposed to be "simple" ?"

Did you miss this blog:  http://www.rebol.com/article/0374.html

Simplicity is a thing of the past.

I thought that was not a good post myself ...

People use things at different levels of expertise ... and if there 
are enough experts around to critique their work, they will get better. 
 So, the differing programming styles seen are a reflection of Rebol's 
failure.

is there a function to recursively delete a directory? I should probably 
have asked before I wrote one. :-)

Optimizing file deletes means first avoiding the standard DELETE 
func. It reads the dir each time which can kill you if you have a 
large dir or, heaven forbid, point it at an FTP location. You can 
build on CLEAR easily though.

    delete-all-files-in-dir: func [dir /local port] [
        port: open dir
        clear port
        close port
    ]


I think my tree deleters all rely on some of my other stuff, like 
FILE-LIST and DO-IN-DIR (now standard as IN-DIR). They generally 
have a callback option as well, so you can track progress.

I have a version that redefines delete that I wrote for QM: http://www.ross-gill.com/r/brutal-delete.html


It has an optional /pare refinement that deletes empty parent folders 
too.

It's defined only to take URLs (as QM doesn't access files directly) 
but I think should work adding a file! argument.

Interesting. I think that's a bug, as CLEAR's spec is as follows:

clear: make action! [[

    {Removes all values. For series, removes from current index to tail 
    and returns tail.  (Modifies)}
    series [series! port! map! gob! bitset! none!]
]]

From a quick glance at the host kit, I think implementing it would 
be rather easy (basically another special case for RFM_TRUNCATE for 
RFM_DIR in Write_File in dev-file.c). But wiring it up to the directory 
port actor is beyond our freedoms with the hostkit, I think.

Would it make sense, or even be possible, for RT to do all the internal 
wiring for port actors, with a default TBD stub that people replace 
when working on their host kit?

Use system/options/args to get the list of arguments as they come 
from the operating system.


system/script/args is more like a rejoin of system/options/args. 
LAUNCH seems to not be doing much more than what CALL does, which 
means there is no escaping of the operating system's shell special 
characters. If CALL/INPUT did not imply /WAIT, it could have been 
a better way to pass REBOL data to a new process.

LAUNCH is undergoing revision in R3 these days and is a mezz, not 
a native, but the problem seems not to be on the side of LAUNCH.

>> a
== make map! [
    e 4
]

>> a/b: func [][print 3]
>> a/b
3

shoudn't it return a function type?

docs just say "not documented"
    http://www.rebol.com/r3/docs/datatypes/map.html
Use select a 'b to return the function itself
Use curecode to get the behaviour normalised :)

Maxim: "shoudn't resolve have a refinement called /bind  making it 
easier to rebind data to target context in a single pass?"

There is a REBIND internal function that hasn't been exported yet. 
Ask Carl or request in CureCode for the function to be exported.

Now for the other binding stuff:


* SET is a low-level function that would be slowed down immensely 
by adding any refinements.

* SET does handle the unbound scenario: It triggers an error. You 
can then handle the error.

* R2 and R3 get their speed from the direct binding model. The core 
speedup of that model is that SET doesn't bind.


* LOAD in R3 is a high-level mezzanine function. It is meant to be 
as fast as possible given its purpose, but being fast is not its 
main goal; user-level flexibility is. Most of the overhead of LOAD 
is in handling all of its various options, as refinements, file extensions 
and script header settings. If you know what you are doing, you can 
always optimize your code by doing it directly instead of having 
LOAD try to figure out that is what you want to do. LOAD is not meant 
for use in tight loops.


* Henrik, ChristianE, the R3 standard answer to the question of how 
to make BIND TO-WORD "a" more efficient or friendly in R3 is this: 
You are encouraged to not program that way in R3. Converting strings 
to words is something you should do once, not all the time in tight 
loops. Your code will be much more efficient if you work in REBOL 
data rather than storing your code in strings and converting at runtime. 
Strings are for data, or script source, not for containing scripts 
at runtime. This is a good rule for all REBOL versions, but especially 
for R3 with its Unicode strings vs. shared UTF-8 words.


* I have recently refactored LOAD so that it is broken into smaller, 
more efficient functions. You might find that those functions would 
work better for you in lower-level code. But this was done to let 
us make LOAD *more* powerful, not less, so the same advice I gave 
above about not using LOAD in tight loops still applies. I don't 
yet know if the new LOAD is faster or slower, but it is safer and 
easier to understand and modify, and you can make your own LOAD replacement 
that calls the same low-level functions if you like. Plus, you get 
compressed scripts :)

Maxim, maps are meant to be used like objects, but with different 
tradeoffs. The evaluation that you show is not a bug, it is by design, 
and it works for functions stored in blocks as well.
>> a: reduce ['b func [] [3]]
== [b make function! [[][3]]]
>> a/b
== 3

Use get-paths if you don't want evaluation:
>> print mold :a/b
make function! [[][3]]

So the evaluation has nothing to do with maps, it's a path evaluation 
thing. You can still store stuff in a map, but as with storing active 
values anywhere you have to be careful.

yeah, ok, so its not a map thing... that is now obvious, since the 
select doesn't evaluate it..

Carl requested the modularization. And I definitely wanted to do 
it because the whole module and script system didn't pass the hit-by-a-bus 
requirement.

brianH  " increased language consistency" if this where true, then 
we couldn't store object in blocks without evaluating them by default 
either. 


IMHO maps are just hash tables, just like a block.... storage, not 
vector jump tables.   but that might just me my skewed view of the 
world.

oops... sorry my last statement was a bit messed up... ignore the 
first line...

Well, it sure _is_ more consistent to always have paths which ultimately 
refer to a function! make the function an "active" value.

Yeah, and that illustrates the consistency argument: if paths with 
a map! as underlying would be redefined to behave like get-paths 
per default, what should get-paths on maps do :) ?

Hi, I corrected http://www.fm.tul.cz/~ladislav/rebol/evaluate.r(I 
omitted a USE-RULE call for the last rule in the script), and renamed 
the accumulator 'a in accordance with industry standards.


Also, I added an efficiency note related to R3 protection disallowing 
us to use a simple binding method to create the USE-RULEs during 
function initialization (creation) instead of creating the USE-RULEs 
every time the respective function is called, which is inefficient.


I wonder, whether we should consider a way how to allow the creator 
of the function to perform some additional initialization during 
function creation.

As I demonstrated in the %use-rule.r script, such an initialization 
is possible using a method to circumvent the protection R3 uses, 
but it looks neither simple, nor very efficient.

bleeeah :-) REBOL as a messaging language has networking protocols 
being an optional package = no standard functionality over the REBOL 
installations. Great, what's removed by default next?

Let's use DECODE-CGI as a simple example: currently in R2, you fire 
up R2 and can use decode-cgi in your code straight away.

The question is what tradeoffs are best? I have to say, even with 
Base available, I like having everything just work out of the box. 
How much does each exclusion save us? This is a tough call. Of course 
I want things lean and mean, but I also don't want every script I 
write to have 5 or 10 lines of import statements for what we've come 
to expect as standard functionality.


Do we have any kind of cross reference or dependency list? That is, 
do we know exactly what we're talking about?

And you can do imports in the header, or on a single line.

and the plus package is on by default, unless you switch it off on 
the command-line.  which is a good idea IMO.

IMPORT with a block! as argument does the same as the NEEDS block 
in a header.

Right, what I don't want is to have to explicitly import "basic functionality" 
in every script. The question is what is basic? And while we can 
certainly do it in a single header line, that's far from the same 
as having it "just work". 


I just want to make sure we're saving enough to make it worthwhile. 
You know how I hate premature optimization. ;-)

So we know if we allow a url! as an arg we're sure to get all the 
protcols that are supported for any url! we might get.

If we had a list of modules, along with their cost in memory consumption, 
"clutter", and load time, it would be easy to weigh their value.

extra == "plus". In a recent CC bug Carl for example mentioned having 
LAST? in core and moving SINGLE? to plus, if it is still wanted.

hum... the comma there makes the sentence a bit weird... ignore it...

Maybe a pseudo-module named 'full, then import 'full will do.

And I'm sure there'll be a way to just put the import in user.r/rebol.r 
and be done with it.

Andreas, while the typing is simple, do you agree that you aren't 
just going to type it once, and that there is a cognitive overhead 
to defining the imports?

Again, I'm not necessarily against it, as long as there is a benefit. 
If the benefit is 3ms faster loading and 30K less memory consumption, 
I will probably say that my time is more valuable than that. :-)

3ms would be a startup time improvement of over 10%.

In a CGI use case, that is _definitely_ worth it.

It wouldn't help a CGI script, because it would need to import CGI, 
HTTP, HTTPS, ... ;-)

Don't be that anxious about your console. Once modularisation is 
done, it is ridiculously easy to get back a REBOL console with all 
modules and then some enabled and ready to use just like nothing 
ever happened.

It would help a CGI script a lot, because it won't have to import 
20 network protocols it never uses. But I sure noticed the ;-) at 
the end :)

But I have a new idea, based on what is possible with the new modules 
(that haven't been integrated yet), so let's move there :)

There is no reason that R3 can't have standard builds that include 
everything. In fact, the blog says as much: Most of the options are 
opt-out based on a command line option, not opt-in. But we definitely 
need some stuff to be opt-in, like graphics stuff on OSes like Linux 
that don't necessarily have the supporting libraries.

Added bug#1664 "Rename the issue! datatype". I think the basic wish 
is rather uncontroversial, but naming is hard. If you have any good 
ideas for a name, please comment: 

http://www.curecode.org/rebol3/ticket.rsp?id=1664

ANY-WORD! is a typeset of value: make typeset! [word! set-word! get-word! 
lit-word! refinement! issue!]

Could also use symbol!, but I think it would be a shame to waste 
that nice name on this mundane datatype :)

it also makes 'LIB a reserved word in general, which is not really 
cool either.


I would much prefer if carl at least used the full word 'LIBRARY 
and also 'SYSTEM.. . not 'SYS or 'LIB.


I am sure another word is even better than 'LIB, but 'EXPORTS always 
was perfect already.... so why change that?

I am wrtiting a big blog post on Carl's REBOL blog since he posted 
an entire post on this specific rename....

I did a little of research... and found (remembered) the exact word 
it should be called.   

'RESIDENT

Having short words for the 'lib and 'sys contexts opens a lot of 
possibilities for system simplification. If they are renamed to something 
else, make sure that the replacement words are no longer than 4 characters 
each. And if you don't predefine them in the 'lib context, definitely 
make sute that they are predefined and protected in the 'sys context 
- that way the at least the system code won't be as disadvantaged 
as the user code will be by not including them in 'lib.

These are words that will be referenced a *lot*, both of them, so 
we want them to be really short.

Why would they be referenced a lot?

BrianH: that does not change the fact, that 'lib as a name sucks 
a lot. It says namely nothing, and in my eyes is a degradation from 
'exports ....

You export into the common shared library, or lib for short. The 
word "lib" is a common abbreviation for "library" for english-speaking 
programmers, so if you use the word 'lib the first thing many people 
will think you mean is library. Carl is right that the name reflects 
how the system works in practice. The lib context is a shared common 
import library.

Why would they be referenced a lot?

 - Because we are trying to make using your own versions of the built-in 
 functions as easy as possible, especially through using local definitions 
 of the words. No reserved words in the DO dialect (except the two 
 in MAKE module!). In some cases *only* through using local redefinitions 
 of the words because the built-in definitions may need to be protected 
 from modification. This means that we want to make referencing the 
 built-in definitions as easy and concise as possible. 


This especially the case with the 'sys word, since the context it 
refers to isn't imported by default because it is the context for 
system internals (no, we can't use 'int). When you need to access 
the publicly visible words of 'sys you won't be able to get them 
imported: sys is not a module. You can copy over the words manually 
(maybe with the EXTEND enhancements).


Whether or not the 'lib and 'sys words are defined in the 'lib context, 
they definitely need to be defined where the mezzanines are being 
implemented (which is likely a combination of the lib and sys contexts, 
we shall see). Don't handicap the implementors of R3 just because 
you want to handicap yourself.

Maxim, you made a couple of wrong statements:

it obfuscates the meaning of what that context is...
 (about changing 'exports to 'lib):

Actually, if you read the boot levels blog post, you might notice 
that the R3 module system is now optional at the base boot level, 
and to a certain extent at the sys boot level too. The new role of 
the 'lib context is to be a runtime library - it is not dependent 
on the module system anymore, nor does it necessarily contain any 
exports from anything.

it also makes 'LIB a reserved word in general

Nope, you can override 'lib or 'sys locally in any module or script 
you need to. It might not be a good idea to do so, but that doesn't 
mean that it is not trivially possible. On the other hand, in top-level 
module code the words 'export and 'hidden *are* reserved keywords, 
so watch out.

One further question to boot-levels. There are three. And the top 
one is:


mods: initialize up to and including lower-level resident modules. 
In addition to boot-sys, this level adds high-priority resident modules, 
but not mezz plus (higher level mezzanines). 


I am a bit confused - what should I use for CGI? E.g. I don't need 
help, etc.

For most actual users of the issue! type the new issues will be faster 
to use. And the "running out of words" argument isn't anywhere near 
as much of a problem as it is in R2, as noone has yet run out of 
words in R3 afaik.

I am a user, I should not care for the technical mumbo-jumbo :-)

Most of the time you won't specify a boot level at all.

All I needed to know in the past is, that for CGI I need fast system, 
which will not load unnecessary code, e.g. help, etc. Hence I used 
/base executable. Now:


base - initialize only the lower levels. This option is for special 
purpose testing only because it provides no way to load external 
code. (No schemes, such as file access, nor load or do functions.) 
If your host-kit build is crashing on startup, you can use this option 
to confirm that the exe image is loadable and runable.


sys - initialize up to and including the basic runtime lib and sys 
contexts. This option allows you to run a very "lean" system (minimal 
memory and boot time) where your code will be supplying all other 
run-time functions and modules. Provides a basic load function but 
with very limited special options (no import, needs, versions, or 
related features.)


mods - initialize up to and including lower-level resident modules. 
In addition to boot-sys, this level adds high-priority resident modules, 
but not mezz plus (higher level mezzanines).

The 'base boot level *is* the minimal running REBOL environment. 
It's just that R3 can run in a *much* more minimal environment than 
R2 can, so the base is smaller. At least Paul should be happy, as 
he has been requesting this for R2.

Now I want to understand 'sys level - "Provides a basic load function 
but with very limited special options (no import, needs, versions, 
or related features.)" - I don't understand the "no import" argument 
- so I can't use modules here?

Right. People who thought that the 'lib context is just a renaming 
of 'exports were way off.

No, it wouldn't, because there are still a few opt-in modules that 
are included but not imported by default. For instance, modules that 
implement conflicting functionality, such as CGI vs. GUI.

It only sounds cryptic because it isn't done yet. A system redesign 
has been planned for a while now, but we had to nail down the semantics 
of the language first and fix a *lot* of bugs.

I am putting the finishing touches on the initial implementation. 
More tweaks will be necessary for the integration (mostly renaming 
variables), but the new system model will simplify things a bit. 
In particular, the predefined 'sys word makes the module-tools mixin 
unnecessary, which simplifies the bootstrapping and use of the system 
immensely.

Well, there was a new feature required (delayed modules) that when 
added had wide-reaching implications for the rest of the module system, 
and caused a bunch of other features and the improving of others 
as a side-effect. Also, the old module system violated the "hit by 
a bus" principle: I was the only person who understood the code fully, 
so noone else could modify or enhance the code, and if I went away 
the code would become instantly unmaintainable. So the new code is 
easier to use, does more, and can be understood by the average REBOL 
guru. Believe me, it was that last part that has been the trickiest.

BrianH note that if you read my blog posts, I am rooting for 'RESIDENT... 
not 'EXPORTS.


and thanks for your better explanations they shed a little bit more 
light on the whole thing.

Don't handicap the implementors of R3 just because you want to handicap 
yourself.


Don't harm the users of R3 just because you are a lazy implementor.

But it will be easier to discuss this once there is a concrete implementation 
to play with and discuss, not just vapour.

I hope this is not the case, however following is scary, while understandable 
-  ".... a fight between simplicity and complexity, between maintainability 
and chaos, between elegance and ugliness"

no Brian is doing the module work, its just that the changes to how 
the contexts are now layed out provoke deep changes in how things 
are bound.


because that is a big part of the module system's job, it means Brian 
has to update a lot of the code.


also remember that Brian has been splitting up the module code into 
sub-functions, so all of that makes it simpler, and more re-usable.

They where coding at opposite ends of the spectrum, now they are 
fighting to merge the two together.  that's how I read it.


IMO its just a question of getting it to work again. with new contexts 
layout and new, better module functionality.

I like the following part :-) "Some of you may be saying "Carl, we 
don't care." Yes, I know, I've heard that before. But, (if I had 
a Yoda voice, I'd use it here) you will care. You just don't know 
it yet."

The module system has grown to include many advanced features, which 
are all usefull and viable.  Brian has been working to simplify the 
code by breaking it up into smaller pieces.   At some point you can't 
have features without at least a minimal amount of code.


The new contexts layout makes it a more complex task because my guess 
is that basically, its broken everywhere and that is hard to debug.


The original module system wasn't very powerfull in the sense that 
it didn't add much more than special objects... what Brian is doing 
is sooooo much more than that.

I've looked at the module code and it was a large and barely understandable 
by its complexity.  Even by Brian.   He was already working on this 
problem... its just that now that its all broken, they can't ignore 
it anymore  ;-)>