AltME groups: search

but you insert example is just a chain... it gets insane when you 
also have offsets, cause you want to insert into sub-blocks  ;-)

perhaps it's a bit too many fixes for one release. one part of chat 
is mysteriously broken right now.

ah, load-plugin .... what a bad name once again. Why load or import 
does not handle it internally? ('import is used in the blog article)

That sounds like an internal function that hasn't been put in a module 
yet. There is a similar function MAKE-MODULE.

A:

1) They are different concepts, but devices may be implemented in 
plugins.

2) Devices wrap host or hardware things. These things include stuff 
needed for I/O, graphics, etc.
3) Well, plugins for start :)
4) Yes, absolutely.

thanks. I just have a little problem understanding 1), but never 
mind. So plugins are superset, the ability to extend environment. 
And as they can contain REBOL code, C code, they can contain even 
Device in itself? Well, it will be better to wait for API docs probably, 
to see some real-life examples ....

do devices wrap hardware directly like a real device driver or does 
it wrap the underlying OS driver?

We need utypes for host interoperability, to replace rebcode, and 
more. A utype will need to be able to react to the actions, just 
like a type

But - I can imagine having library containing functions to handle 
mouse, but Amiga had device for each, which allowed it to function 
in a more async way ...

Right. R3 is built like an OS. And designed by the same guy who designed 
*that* OS. It might follow a similar model.

The device will have associated functions, but those functions might 
be defined in a plugin. Or not.

Too costly on host OSes, you mean. Some host OSes provide APIs that 
structure hardware access, like the Direct* APIs. Devices could use 
those. Or if R3 is just running on a bootloader (as proposed in Wildman), 
the device functions would access hardware directly.

About #564 and blog#207: I'm a little lost, is option 3 already implemented 
in alpha55?

Part of the trick here is that you have to balance the benefits of 
error generation versus the overhead of error handling. We've been 
careful to make a lot of code that used to generate errors in R2 
just work in R3. If there is a good rationale for "just working" 
that is.

I agree on the benefits of treating unset! as noops in such cases 
: 
ANY [( )] == none
ANY [( ) 1] == 1
It's usefull and is consistent with the way COMPOSE treats ( ).


But I still think that's some way of getting unset! values may lead 
to undetected errors like in :
>> test: func [a] [print a exit]
>> if any [test 123] [print "ok"]
123
== none
>> result: test 1
1
** Script error: result: needs a value


I understand why you were asking for such change, but it's hard to 
know if it won't cause more trouble than gain.

ANY and ALL are used as control structures too. If () was defined 
as a noop, I would use it that way on purpose. If not, I wouldn't.

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.

Not a bad idea, at least for the built-in functions. In my experience, 
the main use for PRINT in ANY or ALL is debug statements. Most of 
those go away now that we have ASSERT. We didn't have ASSERT in January.

