AltME groups: search

Thanks. 

That's useful evidence that the problem is not network or server 
related [rebol3 and rebol-gate run on the same server]


Next step ---  is it better or worse in groups with many messages? 
(ie is the problem the world or the group):

--could you try a test post or two in a couple of groups that have 
less than 100 posts?
  list available here: http://www.rebol.org/aga-index.r

it just limits what is visible in your scrollable view above.   it 
will affect speed so much as it uses less faces to display the list 
and thus less RAM is managed by the GC.

hmm, strange - I received your PM, but your name in the list was 
not in red letters ....

Strange ... I saw red from both of you.

Did my name float to the top of the list, or was it buried a long 
way down?

It was at the top of the list.

That way, we can miss if someone contacts us. So the urge is to check 
if some name is at the top of the list, and better check from time 
to time ....

Cancel that gripe.....I think it just took a while to resync and 
update the list.

I noticed something interesting: When you are reading a red group, 
the column in the left hand side is colored yellow for unread posts. 
When switching group, there is for me a waiting period of about 2-3 
seconds, for large groups before the new group appears.


However before the group switches, the coloration disappears, suggesting 
that a redraw of the list takes place before the switch. If this 
redraw was removed, switching columns might take much less time, 
perhaps half as long.

I'm not opposed to having the mailing list continue, but really dread 
having to use it, which I will have to if it starts being used.

What drives me nuts with AltME is, that when it's reconnecting, that 
it switches display and don't just stay at the group and message 
where I am. It resets the list etc.

another perhaps tricky element would be to solve the message limit. 
it seems currently to directly conflict with the memory usage of 
altME, due to the pane size of the message list. so we'd need an 
endlessly scrollable message list with variable height rows.

If you click on the little wrench over the groups list, you can mark 
all messages read once.

I'm talking like 100 times worse!   the larger the list the worse 
it gets... seems like an exponential issue.

Is there a list of  words reserved for parse, as

>> parse "a b" [ copy limit to " " ]

** Script error: PARSE - command cannot be used as variable: limit
** Where: parse
** Near: parse "a b" [copy limit to " "]

>> parse "a b" [ limit ]

** Internal error: reserved for future use (or not yet implemented)
** Where: parse
** Near: parse "a b" [limit]

The 'self in the argument list duplicate word bug is separate.

Carl's doc is too high-level to be helpful here. His list of tests 
is better, but still incomplete.

R3 97 released for real.....long list of Curecode issues addressed:
   http://www.rebol.com/r3/changes.html

I expect that the best use will be either making is-it-an-error-or-not 
changes like the above, or simplified versions of functions, perhaps 
for sandboxing. So remember this: If you have a nice, friendly native 
function with some advanced, evil options, put the most evil ones 
at the end of the list, so they can be hidden later if need be.

es5 adds a lot of new tricks for playing around with values.  the 
args list can be retrived, applied, changed, etc.  I'll admit the 
part about the code body is a bit fuzzy in my mind, but I seem to 
remember that you could play around with it in some way too.
 

playing around with the functions isn't exactly the same but the 
end results are very similar IMHO. 

especially since hot-patching isn't allowed in R3 anymore.

but its not in the series! list:

>> series? make gob! []
== false

It's the next thing on my list to rewrite PREBOL to be compatible 
with R3's module system. The syntax should be a compatible superset, 
but the internals will be a lot different.

It's the next thing on my list to rewrite PREBOL to be compatible 
with R3's module system. The syntax should be a compatible superset, 
but the internals will be a lot different.

  - hmm, reinventing the wheel? (my INCLUDE is already available from 
  rebol.org library and it has the properties you listed)

You should not be to much alarmed, the "It's the next thing on my 
list" is his favorite motto ;-)

Btw, "it's on my list" is more of a desperate cry for help nowadays. 
It's more of a "it's on my list to get done, because it's needed". 
Actually doing it myself is the last resort; getting someone else 
to do it is the preferred method. I'm more than happy to provide 
advice, but it's hard for me to budget time to program this myself.

That's not a long list of people at this point, but at least it's 
not just one person :)

Carl is working on bug-fixing, did two releases last week, and is 
working on extracting view from the core, which he has stated a while 
ago.


What do you want Carl to do more?     AFAIK, there is nothing "unknown" 
right now.   we are simply waiting for Carl to finish this cumbersome 
task before any  of the above *can* be done.


so far, Carl has been telling us everything he's doing every step 
of the way.   some things just take time.  its not as if Carl is 
waiting doing nothing.  

He's been working his ass off  tackling huge items on the list.  
Some of the very things you (and many of us) have been "complaining" 
about for years.

