AltME groups: search

Ladislav, I'd like to make your article on Identity into a cookbook 
recipe, so it gets an official listing in the cookbooks list, so 
people can find it. Where do you think it would fit on this page:

http://www.rebol.net/cookbooks/

Remember what puppies can be trained to do :(

I've suffered of trying to get rebol INTO companies and it never 
works.  there is too much ground work to do, it costs a lot of money.

yes we can :P YES WE CAN :P and i'm sure all of them will really 
like to do it ;P

Ever tried to use rebol in a company that has only .net, python, 
or java code?  good luck.  it takes weeks before you can use most 
of the DB stuff they have built up, because there are sooo many modules 
out there, and they have huge frameworks, which actually DO more 
stuff than rebol .  rebuilding those libs is not even always possible....

maybe, as a helper for explicit flat record handling we could add 
a really simple func which returns true/false for complete records. 
 its not that its hard to write, just that its cleaner if we all 
use the same func for it.  what do you think?

If someone needs partial record detection, they can do it ahead of 
time. We're trying to make REBOL only generate errors when it's useful 
to do so. It was not deemed useful in this case.

Not the same thing. If you have skip > length of the series, it will 
only do one iteration and your access to the results off the end 
will usally be none, unless you constrain it yourself. The question 
is whether negative skip should be silently constrained or generate 
an error, as a general rule.

but functions like insert are a bit simpler to use with 0 based, 
since a length is used as the value past an item in a series not 
the last character in it.


they both have advantages.   but trying to explain to someone that 
an index of 0 moves backwards isn't very obvious to promote as a 
feature ;-)


I'd have trouble justifying this to my kid which is learning to do 
math  :-D

I have difficulcy to get Chat files. I do nf, to list new files, 
then I submit get * but nothing is synced. I try other aproach, going 
to e.g. R3 mezzanines section, and doing get * does either report, 
that there was no change to files, or that my local copy is changed, 
and hence it can't be synced. I am sure I did not do any local changes 
here ... So - how do you usually work with Chat file facility?

If I want to keep local versions to compare to I keep them in another 
directory, then compare to the changes made by others. I only need 
to do this when I am working on the same file that others are working 
on, usually a sign that there is too much in the file (it needs to 
be broken up), or that I need to do a better job of talking to the 
other person.

OK, Maxim, the MOVE/skip example you specify is not an error in MOVE, 
it is an error in the code calling MOVE in that example. MOVE was 
specifically designed to do something useful in that case, rather 
than generate an error.


The whole reason that MOVE takes one position and one offset is because 
that limit gets rid of a host of potential aliasing errors. MOVE 
is designed to be the most efficient and safe solution to the problem 
of moving stuff, and it should *never fail* unless the series is 
protected from changes. MOVE is a DWIM function: Do What I Mean. 
This goes for treating negative /skip lengths as an error too - having 
it magically constrain the /skip length to 1 or greater was a deliberate 
design choice, the result of a lot of discussion.


So the question is whether the error of having /skip lengths being 
less than 1 is worth worrying about, worth the overhead of generating 
an error and checking for that error every time you use the function. 
Don't be fooled, that overhead is really significant.


We've already changed other functions so they don't generate errors 
anymore, and just DWIM, like FIRST not complaining about bounds and 
acting like PICK 1 now. These changes have made these functions faster, 
and better to use. Generating an error is considered something to 
do when it is really important, as it sometimes is. How important 
is the /skip < 1 error?

In general, it is a much better idea to do marketing on ReBrowse. 
People will understand what it is. The right people will want to 
learn how it's built.

So far, R3 tasks don't work properly and should be considered a placeholder. 
We can't do a proper task model until there are changes to the basic 
semantics of REBOL. Fortunately most of those changes were done in 
the last month.

maybe, but STL already allows us to do 3d object things like inverse 
IK for games or 3D modeling applications ... that is what one of 
the engineers was using to build plugins for Maya.

The following session shows that launch does not effectively run 
a script as a separate process and return immediately.

>> ans: "yes"      

== "yes"

 >> do [ while [ans <> "no"] [ans: ask "(l)aunch, yes or no ?" if 
 ans = "l" [launch %launched.r]]]