Btw (digressing a litlle), I've always found inelegant the way unset! 
was used by PRINT or other console-oriented functions to avoid returning 
a value. I'm maybe too purist, but I would have expected PRINT to 
return the passed argument (making PROBE unnecessary). Other solutions 
for making functions (native or user-defined) more console-friendly 
could have been choosed (not having consequences on language's deep 
semantics), like adding a special flag in the spec block! (as 'save 
or 'throw).

I really don't mind having some functions return no-value. The interesting 
decision to be made on a case-by-case basis whether no-value is an 
optional return or all the time, and whether no-value is generally 
an error when used, or not. #[none!] is the no-value that is generally 
usable as a value, or at least not an error most of the time. #[unset!] 
is th no-value that really is not a value, and most functions treat 
it as an error, but not all.

I understand unset! values as an exception case where there's no 
value to work with. As such, IMHO, it should be treated as an error 
as much as possible. We should stick to the principle of least surprise. 
 

It wouldn't hurt if R3 unset! values were treated more consistently. 
But this is a deep topic, I remember that Ladislav had some interesting 
propositions about unset! (like, IIRC, removing it from user's eyes 
and keeping it internal only). While browsing about that, I've found 
a few interesting links :
http://www.rebol.net/cgi-bin/r3blog.r?view=0100
http://www.fm.tul.cz/~ladislav/rebol/rep.html#section-18

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.

We get a different answer every time we have this discussion :(

Yeah, and it doesn'tt make sense to ignore unset! with REDUCE because 
that is a value context. With CONSTRUCT it is treated as no-value 
and not inserted. Both of these are the right choice in their respective 
cases.

The main difference between ANY and DO, aside from ANY stopping early, 
is that ANY has a default value: none. Having a default value means 
that no-value is acceptable, so it returns the acceptable no-value. 
DO doesn't have a default value, so if the last expression generates 
no-value, that is passed along. That was the rationale for #564 and 
option 2, at least.

I'm actually OK with either option 2 or 3, but there are tradeoffs 
to either. Which reminds me: Which built-in functions in R3 return 
unset! values? I can only think of PRINT and PRIN, off the top of 
my head. WRITE returns a value in R3. Even ASSERT returns true.

yes, this world needs restart. I advice, before you post, press CTRL+A, 
then CTRL+C to get your post to clipboard first, to save your sanity 
:-)

Maybe it would be get to post your idea to R3 Chat, R3/Datytypes 
section, or as a wish to CureCode, as Carl will not be able to read 
it here ....

REBOL values only need to be serializable in REBOL format from the 
start - that is all the datatype! spec allows. That means MOLD and 
MOLD/all formats, and vectors support those peoperly as of alpha 
55. There are only so many operations that a datatype! can support 
internally. These operations are known as action! functions.


All other operations on a datatype! can be implemented as REBOL or 
native functions, and these functions can be added later if need 
be. They don't need to be there from the start. Codecs seem like 
a likely choice in this case, once the codec model changes to allow 
streaming. The current model is a just-for-now placeholder.


Welcome to the wonderful world of alpha software that is still being 
designed :)

I'm a little disapointed about how Carl deals with the design of 
vectors.

Vectors are serializable in the only way that REBOL datatypes can 
be inherently serializable: through MOLD. This is a basic limitation 
of how datatypes are implemented in REBOL. All other forms of serialization 
*have to* be implemented with other functions.

The actions are the only functions that can be implemented *by* a 
datatype. All other functions are addons.

Serialization is a general concept here.

I'm talking about convertions of vectors into another formats (like 
blocks or binaries).

molding a vector is of no use in real applications.

Wtf, i want the reference of the hardstored binary data of the vector.
What the prob ? it's stored as a binary stream

It's a safety issue. That kind of access will be done through accessor 
functions.

there is nothing to hide, a vectors is a binary serie

so to secure it, there will be a copy. If not it can be secured

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

what kind of bad modification could exist with a binary serie ? there 
is noone.

To my mind a vector should be just a wrapper on a binary serie.

just a new handy way, to modify or get values from a binary

There are unsupported floating point numbers (inf, nan), and vectors 
must be a multiple of their component parts' size.

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 ??

I am OK with renaming too. OTOH I too dislike map-each, remove-each 
names, but not a big deal here ...

Two questions:
1.  is there a way to load-gui from local file ?
2. How is unicode in rebol3 working ?  (is it working ? ) :)

Well, one advantage for calling them something other than map and 
filter is that you could put functional map and filter functions 
in a module somewhere and not have naming conflicts. They'll be less 
efficient and less flexible, but at least the functional programming 
fans would be happy :)

That's a good point Maxim - we better make sure that IN series block 
is never added as a feature :)

steeve, this isn't a noun prefix.

that is a big difference.

map in this context is a verb.

much better to include a totaly obcure character... sure steeve. 
 assembly style code is much better than C.

but in any case, REBOL style usually uses the '* as a notation for 
"pointer" or "reference to",

brianH to me, a reference in rebol is not the same as a reference 
in C.  semantically they are equivalent, even if technically they 
are implemented differently.

meaning, keeping a reference to some data.   which is why we never 
use a-word* to store scalar values for example, but we will sometimes 
use them for copies of series, and words.

why is why reference, in REBOL, has a different meaning to me.  if 
all words are references in C terms, then that concept has its own 
meaning in REBOL terms... IMHO.

I prefer just "map", but if there's going to be a name change, I 
think "map-each" is best - not only is it consistent with foreach, 
remove-each, etc, it's shorter than "map-every" or other alternatives, 
and feels like more natural English to me.

