AltME groups: search

Don't put tasks on the list - they are due for a redesign. Otherwise, 
cool :)

We could use some practical vector! recipes in the cookbook list. 
This will give people a good idea for what they can do.

Henrik:<I can only emphasize the importance of submitting Curecode 
reports.>


If you look at some very recent bug reports (numbers 700 -- 799), 
over half of them have been resolved, often within days
    46 built and/or tested (ie fixed) 
     8 dismissed (not actual bugs)

There seems no better time to report R3 problems than now!


The rest are Reviewed, Deferred or Waiting.....So still on the action 
list.

can't. It is not on R3.0 list of features, IIRC.

To write a rebcode replacement all you need is user-defined types 
and the knowhow - it's on my todo list. However, user-defined types 
will probably need to be defined in plugins, and at the very least 
we couldn't even specify how to define them without a working plugin 
model. So it will help, indirectly :)

Yes. And a satisfaction to checking it off on the big todo list. 
;)

well, any block, list, hash but not things like objects.

The View alpha/beta list was fun :)

I mean list of variables / words defined in a function and their 
values?

I would prefer GUI version. We should also create priority list - 
what should happen after the plugins are released? Release first 
host code, examples? Then what? Move onto parse? Unicode? (still 
things like collation, sorting not supported)? GUI?

there is a list in devbase help in the wiki

I do everything and its not in the extensions list, but strangely, 
it is working, since clicking on a liquid.r3 loads it properly.


what is even stranger is that I scanned the registry and its not 
there either!

Another gotcha to look out for is that if you use the module lookup 
list, the extension automatically added to the script is .r, not 
.r3.

but there is definitely one thing that needs to be added, unless 
its just not documented.   the ability for import to RESTRICT what 
is exported by the module. 

this is the most powerfull concept in slim and I'll never want to 
live without it.  


in slim, its the module USER that has control over the module.  when 
you load the module, by default it uses the module's expose list, 
but if you supply your own, then the module doesn't expose anything 
else than what you ask of it.  


this allows me to have a clean current context, and I can prevent 
my module from cluttering the context its loaded in.  especially 
if its loaded AFTER some code has been defined, or using common global 
words.

In theory the module import list could be more complex, including 
particular imported words (the relevant function is DO-NEEDS). The 
current model is focused on being enough to keep us going with our 
modularization of the system. We intend to refine the model after 
enough real-world use has given us ideas for refinement.

I have been playing with converting some R2 scripts to R3.

And I am buiding a perhaps useful list of the things that need to 
change....eg:
      r2  allows: xor 1 2
      r3  either: 1 xor 2
              or: xor~ 1 2
Where would be a good place to start a list like that?

Max: I am especially curious, if you are able to add a point to the 
"Needs list"

and only those from the available export list can be chosen...  so 
you have a double restriction.

what can be exported AND what you need imported.

I have not thought it through that much, other than figuring there 
would have to be a way to shorten that code to one step. I have compiled 
a list of neutral values for all types, that are capable of producing 
neutral values. Some can't, and I wonder what the response to NEUTRAL? 
would be there.

I think pretty soon. That got delayed because Ladislav and meijeru 
started being really thorough about reporting inconsistencies in 
the core semantics of the language, so we started working on resolving 
those in case any changes affect the rest of the system. For instance, 
the equality change includes changing the equality actions to natives, 
which changes the action list - that might affect plugins.

For instance, there isn't anything in the HTTP or URL standards that 
say that the path is necessarily a hierarchy, though the (poor) cookie 
standards definitely imply it. Ignoring the cookie standards, you 
could easily look at it as a tag list. However, you would need to 
be writing the server app to do so, since the server is what decides 
what the path means.

Does anybody know the reason that money! is not included in the list 
of immediate datatypes for plug-ins?

Does anybody know the reason that money! is not included in the list 
of immediate datatypes for plug-ins?
 - money! is not 64-bit datatype

As for the JIT, I could write the compiler in REBOL and generate 
the intermediate code of the JIT, then pass that intermediate code 
to the JIT with a command. The JIT would then generate a function, 
add it to its list, and return the list index as an integer. That 
integer can be  used to create a new command!, which RX_Call can 
dispatch to the internal JITed function.

When investigating the creation of a MAP function in REBOL 2, I found 
that sending functions with refinement to map required some extra 
work (the need for a DO). The rules about get-words as arguments 
has changed in REBOL 3. Maybe I should talk to Carl about it, but 
I could discuss it with you guys first to not disturb Carl too much. 
First a REBOL 2 version of MAP, that can't cope with refinements:


>> map: func [:f l /local r] [r: clear [] foreach i l [append r f 
i] r]
>> map sine [0 30 90]
== [0.0 0.5 1.0]


f is the function, l the list and r the result. i is an item in the 
list. The critical part is

append r f i


The function f is evaluated taking the argument i. Easy to read and 
understand. But it can't cope with refinements, which are seen as 
the path! datatype. Example:

>> map sine/radians reduce [0 pi / 6 pi / 2]
== [sine radians sine radians sine radians]


This can be fixed by putting a DO before f. Now it works both with 
and without refinements:


>> map: func [:f l /local r] [r: clear [] foreach i l [append r do 
f i] r]
>> map sine [0 30 90]
== [0.0 0.5 1.0]
>> map sine/radians reduce [0 pi / 6 pi / 2]
== [0.0 0.5 1.0]

In REBOL 3, the function is not evaluated:


>> map: func [:f l /local r] [r: clear [] foreach i l [append r f 
i] r]
>> map sine [0 30 90]
== [sine sine sine]

Including DO just makes it worse:


>> map: func [:f l /local r] [r: clear [] foreach i l [append r do 
f i] r]
>> map sine [0 30 90]
== [make native! [[
        "Returns the trigonometric sine."
        value [number!] "In degrees by default"
        /radians "Value is specified in radians"
    ]] make native! [[
        "Returns the trigonometric sine."
        value [number!] "In degrees by default"
        /radians "Value is specified in radians"
    ]] make native! [[
        "Returns the trigonometric sine."
        value [number!] "In degrees by default"
        /radians "Value is specified in radians"
    ]]]

To make map behave correctly, I have to do something like:


>> map: func [:f l /local r] [r: clear [] foreach i l [append r do 
reduce [f i]] r]
>> map sine [0 30 90]
== [0.0 0.5 1.0]
>> map sine/radians reduce [0 pi / 6 pi / 2]
== [0.0 0.5 1.0]

Is this ok and accepted behaviour? Will it break many scripts?
(Sorry for the long post, but I wanted to be precise.)

Only C for now - not C++. Some tweaks to the header will help with 
that. It's on my list to test with TCC :)

>> ? in
USAGE:
        IN object word
        Returns the word or block in the object's context.
ARGUMENTS:
        object (any-object! block!)
        word (any-word! block! paren!) 


IN allow a list of objects OR a list of words as parameters but not 
together.

IN context [a: b: 1] [a b] == OK
IN reduce [context [a: 1] context [b: 2]] 'a == OK


But the more powerfull behaviour, to be hable to bind a block with 
a list of objects is forbidden.


IN reduce [context [a: 1] context [b: 2]] [a b] == ** Script error: 
invalid argument: [a b]

Why ????

look at detailed beta plan - it is just list of things to do. It 
seems Carl is not sure about adding sound device (for the beta)

the list is sometimes strange - why 'replace has high priority, but 
other imo more important stuff has medium or low?

But - according to the list, it is hopefully being adressed too ...

yes, I had ... and? :-) Carl reserved 5 days for that. I am for implementation 
of all stuff from  the list. If you count the time needed, it is 
not more that 1-2 months to beta. After 3 years 1 or 2 months is 
OK with me ...

I more care about the completness level, hence I am a bit surprised 
that e.g. CGI mode is not on the list and networking protocols are 
low priority. As for those, maybe Carl plans that community should 
do it. But as for CGI - why are not CGI related mezzanines in R3?

see the system/catalog/codecs for a list of loaded codecs

 - hmm, docs need an update. Dunno why the section was moved to system/codecs 
 ... will ask on R3 chat ...

If a new version of REBOL is very different from what we know as 
REBOL today, then it might be ok with a name-change. If it's just 
a new version in a line of versions of REBOL coming from Carl, then 
I think, it would be more confusing to rename it. And what's the 
point of a rename? The name is not the reason, the language is not 
more widespread.

List of 	programming languages:
http://en.wikipedia.org/wiki/List_of_programming_languages

R3 Chat, type "n" for new messages, and "lm" to list the messages. 
It is generally enough to be able to participate. For reply, just 
type the msg number you want to reply to, and type "p" to post to 
the thread, or "r" to reply to such a message ...

you don't understand... I know that.  when the discussions is spread 
between 10 groups. its VERY tedious to read more than very few messages.


jumping around, hoping you don't miss posts, then listing again... 
over and over.   it would be nice if we could simply skim over the 
list of new posts in order of time.


then if we jump to a post we don't get the context, we just list 
that group... its easier this way.  but going to next mesage would 
still bring us to the "newer" message, not the next message in that 
group.