(l)aunch, yes or no ?l
Checking for rebol.r file in /Users/peter/Desktop/Rebol3/
Checking for user.r file in /Users/peter/Desktop/Rebol3/


Evaluating: /Users/peter/Desktop/Rebol3/launched.r

launched script
Do you want to continue running the launched script?yes

yes

Do you want to continue running the launched script?yes
yes
Do you want to continue running the launched script?yes
yes
Do you want to continue running the launched script?no
no
(l)aunch, yes or no ?y
(l)aunch, yes or no ?y
(l)aunch, yes or no ?no
== none

The source of %launched.r is:

REBOL []

print "launched script"

ans: ""
while [ans <> "no"] [

   print ans: ask "Do you want to continue running the launched script?"
]

Similar to R2, though the errors start disarmed and need to be armed 
with DO. CAUSE-ERROR wraps this.

You'll have to wait for multiple-dimension vectors before we do matrix 
operations :)

so i keep the tuples to do vector operations.
1.2.3 * 5  = 5.10.15
but it's quite limited

Steeve, the basic math operations generate new values, they don't 
modify in place. This cold cause a lot of memory overhead. Modifying 
operations might be better to do as functions, perhaps even native 
functions loaded in plugins.

It's not exactly true that they didn't worked at all. I was able 
to do drum and subtractive synthesis plus AIFF/WAV loader/saver with 
vectors. It was just NOT easy :)

Brian --- R3-alpha is archived on REBOL.org, for world-members only 
(ie the same read rules as the AltME version itself).

So good news -- we have a persisent archive of that world: no need 
for Rebolek to rush

But bad news -- not many people can see it -- so any gems do need 
to be ported to more visible locations.

How do I fix this:

Couldnt get a file discriptor referring to the console.

bah... to be honest, i can do the job using another tricks, it will 
be less elegant...

continuing discussion in I'm new group...


brian: no R3 chat account yet... its basically that I'm keeping my 
energy.  I really would love to participate more in R3 but since 
most of what I do is commercial (REBOL), time invested in R3 is severely 
lost in the short to medium term.


but I think its now progressed enough that I really should participate 
more.  


I think I have a lot of insight to bring to the table since I'm one 
of those few developpers who has been using REBOL commercially for 
just about ever, I've been using a module clone for the last 7-8 
years,  built 4 complete view engines (even ported glayout to python 
;-),  implemented some of the largest apps (code wise), and have 
several dozen REBOL APIs under my belt.

this can be a big discussion... want to do so privately?

The "new evaluation model" of the command! type is what I find most 
interesting. That would be the only way to do other forms, but there 
isn't enough info out there to know whether it does.

Wait a minute - Carl's method is simple things should be simple to 
do (STSBSTD).  A longer acronym.

i think i will do that anyway since it's so usual way to handle chatting

Actually, the first optimization i do in my scripts which need speed 
and low memory usage, is to remove all the reduce and compose usage.
It's always the first thing i do

See this line of code i do to rebuild a draw block in area-tc (it's 
called thousand times when the style is scrolled)


    out-style: insert insert insert insert insert insert insert insert 
    out-style
					'pen color/2 'fill-pen color/2 'box

     as-pair abs-x 7 as-pair (f/x * length? str) + abs-x 7 + f/y 3

Insane ;-)

Brian - what needs to be implemented for utypes? Do you think we 
will get them for 3.0?

As for 4) - I know you guys find them important (utypes). But what 
will we gain having the ability to do our own datatypes? btw - having 
own datatype will have to fulfill some needs, as for e.g. utype will 
have to be able to react to some functions?