I need to identify what benefit I'm hoping to get over the current 
lexer which uses a static word list and regexes for capturing various 
bits

It's not about x-mas and what we would like to see in R3. I have 
a very simple priority list: What do we need to get to scale R3 development 
and avoid Carl being a bottelneck? What do we need to do to use R3 
to do a commerical app?

Graphics extension loads:

http://rebol.hmkdesign.dk/files/r3/gui/217.png

List of graphics functions:

http://rebol.hmkdesign.dk/files/r3/gui/218.png


There was a small demo to display a random collection of gobs, but 
a bug in the host kit prevents me from taking a screenshot.

We should also have a list of styles, and if a core GUI team member 
sketched out rough designs or inheritance/composition thoughts and 
prototypes, we stand a better chance of our work being used.

Yes, and? We can create dialects in R3 right now that are processed 
with native code; we've had that ability since the first extension 
model came out. If you want to make an optimized dialect, go right 
ahead. Cyphre is working on one, I have one on my list, others are 
considering working on them too.

With limited man power it makes sense to work on the most blocking 
aspects of R3 development.  I don't know if anyone has created such 
a list ... and whether it would be adhered to anyway, as development 
is being driven by politics and money.

This is a list of open projects .. but note that there is no prioritization 
visible

and you can specify a list of words, thus being entirely independent 
of the code inside.

Some counterexamples where we messed this up:

- "functions" have side effects so they aren't really functions, 
they are procedures with return values.

- "closures" aren't really closures, though they are closer to that 
than REBOL "functions" are.
- "contexts" aren't contextual
The list goes on.

AFAIK, your last example would trigger true no matter how we try 
to define it, cause the fact that you wrote 'orange and loaded it, 
it is defined as unset!  ' :-/


the reason is that words actually are just integers internally, and 
loading a word adds it to that list, so it can be used later.  this 
is why word comparison is so fast, its just comparing two integers.

I've created this function many times enough to think it should be 
standard:


; creates a string from a list of strings with human readable comma 
separation
string-list: func [blk /local out] [
	out: make string! 1000
	forall blk [
		append out form first blk

  unless tail? next blk [append out either tail? at blk 3 [" and "][", 
  "]]
	]
	out
]

string-list ["a" "b" "c"]
== "a, b and c"

modules, callbacks, memory leaks in the GC, memory exceptions, IPC 
and API for inter-thread data shareing, the potential list is long.

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.

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.

Right, so where is our list of options and dependencies?

Heh, _compiling_ that list of options and dependency is part of the 
work in progress, I think :)

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.

can someone please tell me how we can generate errors in R3.  cause-error 
has no list of appropriate values and everytime I've tried to use 
it it just fails with "you have no clue" errors.

It seems    do  to-error "whatever"    also works.


but I'd like to get the list of valid types and expected args for 
cause-error.

dataset browsing example : 

>>my-ctx: context [ a: 22 c: context [ b: 33]]
>>using my-ctx
>>current-words
== [a c]

>> using c
>> current-words
== [c]

>> using none
>> current-words
== [... list of current user context words ...]

If you want the reloading, use DO. DO works on scripts and modules 
both, and does them every time. It even tries to import the module 
after it is created. This is everything that you were requesting 
out of reloads. What it won't do is override a loaded module in the 
module list that is the same version or newer, but you can import 
those directly using IMPORT options.

The override rules in the system module list are sacrosanct though. 
You can load and use modules, but you can't override modules in the 
system list without following the rules.

You don't have to import to the system list for modules to be useful 
though. Look at IMPORT's /no-lib refinement. (After a110 comes out 
and it is fixed)

well the idea of supporting none is that they are not put into the 
system list to begin with, whatever their name or path.

What /no-lib does is converts a module to a private module. It does 
a full import directly into the user context instead of importing 
through lib. It doesn't even go into the system modules list as a 
reusable prebuilt module, which named private modules otherwise do.

BrianH: I just looked into Delayed extension note is CC - cool guru 
stuff :-) btw - do I understand it correctly, that unnamed modules 
will be named in module list, according to the filename? But what 
if there is unnamed module, which is not loaded from file?

OK, then it wasclearly my wrong guess :-) btw - how do you list unnamed 
modules in the module list then? or we don't? I thought that unnamed 
modules are auto-named according the file-name, but that would not 
be suficient anyway, as 1) one filename can contain multiple modules 
2) it still does not solve the case, when you create module e.g. 
in console manually ...