I'm not saying the current method isn't usefull, I'm just saying 
that another method would make it easier not to miss out on new posts, 
especially when there is a sudden flurry of posts all around the 
place.

Hmm, so good proposals are down the list ... e.g. of (I would call 
it any-of), do, reverse. Brian - what you think we get for the parse 
update for 3.0? Carl mentioned, that some proposals would require 
some big changes to underlying parse function. I was surprised,e 
.g. 'of being one of them ....

DO is down the list because it's scary. The number of people who 
could use it without code injection security problems is small.

It seems insert (and maybe even change, remove) are already implemented 
for parse? At list this is how I read between the lines of Carl's 
blog reply in Either related blog ...

multiple to/thru  are near the top of the list... and Carl recognises 
their use... and probably they where the first requests, ever for 
parse.

Back in 2000 I was one of those gurus on the mailing list, and my 
argument with Gabriele was the initial documentation for R2's context 
model and behavior. I was glad when Ladislav later fleshed out that 
discovery with more detail in his Bindology papers.

I remember Carl used to be on the mailing list ...

I remember I used to be on the mailing list. Haven't been for many 
years now.

We need a way to make the "todo list" accessible and we need users 
to help us maintain it.

Pekr, for some things, I need more of a todo list rather than message 
thread.

Speaking of which, add finishing the PROTECT changes to the list. 
All details in CureCode.

Ok, must go. Will get that project list on the Docs wiki today.  
Let's get it filled in, but also think about how to get more community 
involvement in R3 as it moves forward rapidly now, but must still 
accelerate to reach the release timeline ("Autumn 2009").

about chat ... i always said it was hard to have a precise location 
of interresting exchanges ... but that's the same in altme...  in 
fact any discussion here or in chat when it pops out interresting 
ideas should then be resume into a temporary task list  but ... that's 
normal most of the time discussion here are mixed we don't only propose 
enhancements we try to figure out how things works then  we try to 
give how things could or should be working in order to make our lifes 
easier... It's a difficult task to keep tracks on every good idea 
passed throught altme or Chat  system...

precisely what ?
you can't establish a list of all the bad coding practices

Carl even agreed to adapt list, to make it wikified, so that we could 
update it for the final beta list ...

is the project list on any wiki page at this point?

Current project plan is here: http://www.rebol.com/r3/project-plans.html


Carl expressed his will to adapt the list and its priorities upon 
the needs of community ... I will ask him to wikify it, so that we 
might edit it ...

I am not sure everything on the list can make it into beta in reasonable 
timeframe ....

Hehe, what is this? I did not know such func exists :-) I just realised 
it as Carl adressed the stack size:

evoke: make native! [[
    "Special guru meditations. (Not for beginners.)"

    chant [word! block! integer!] "Single or block of words ('? to list)"
]]

example:

secure none
evoke [stack-size 1000000]

Carl wikified the project plan - http://rebol.com/r3/docs/project.html


I am now suggesting the following aproach - to create October plan, 
describing R3 beta release. My proposal is to discuss particular 
items here and on chat, but the main channel should be blog. There 
we can post our priority lists. Once agreed, we edit the doc.


So hopefully soon enough, we open the discussion. We might already 
start, but save your comments for the blog. This group is moving 
fast with discussions, maybe we could set-up (temporarily?) an R3 
priorities group, and each of us could post his numberred/bulleted 
list of requested features? It would be then easier for Carl to look, 
or for us to gather ideas and repost them to blog, etc.

What do you think?

priorities are a matrix... everyone does the error of viewing them 
as a list.

I have a few security concerns that haven't made the list yet - mostly 
requiring the rest of the PROTECT tickets to be done.

I think, that naturally, such document should be part of CureCode. 
But that is for the future. Simply put - in cure-code, you post a 
wishes too. Those might be dismissed, or accepted. There should also 
be a table called releases, where admin could add version numbers. 
Then fixed-in could use shortcuts as fixed-in 'next release, and 
the correct version would be filled-in, etc. From there, such pririty 
list and milestone releases description could be automated. But - 
we don't need it now ...

Add these to the list:
- (UN)PROTECT /lock
- Protecting loaded module headers

Max - OK. Just remember, that Carl wants to get it quick, or so is 
my feeling. So you should better finish it ASAP, as once Parse is 
done, he might be back to revisit the list, and reorder priorities. 
Hopefully I think that Extensions will remain high priority, as it 
seems they will be used even for Host to Core isolation ...

There are references to a FIND-MODULE function in the function list, 
but it doesn't exist in R3?

there are a few of those on the list of function pages to remove

but, I'm about 40% through the list, and I'll compile a list of changes 
and things that need to be looked at.