I'm not saying that unset! values in an ANY or ALL is one of those 
cases where there would be benefits, just that it might be. Benefits 
like being able to use functions like PRINT in ANY or ALL without 
having to do tricks like (print 'hello true). If errors would be 
more common than beneficial code, then generate errors.

It's hard to say in advance if it will do more harm than good. Unset! 
values can be generated from various semantic rules, I think it's 
 quite touchy to consider that all these cases are equivalent without 
exhaustively listing all ways to get unset! values and see one by 
one if the proposed change would impact it in a positive or negative 
way.

Bug #564 and option 2 were the result of the last time (January) 
we decided on a consistent treatment of unset! values:

- As an error in value contexts, like assignment, function parameters 
that don't explicitly support it.

- As a noop in control contexts, where the value would normally be 
thrown away, like DO blocks. ANY and ALL were added to this group.

i don't see your point, if i want a binary serie of the internal 
data of a vector, it's to do all sort of operations we can do on 
binaries

No, I want to protect the vector from *bad* modifications. That's 
easy to do, as long as you *don't* do type aliasing.

Quick discussion needed, and here because more people need to chime 
in:


There is a proposal to change the name of the MAP function to MAP-EACH. 
Here's why:

- There's a map! type, and this function is unrelated - except in 
CS theoretical terms, which is why we suggest the name MAP-EACH.

- The other functions that have the name of a type without the ! 
are constructors for that type. The map! type could use one.
- This function is behaviorily one of the *EACH family already.

- This is *not* the functional language map function, and it might 
be good to emphasize that...


In functional languages, functions like map take functions as parameters. 
However, such languages tend to be compiled and the function values 
they take are constructed ahead of time. Since REBOL is interpreted 
and functions are created at runtime, that kind of code pattern tends 
to be inefficient. That is why REBOL control and loop functions tend 
to take blocks instead, and have any argument words to those blocks 
as a separate parameter: It's much more efficient that way.


There is precedent: The REBOL function that corresponds to the functional-langage 
filter function is REMOVE-EACH.


We ask this question now because now is the time to make the change, 
if ever. Not many functions in R3 use MAP yet (the only one I can 
think of off the top of my head is LOAD). This will change when we 
do a hand-optimization pass of the mezzanines, and it will definitely 
be too late once we hit beta.


What do you all think? Please chime in in the next couple days if 
you can (and have an opinion).

My vote: I don't want it to be called MAP because of reasons you 
named.. anything reasonable else is ok... 


I can't decide if I like map-each remove-each *-each ... naming convention... 
 

just thinking outloud..

1) you named fold/reduce accumulate ... if you name map/filter in 
similar vein they could be something like  map -> transform  translate 
  alter   apply ?     remove-each -> filter  purge ...


2) common to these functions is that they take a block of code (and 
a series) ... each hints about the serries but maybe more specific 
about them is first part - block of code (function in classic functional).... 
one idea for the common word that hints about  do something with 
block of code as a rule IMHO is with


map -> map-with , transform-with , ... ; remove-with  filter-with 
purge-with ;  fold-with ??

The only reason the *EACH makes sense is the word parameter that 
comes first:
    foreach x data [code]  ->  For each x in data do code
    remove-each x data [code]  ->  Remove each x in data if code
    map-each x data [code]  >  Map each x in data to code

Steeve, other languages that use the * convention use it differently 
from each other. C-like languages use it for pointers. REBOL uses 
it for keeping the original definition of redefined words, like COPY* 
(not for pointers or references, Maxim, because those are implicit). 
The only language in major use that uses * to mean do-many-or-all 
is Regular Expressions.

Steeve .. do you say this to me because of find-each :) .. I mean 
a fing that uses block of code to determine what to find .. like: 
find-each x numbers [ x > 3 ]    ... in same manner as map/fold/filter 
work

I use map reduce and seek  at jsgoo and I can do a lot of stuff with 
those (an appy inject for dictionaries) .. let's say you want to 
check if users with username and password exists in a block of users:

find-each U users [ all [ equal? U/user user equal? U/pwd pwd ] ] 
... much cleaner and more error prone than with foreach IMHO ( and 
these functions show intent of why you are looping through block 
of users )

if I would care only for efficient I wouldn't be using compiled languages 
anyway .. sometimes it doesn't matter that much .. I like map/fold 
because they cleanly express what you want to do , you don't have 
to setup and update temp variables and they are expressions ( they 
return result)

Above reminds me - does our parse enhancement proposal contain request 
to continuous (streamed) parsing? I can imagine parse being fast 
enough to have REBOL level codecs. But surely I don't want to read/part 
manually, nor do I want to read 1GB of video into RAM, just to find 
out, what the codec is :-)