Unnamed modules (that stay unnamed) don't get listed in the module 
list. Instead, they get converted to private modules and get imported 
directly into the target context (system/contexts/user, or the context 
of the module that is requesting the import with its Needs header). 
Unlike regular private modules, if you import them again they aren't 
reused - you get a fresh module every time. This can be a useful 
property at times, so we kept it. We have done a great deal to make 
unnamed modules useful, and as a side effect even preferred in some 
cases.

hmm, we are preparing for the beta - finally! Carl is working on 
the Projects/Roadmap site, the list is gone and we will get new one. 
I wonder if we will be able to influence that. My bet is that we 
will kind of rush for beta, so things like tasking will be postponed 
for 3.1 :-)

My list of what needs to be fixed/done before we can consider beta, 
in CureCure tickets: #539 (likely as definitional return), #851, 
#1509, #1515, #1518, #1519, #1520, #1742, #1743, maybe #1744, #1758, 
#1759. Plus all the PROTECT bugs. There isn't a single one of those 
that isn't more important than tasking or a new codec model.

And now you can add #1760 to that list.

I'm sure that you had other objectives as well when you got involved 
in the most recent parse project 6 or 7 months after it started. 
Were you involved in the first round of parse proposals about 6 years 
ago? I remember Gabriele making a page for them after they had been 
discussed for a while, but not whether the initial discussions were 
here or on the mailing list.

Generally I remember two enhancement requests in REBOL:


- find/first - from the list of objects find first one matching the 
query

- find/deep - look-up in nested structures. Most probably blocks 
were meant, so not sure it would work for objects ...

the next time in the datatype's action list.

I hope Carl re-appears refreshed, and defines the beta-list. I wish 
for device extensions, user types,  tasking, timers, new codec system, 
network schemes :-)

Ports implicitly waited for by WAIT NONE can be seen in the wait-list:
	print mold system/ports/wait-list

13-Sep-2006 Anton Rolls

WAIT without also waiting for events:

view layout [
	button "wait 2" [
		remove find system/ports/wait-list system/view/event-port 
		
		wait 2 ; wait two seconds
		
		insert system/ports/wait-list system/view/event-port
	]
]

To begin with, I never liked faces-of or faces? proposals.
faces
 should be enough.
Plural means that it returns a serie of faces.

It may be a static list (reference) or a constructed one (function), 
I don't bother.
The context give all the hints I need.
*-of is a lame and useless convention.

Because a property or a method is always the relative "-of" something 
else .

Brian Posted a list in the R2 Releases group.


I also hope he included 2 fixes which I got Cyphre to address in 
view which crash or mock-up the quality in AGG.

If there are more properties of the immediate! values than the ones 
I listed above, as opposed to the other types, feel free to list 
them. I just gave an overview. As for documentation, that's a little 
behind. I was just going by how the person who writes this stuff 
refers to them. It's been used in some blogs, conversations, etc. 
It's a term taken from compiler construction jargon, appropriate 
since the semantics of REBOL has a lot of overlap with those of a 
compiler.

how... do you have a list of all available error ids?

Carl should get beta list out, not just choose another priority for 
next 3 months and then disappear again ...

I don't like the fact that Carl does not discuss the direction (beta 
list) with the group ....

possible? worthile?

foreach [ a b c 3 d e ] list [ ... 3 = skip 3 elements ]

Looking into porting R3 graphics to Linux has been on my "if you 
ever come across a free week" list for a while.

Pekr, ofcourse, all this can be improved but currently I have other 
things on my hi-priority list...

tell him to fix his apt sources list to use archive.debian.org urls

what are the things not compilable ? list them and then we will see 
if there are of any interrest in fact, if you want to discuss  things 
come with arguments for the discussion and not

The module model is stable for now, and has no current errors in 
the mezzanine code, though OSX has some errors in RESOLVE. When tasks 
are supported better there will need to be some minor underlying 
changes, but not many because the module system was written with 
the proposed multitasking model in mind. The module list hasn't been 
locked down from a security standpoint, though its layout was designed 
with that in mind. There are still bugs and missing features in the 
(UN)PROTECT functions that are blocking the locking down of R3, so 
don't run untrusted code yet.

Can we get a list together ?

I volunteer Andreas to draw up a list :)

A prioritized list

here's one list i once started of crashes and blockers:
1422    Rebol crashes when opening the 128th port
1799    maps broken for >2**24 entries

1806    Error after loading an extension: "REBOL System Error #1207: 
assertion failed"
1825    Crash in RESOLVE
1865    SIGSEGV when importing modules

1867    In extensions, returning with RXR_BAD_ARGS or RXR_ERROR has 
no effect

Want to publish a list somewhere?

I guess I assume Carl has a prioritized list already. :-\