Yes, although I don't know much. You can find it in Carl's own priority 
list - http://rebol.com/r3/docs/project.html, described as - "FIND 
/first with list of targets", priority high. I do remember Carl planned 
to add it because of GUI? You simply want to check on multiple targets, 
and it returns first match ...

maxim too many groups here i'm dizzy just looking at the list ...

part of SCREAM's mission is to allow compilation targets for all 
of its tools.  this won't happen soon, but its one of the reasons 
for its existence in the first place.


Oldes' Flash dialect is very high on my list of Scream subprojects.

The type test in the argument list might be taking a little time. 
Try John's with the type spec. I'm curious to see what the difference 
is.

1. TCP question: where to get complete list of event types? lookup, 
connect , wrote, read, close .... what else, does exists the complete 
list? 
2. Is it possible to get other devices event types
3. is it possible to define "own" events?

I think I'd look for at least the following behaviour:

	>> url::%23#
	== url::%23#
	>> join url:: "%23#"
	== url::%23#

 >> join url:: " " ; space is not in the uri spec, so could arguably 
 be converted
	== url:: 
	>> read url::%23# ; dependent on the scheme, I guess
	== "GET %23"


The problem with magic percent encoding is with the special characters. 
 As it is now, it is impossible (so far as I can ascertain) to build 
an http url that encodes special characters eg "#=&%" - Twitter being 
a great case where an encoded # is integral to the service.  Given 
though that the list of special characters is short and well defined, 
perhaps they could be the exception to a magic encoding rule.

I agree with Henrik, both on not changing it and on the problem list. 
 I've gotten past all that at work though, the development group 
knows what REBOL is and can talk about it in conversation just like 
they do Ruby (they are Java based primarily).  One thing I do find 
that seems to give some relief on the name issue is just to call 
it R3.

All module export in R3 is what you call exposing in slim. Importing 
is a separate issue, and you can choose what to import. The export 
list is just that: a block of unbound words that are used as a guideline 
about what to import - all module context words are actually visible, 
unless they are hidden using the standard hiding facilities. You 
can choose to import just that list, or none, or go by a module reference, 
or import whatever visible words you want. What importing means depends 
on what kind of module or script you are calling from, or for that 
matter whatever you want it to mean.


You need to remember the model if you are doing selective import 
though. You aren't just importing to the current context if you are 
importing named modules. If you come up with a good model for selective 
import, be sure to tell me. I think that I'm one of only a few people 
who really understands the whole model (must write more docs).

If you have a Needs header (pardon the anthropomorphism), named modules 
in it are put in the module cache and the words in their exports 
list are resolved to the user context (resolve means copying the 
values to corresponding words in the target context, but not overriding 
existing words). Then the words from the system and user contexts 
are imported to yours, with "import" meaning one of three things 
depending on whether you are a script or a regular or isolated module. 
Then any unnamed modules in the list are imported into your context, 
also in one of three ways. The modules in the list are loaded in 
the order specified (transitively). No explicit IMPORT function call 
needed.

Selective imports can include words that the module hasn't put in 
its export list at all - anything that isn't hidden.

You can choose to import just that list, or none, or go by a module 
reference, or import whatever visible words you want

 - eh, really? I thought that one of the ideas of the module is to 
 prevent user to mess with things. There are two point of views:


1) you debug some code, and your imported module function does some 
weird thing, so you want to debug foreign module. You can export 
some intermediate values from module (well, I am not sure it is best 
debugging method, but it is nice that such possibility is here


2) OTOH - you are a module author. Let's say you have some reason 
to protect your code/knowledge. So what you want is - compressed 
and scrambled source, checksum of code section into header field, 
and precisely defined Exports block of exported stuff = API to your 
module. And please don't push me to use Extensions in such a case. 
I am wondering, if security framework can be expanded, so that you 
can protect module/object, so that its words are not visible or gettable 
in any other reflective way :-)


I of course encourage to use open-sourced modules, but sometimes 
hidding the source and having only API exposed might mean a simplicity 
(user does not always need to look into internal, having headaches 
from thousands of line of code)

Previously, I also haven't been able to separate "launched" versions 
of Rebol from the same terminal session. However, after a bit of 
googling I've worked out a way that seems to work using Ruby:
 
Macintosh:Rebol3 peter$ irb

>> require 'pty'

=> true