Pekr, the reason for R3/Plus is so we don't have to say no to people's 
requests for new functions, but don't want to bloat REBOL. With modules 
we don't have to make everything monolithic anymore. We have a new 
situation with R3.

The main advantages to having functions built into REBOL:
- REBOL itself can use them.
- You can count on them being there.

- They will be tested and reworked by the best of the community (the 
REBOL optimizer).

The main disadvantages to building functions into REBOL:

- Increases overhead, both in startup time and memory overhead. Compare 
R2 /Base to /Core to see what I mean.
- Predefines more words.

- These might not do what you want, so you'll end up redefining them 
anyways.


Building a community is a balancing act. Once we started taking requests 
for new features to make REBOL better, the floodgates opened. Even 
after filtering out the impossible or otherwise bad ideas, there 
was a lot of good stuff in there. But we don't want to bloat REBOL 
into Perl.


Fortunately, we had added modules to R3 to help organize the code 
and deal with the last two disadvantages to building in functions. 
And we have DevBase to accept community contributions. These are 
all the infrastructure we needed to create a standard library, tentatively 
called R3/Plus.


So now we don't have to worry about accepting requests for new features, 
because we know how ruthless we are going to be about our mezzanine 
cuts. If REBOL itself uses the function, it either stays as a mezzanine, 
or in some cases goes native. If the value of the function for users 
is high, the overhead is low, and there is consensus, it may get 
to stay too. Otherwise they become library functions. FUNCTOR wasn't 
the first cut, and it won't be the last.


Keep in mind that with plugins, library functions can be native too. 
And the REBOL optimizer still applies. And with modules you can declare 
your dependencies. There's very little downside to having R3/Plus.

Ah. What will be the model to "simulate" R2 DLL capabilities? Ladislav 
suggested bunch of enhancements. Should we do R2 DLL kind of interface 
as one of plugins?

Doc and I decided that the "block" severity would refer to bugs that 
are stopping development, or the fixing of other bugs. There is only 
one bug with that severity now: DO/next. The system/user/home replacement 
is almost there too.

Maybe we need DO string! to error out with a message: "old fashioned 
char-based coding is not allowed."

We discussed adding one, but everyone wanted the function to do something 
different. No consensus.

What types do you want to flatten? Just blocks, or other block types?

Yeah, it's a good candidate for /Plus. The problem is that whenever 
the need occurs, what it needs to do is slightly different. Flexible 
semantics like that lead to a slow function - which is a bad thing 
for a mezzanine or library func.

That is so true: "everyone wanted the function to do something [a 
little] different".


So, the question always becomes: what is the most common pattern, 
and how common is it really?  Difficult to know, especially when 
you start thinking about adding reduce or compose into it.

R3 Chat #4395:
  

Re #1890: Question on DO/next: currently, it returns a block as a 
result. That means it must allocate a new block each time. An alternative 
would be to provide a variable name as an argument, and it would 
not need to allocate a new block each time.

   result: do/next block1 'block2

It would also be possible to:

   result: do/next block 'block

Something to think about.

It would matter to me. If DO/next were more efficient, I would not 
consider use of it to be a sign of a bad function :)

When I saw that number coming up, I had to do something appropriate 
there :)

See R3 Chat #4403 regarding how to get new R3 to test DO/next.

its an object within an object, so I am thinking it has something 
to do with binding.

'do/next - I use it in a function as a subverted version of 'case. 
 Perhaps if that's a bad function, there is an alternate way to implement 
it?

next ask is do you think  somthing like colaborative "at the same 
time" could be possible to do with R3  for example hum lets be crazy 
in futur viva-rebol IDE offers a way to make several ppl working 
on the same project at the same time use the viva-rebol IDE and sharing 
in real time information

Might be easier to do with parens instead of do/next, but the case-like 
construct is more readable...

IIRC there was a blog what to do with money! datatype, and if the 
datatype should be more "complex". That is still not resolved.

In school, units were always encased in [], such as 5 [m / s]. I 
think it's possible to do something similar in REBOL.

BrianH: but I somehow have to distinguish usertype from e.g. decimal? 
So how do I do it? And how does REBOL's interpreter know it is mytype? 
How do I match it in parser for e.g.? Any example?