We need a prioritized list of stuff that we need Carl to fix. The 
rest (mezzanine and host) we can do ourselves.

The difference between #[map! [...]] and a constructor is roughly 
the same as the difference between a constructor, and a list of arguments 
given to the constructor, when a constructor is called - it is a 
totally different thing.

Oh, there's a to do list

It makes me a little sad to realize that in order to keep a copy 
of that early alpha I have to keep it in a passworded compressed 
archive, so antimalware software doesn't delete it. I no longer recommend 
AVG because they refused to remove the false positive from their 
list (they refuse all requests from users of their free products, 
regardless of merit, so you have to buy their paid products to appeal).

Yup. The last non-public alpha of R3 was flagged as malware. To this 
day, AVG still refuses to remove the (hopefully) false positive from 
its list.

That would fail for = and all other functions that allow the any-type! 
value (for unset! and error! support), and make it difficult to understand 
the help of all op functions, which use the typespec of the first 
argument for documentation purposes. Plus, the argument list for 
the op! is taken directly from the function it is derived from - 
it can't and shouldn't be able to be specified separately.

The only trick with ternary ops or infix keywords in REBOL would 
be that any syntax error that you might want to throw if the second 
word doesn't match the list of accepted keywords, you can't trigger 
that error until after the other parameters have finished evaluating. 
It would be preferable to trigger that error ahead of time, but impossible. 
Oh well.

DO is seductive, because sometimes I want to create (easily) a "dialect 
environment" and just use DO to evaluate my dialect., safely and 
securely. 


Is there a security page in the docs (I don't see one in the R3 docs 
right now)? If not, that would be good to have. If we have a list 
of functions and operations you shouldn't use on untrusted data, 
and what the risks are, that's a good start.

No, I just didn't include them in that list. It's a special case.

but doesn't this list disapear with the new multi-level booting of 
R3?  since those words are now not sent in the user context but stay 
in their lower levels?

but its not a big deal... unset words are created just by loading 
any word in a block.  it just means, I've seen this symbol before 
and it now has its reserved number in the word list/hash table. any 
future reference will reuse the same word id (number).

block: [1 2]
index? block ; == 1
insert block 0
index? block ; == 1

list: make list! [1 2]
index? list ; == 1
insert list 0
index? list ; == 2

Yes, works with list as expected.

The above list example proves, that lists don't "know" their index, 
and have to calculate it every time, which means, that "index access" 
is slow.

John, remember our previous discussion, that indexes are not properties 
of series, but properties of series references. Therefore, it makes 
no sense to try to make a vector behave like a list, because any 
other references to the vector are unknown and thus it's impossible 
to make the behaviour for those references consistent

by the way banning me from here will just have as effect to had my 
name to the over long long list of people that don't express anything 
anymore for rebol ...

How can I get a list of all R3 words that are available directly 
after the interpreter booted as input for creating a color coding 
file.

Here is my short list (I am sure I forgot to mention a lot of things 
other people may find important)

Advantages of R3:

- new datatypes

-- map!, money!, percent!, closure!, module!, typeset!, command!, 
get-path!, 
- enhanced objects
- enhanced errors
- support for UNICODE strings
- enhanced bitsets (support for UNICODE)
- enhanced pairs
- 64-bit integers

- better conversions (to binary! and back)

- enhanced PARSE
-- new keywords added
- enhanced MOLD
-- improved MOLD/ALL
- enhanced LOAD
- some functions became natives
-- native APPEND
- more complete set of comparison functions
-- EQUIV? added
- much better RANDOM

- enhanced loops (CONTINUE)

- enhanced debugging capabilities (call stack)
- enhanced protection (PROTECT)

- improved GC

- more open (the host-kit is open source)

Disadvantages:

- missing list! (the demand for the datatype was low)

- missing hash! (for the majority of applications map! should be 
faster and more comfortable)

- no adequate substitute for the [throw] function attribute exists 
yet
- missing struct! (for substitute, see extensions)

Steeve... I guess Ladislav is looking for something like this R2 
helper script:
gbl-test: func [
    code
    /all
    /init {returns string with all global variables set to none}
    /local gbl-list words str_init
][
    words: make block! 50
    str_init: make string! 1000
    gbl-list: query/clear system/words
    do code
    if block? gbl-list: query system/words [
        foreach item gbl-list [
            if any [all value? item] [
                insert tail words to-word item
                if init [
                    insert tail str_init join to-word item ": "
                ]
            ]
        ]
    ]
    if init [
        write clipboard:// join str_init "none"
    ]
    words
]
>> gbl-test [a: 1]
== [a]
>> f: func[a][b: a + 1] gbl-test [f a: 1]
== [a b]