>> PTY.spawn("./rebol -q pong-server.r"
)
=> [#<File:/dev/ttys005>, #<File:/dev/ttys005>, 1437]
>>


Process 1437 was running in the list of processes and control was 
returned to the console session.

my company has a protocol, the admin just follow the protocol and 
leave the serious issue to me. they said "REBOL is not in the list 
that they should maintain"

We might not need to coerce to decimal. The first decimal in the 
list will make that coersion for us. And we don't want decimal results 
for a list of integers - it's a loss of precision. I suspect that 
initializing result with the integer 0 will be sufficient.

Then any decimal or money in the list will promote.

Once we understand the exports, we can then formally define the module, 
title, export list, etc.

How do you access the arguments when passed in a command line?

r3apha myscript.r argument-list ?

I've noted in my todo list to extend the RSP API to be able to add/delete 
jobs (for now, the list is static, loaded from config file and cannot 
be accessed from RSP).

Anyone got a list of 1,000,000 valid email addresses for sale??

win-get-dns: has [base local-ip out v][
		local-ip: mold read join dns:// read dns://
		
		either value? 'get-reg [

   base: "System\CurrentControlSet\Services\Tcpip\Parameters\Interfaces"
			foreach adapter list-reg/hklm base [

    if local-ip = get-reg/hklm rejoin [base #"\" adapter] "IPAddress" 
    [
					v: get-reg/hklm rejoin [base #"\" adapter] "NameServer"
					v: parse v ","
					forall v [change v attempt [to-tuple trim v/1]]
					return head v
				]
			]
		][
			; just use opendns
			208.67.222.222
		]
	]

There's no REBOL in the drop down list of programming languages :(

But it seems that you're not using webapps, just plain RSP and manual 
session handling. You should know that invoking session/start container 
will create a new session context but you won't get a new ID at once 
(session/id will be set to none until the RSP page ends). We already 
discussed this point previously and I have an entry in my todo list 
to improve that. (it requires a change in the session ID creation 
process)

Pekr: that's in my todo list, I just need to find some free time 
to think more deeply about how to support such feature efficiently.


Btw, I have built a XMLC (XML Compiler) engine inspired by enhydra 
(http://www.enhydra.org/tech/xmlc/index.html) which should fit perfectly 
your needs. It's a working prototype but need some significant work 
to be integrated within Cheyenne, so it's low priority for now.

Set-cookie is on the todo list but hasn't been implemented yet. So, 
for now, you have to set http header manually.

improved debugging : on my todo list. I might try to emit the debug 
info to a JS console like Firebug's one or a custom one.

The list for 3.0 is not final. What I don't like even more is kind 
of lack of leadership. I described it in my marketing related docs. 
There is some kind of imo wrong attitude towards finishing beta - 
some things were moved into "it might be delivered by community" 
category, and it as well might mean - never delivered ...

yes, so hopefully you can now understand, why I objected to your 
(taken from Project plan) words: "Also, this list is only for R3 
core operation and does not include community-based projects such 
as graphics, GUI, protocols, documentation, and other features that 
can be developed externally, depending on the needs of the community."

what is missing in R3 to have Cheyenne working on it? we should make 
sure Carl doesn't forget any feature needed, I sure wouldn't like 
being stuck with R2 because Cheyenne wont run on R3, do you have 
a list that we should relay to BrianH who will relay it to Carl ? 
I know it's still early, but having a plan should help

Did looked close enough yet to have an exhaustive list, but probably 
/Library would miss the most.

When R3 features list will stabilize (beta stage), I'll make a more 
complete evaluation of the time required to port Cheyenne (lack of 
/Library can be workaround but will cost a significant amount of 
time).

If you want to fix it in 0.9.19, here's the patch :

RSP.r => decode-multipart function => line: insert tail list name
should be : insert tail list to word! name

Yup, I agree, at least the parts that need the web to do (which isn't 
much on that list).

It's funny, Terry, but I keep agreeing with your sarcastic list once 
I filter out the stuff that I can do easier without a web browser, 
or that aren't necessary at all when you aren't using one.

I like some of the stuff on that list, but I like doing it better 
without HTML/JS/CSS.

Need to fix the 'signout' updates to other ports.. it's not sending 
the "bob leaves" message, and it's not updating the user list <div>

Janko: I have in my todo list a full virtual system to add to Cheyenne 
allowing embedding webapps in a encapped Cheyenne. It can be done 
by replacing every filesystem accessing functions (DO, LOAD, READ, 
WRITE,...) by custom ones getting files from memory. The hard part 
is to integrate such approach within Cheyenne preserving perfomances 
for normal filesystem accesses while avoiding redundant code, this 
needs time for designing and prototyping.


I can't see an easy way to protect you webapps right now, but maybe 
other might have found a way to do that?

who's interested to do real apps in Flash?
 http://www.adobe.com/products/flex/buzz/customers/list.html