BTW, what do you think about the END! datatype? is there really a 
reason, why it has to be "exposed"?

I do know one use for the END! datatype, but am not sure, it should 
be "exposed" this way, taking into account, that it is an "implementation 
detail" in fact. The same applies to handle! and frame! or e.g. the 
symbol! datatype n earlier interpreter versions.

do/next matters to me, but, I don't count for language features (Carl 
put me in the 0.1% basket ;-)


What I would like is a "break out"of a block much like throw, that 
allows me to re-enter even in nested blocks.

I think a closure over the evaluation with an "into" would do it. 
It is easy to see parse with into do this.

Brian,  parse uses tables (at least last time I checked on compiler 
construction ;-) so it shoud be a easy to do.


If I have at/deep or so, I can creat a new head and build a stack 
of traversed parse rules. Actually that would represent the table. 
Which means I could do this today. And I can wite at/deep by using 
some recursion.

Thanks!

BrianH: I won't be able to make an example (and maybe it's not possible 
now) .. but I was asking because of this maybe stupid idea for "poor 
mans continuations" 


that are built on top of language as a lib (because of rebol powerfull 
treatng of itself): 


- you have a function >>myfunc: func [ a /local b ] [ b: 5  return-cont 
 a + b ] <<
- at runtime when function is called you reach return-cont which:

  - you collect all it's local words and their values into a block 
  (with stack/args etc)  for example [ a 1 b 5  ]

  - you also get current position of a running block (already seems 
  to be possible with stack/block + next )  [ a + b ]

  - you generate a function at runtime that has >>does [a: 1 b: 5 a 
  + b ]<<
  - you return taht function as a normal return value.
this means that this would be possible:
>> cont: myfunc 5
... do some stuff
>> cont 
== 6

any thoughts :) ?

do you need continuations to have coroutines?

do you need continuations to have coroutines?

 It depends on the system - in some cases it is the other way around.

Janko, you can have cooperative scheduling of real threads - all 
they have to do is cooperate, as long as a thread can pause.

it has nothing to do with the lexical analyser, we just need a new 
data type, to construct computed variables

but I would like a way to get invalid tokens loaded as invalid values... 
that way I'd use block parsing .  so far, I've been using string 
parsing about 90% of the time.  its a shame, since I'm loading stuff 
much more slowly than rebol could let me do it using its native loading.

yes i can do it with OOP, but i don't want to have to code stupid 
things like my-var/set, my-var/get

the accessors are just events... you have to know WHEN and WHAT to 
do with a variable...   It would be fun if generic objects allowed 
us to set accessors per instance, just like python allows it, but 
alas, Carl doesn't realise just how often this could be used to simply 
a vast array of code.

Oh, the unit syntax. There would be limits to what you could do, 
but the principle is sound. You probably wouldn't be able to do 1".

If we do these as mezzanine with the full R3 *EACH word and set-word 
syntax these become big functions, similar in scope to my R2-Forward 
MAP function. If we limit the words to the word! type it becomes 
much easier, but still with more overhead than ANY and ALL. I had 
put off working on these for months because I thought DO/next was 
needed to implement them, but I've just realized that it isn't.