And I use my map all over the place

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 propose a new fork for rebol.
REBOL-EACH

fact is that find with a codeblock as criterium would be very usefull 
.. maybe it already exists under some other name? I remember someone 
proposing it not a long ago too

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 )

Steeve, the *EACH functions have a really specific calling convention 
and all have the same bind/copy overhead for the code block. The 
other series functions have neither of thoise characteristics.

Janko, REMOVE-EACH is not reverse in meaning - elements are removed 
if they meet a particular criteria. The REBOL version is modifying, 
though.

Steeve, is the filter function modifying or does it return a new 
series?

I use REMOVE-EACH a lot in R2, but mostly because of how fast it 
is. It is easy to make your condition return false or none.

Pekr, MAP-EACH (using the new name) is used in LOAD to implement 
LOAD [%s1.r %s2.r ...]. I don't know how it is used in the rest of 
the mezzanines. I mostly use it in my own code, but the version I 
backported to R2 as a mezzanine.

I don't care about the exact name much ... I usually call it reduce 
but reduce has a very important and basic meaning in rebol already

Yeah, and a different meaning too...

BrianH: one question - what is the motive to have R3/plus? Is there 
really a need to move few funcs out from main R3 module? Isn't it 
a bit preliminary?

Pekr, I'm still mad at you for making me think R3 was almost done 
a year or so ago.  I waited with great anticipation for that date. 
 That was a big letdown!  :>)

in cases where the data is pretty linear or backup isn't needed due 
to format, a simple error is all you need to return when you encounter 
un-expected data... this can mean streamed xml parsing.

Pekr, I'm doing that right now head smashing right now trying to 
find a bug in my script.  It doesn't seem to help. But don't worry. 
I'm not really mad at you. Just joking.

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.

hmm, somewhere, i have a script which simulates parsing on an opened 
file (a port) in R2

wait a minute

Perhaps there was a glitch in one version.

I've checked a few older R3s and a 2003 R2....They all behave the 
same way.

Here's a good place for that kind of chat.

DevCon - yes. Interesting, because we are starting to plan a trip 
over there (Europe) already.

anyone got a link?

(that's a separate topic... btw)

btw - I can see some new users in R3 Chat - it is a good sign. From 
the point of RT - are you still contacted by new users/companies? 
Is there any interest in R3? Sometimes I feel that we are unnoticed 
:-)

As for R3 and me, I can't wait when we get back to GUI. It was good 
period. And times flies by - it is one year you started to work on 
it. The model is good, we "just" need to finish it and allow it to 
display Unicode. Well, some kernel changes are needed too, but if 
gfx is going to be open-sourced, not a problem ...

There is a certain satisfaction when something difficult falls into 
place. And it's true that it's sometimes not only difficult to design 
and code but difficult to explain. :-)

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

A codec only works on in-memory data... even at a low level.

I posted a very detailed description of event handling on the wiki.

I think it covered pretty much the entire thing. But it was a long 
time ago.

Posted by Doc - "Having the TCP/IP part open-sourced in R3 will be 
great. It will allow to use much faster OS hooks for file transfers, 
extend the port! API to bind only on selected interfaces, etc...I 
wonder if the main event loop will be there also, so we can replace 
the not-scalable Select( ) call by other faster ones or even integrate 
libevent. That would definitely make Cheyenne able to handle a much 
higher number of connections."

Plugins can be internalized... so yes, a single exe is supported.

There are a few simple init levels in the host.

Ah, good to hear ... it once again starts to sound like MagmaOS/Wildman 
is still a long term plan :-)

Carl, cold you put out the June plan blog a little earlier this time? 
It would help with prioritization of tickets, something that was 
skipped recently because we didn't quuite know what was going on...

Not sure what you mean? Building a future? :-)

B: on block, good.  On DO/next... fastest would be a do-next, maybe 
private (not exported.)   Problem is DO is heavily "loaded".

B: let me take a break and see if I can get it to you somehow. Maybe 
a special A55.1 build for you to try.

But, is there a solution to the bug it causes?

It is not thhe cause of the bug. Read the ticket again - I found 
out the real bug and fixed the ticket at least a day before alpha 
55.

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

DO of string not working is a worse buug than CATCH/quit messing 
up a TRY block.