That would require a REDUCE or DO/next to use referenced data, and 
this function is too inefficient to use with inline data, as compared 
to the ANY and ALL equivalent code. These functions would only be 
worth using for large datasets, or otherwise their overhead would 
be too much. That is the problem ANY+ had :(

I started a deep deep thinking process wich is a heavy task for an 
idiot biain of mine concerning the futur of viva-rebol and where 
i want to lead it.


If you have a little interest for what i'm doing actually you know 
that i'm actually working  on 2 projects viva-rebol and rekini. I'm 
interrested in transforming viva-rebol into a real time collaborative 
project. manager/editor something like wave but done in rebol to 
create rebol application.


The idea that comes to my brain is to mix IRC and vivarebol. IRC 
would be the supplier for sharing real time documents content information 
and viva-rebol will be at the same time manager and the renderer 
that will catalise the informations collected by irc.


Why irc?  first because they have lot of control feature wich can 
allow anyone to join and see an onShared-creation docuiment  or script 
and only look at it without active participation. That can allow 
a hierachy system with master, co-writer and only viewer. and the 
allow the master to select who participate or not to the création.


We saw with area-tc that rebol and VID and the dialect concept was 
really feat to handle uncomon text handling  at light speed so the 
appears clear for me that this is the next step to go.


Some people will say to me "but it's more important to have an advanced 
rich text editor tool"  which i answer that boring to do and in the 
result the gain in notority for rebol is close to 0. So instead of 
 clonning MS-Word using VID I prefere move to the next step wich 
I hope will lead us to make people see all the potential of rebol.


It took me looooooooooong time (6 years in fact) to see how to merge 
all the interresting part of rebol to make a big project wich we 
could be all be proud of and show all the interesting part of rebol.


Our comminuty is small and working together to make advance the projects 
is obvious if we want our project to be recognised in some way. If 
we all work on our sides on our own project achieving a high quality 
for those projects is hard.  So externally we only show to the world 
project that looks more like teasers than completed project and that 
not a good thing for rebol promotion. We can say all we want about 
the way rebol is done by Carl but us as community which goal is to 
spread rebol world wide we have a part of reponsability in that too.

but if you want a persistant extension of that making an irc bot 
that collect all the project worked with the viva-rebol online feature 
and making the bot publish them on web that's easy to do.

You do it once. After that, do you expect to receive thousands of 
messages per sync?

Please don't make it use scientific (E) notation.
 - so, what do you want to get from:
10% + 10% + 10% - 30%

I wouldn't rely on any kind of Gui expectations for a while in R3. 
 AFAIK, a lot to do still.

now this done - that why i ask for an upgrade of gui-load and demo 
and to do it also for other version like linux.

I'll be using modules if possible.   an earlier version of R3 just 
crashed when trying to allocate a single node... we'll see.

is there a page which explains various optimisations one can do to 
R2 code to allow it to take advantage of newer and faster functions 
in R3?

Maxim, so many things to do. Can your super brain handle it? :-)

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.

Works for me: 

>> write %mod1.r to-binary "rebol [type: module] print 1" 
>> write %mod2.r to-binary "rebol [type: module] print 2" 

>> write %mod.r to-binary "rebol [needs: [%mod1.r]] import %mod2.r 
print 3" 
>> do %mod.r 
1 
Script: "Untitled" Version: none Date: none 
2 
3 


Note that if you specify your Needs in file form, system/options/module-paths 
won't be searched. Any relative filename will be resolved relative 
to the path of the importing script. Does this affect you?

Do you know the R2 SDK source well enough to know whether the Needs 
header is handled by mezzanine code in R2? And where?

If you want the module to be referenced in the module registry so 
it doesn't get reloaded you need to do the word-based module style.

shared and distinct/copied modules should both be supported.  right 
now I am not sure which one R3 does but, it doesn't provide the capabilities 
to do both, AFAICT.

strange bug... If I only
 do %vprint.r3

in the module and try to use a function from vprint, I get an error:

vprint loaded
** Script error: von word is not bound to a context

** Where: do applier make if import catch if either either do begin 
do
** Near: do body obj

vprint loaded
 is a probe statement executed within the vprint.r3 file

If I get this, it means that  DO is always global, and the only way 
to trap it, is for the module to isolate the global context from 
any code it executes.

No, DO is always relative to the current context and there is no 
global context. And you can switch current contexts, though that 
mechanism isn't fully implemented yet.

I know R3 will have threading ... this is some video that digs into 
pythons implementation .. and shows how not to do threading mostly 
... http://blip.tv/file/2232410

Thanks.Ladislav....I don't particularly mind _why_ R3 is incompatible 
with _R2_. Forward compatibility would have been nice, but that discussion 
ended long ago with the decision not to be.


What I think we need now is to start work on a  migration guide, 
so we do not all need to stumble across the gotchas.....It may also 
help debug R3 [some reported changes may turn out to be accidental 
and fixable].


Hence my question about where would be a good place for us to start 
sharing migration hints and tips.

I don't even understand why you'd want to do so... its exactly like 
forcing a reduce everytime you copied a block.