AltME groups: search

this way no need of having to maintain 3 x3 rebol plugins ... lot 
of saved  time for Carl i will say

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.

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?

so we can do array transformations in REAL TIME for things like polygons 
and 3d objects  :-)

Well, I don't have the time to write CureCode tickets :(

i have a very slow connection currently, most of the time i'm disconnected 
-_-'

No time for that today though.

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.

yes... decimal! should be BCD and we should have a new float! type 
which equates to current decimal


if no current R2 is going to be compatible anyways... I think this 
is a good time to fix this issue once and for all... its always been 
an issue, since core 1

for me, R3 is a real attempt at delivering a finished product.  probably 
the first time since rebol's creation.

My experience is, that Carl works in his own world, and it is good, 
we communicate with him via some "API" :-) E.g. I had to mention 
article about the need to use better timers (not done yet) for something 
like 3 or 4 times. Then, when I found the right time and his mood 
to actually look into it, I think that he agreed that there is better 
solution than what we now have ...

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.

The reason I am checking this now is because it is time to backport 
the module system to R2. The code is pretty easy (and mostly written) 
- the design issues are not. Since you've written a module system, 
your input may be valuable.

so ... now might be correct time for him to post some ideas :-)

RAR already switched to another naming convention, so we should still 
be good by the time REBOL 10 comes out :)

Please keep trying. It may time out 10 times in a row and then it 
comes.

(continued from !CureCode) When the time comes, the Parse Proposals 
will need to be reorganized so that there are separate sections for 
general operatioons, and for the operations that are specific to 
blocks, strings, binaries, ports. At the very least, there needs 
to be good binary pattern recogntion operations.

although liquid-paint is already much faster than AGG and lazy so 
the gains might not be as noticeable, but still I can't wait to have 
time to try and port my stuff to R3, it does seem to be much more 
series stable, by all accounts.

Brian - ticket #588 does not crash here. It just takes lots of time 
and resources to display 20x9999999 size button :-)

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.

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 :(

I just wanted to underline that it's not good to postpoint the design 
of vectors.

Currently their design is too limited to be usefull (not serialisable, 
no scalars operations).

I hope there will be not huge drawbacks when the time will come to 
complete them like they should behave.

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).

I never said R3 is close to being finished. So what let-down you 
are talking about? We were talking public release, which happened 
and is available for some time.

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.

I have some improvements in my mind.

For example, I could optimize the copy/part  actor to get it really 
faster.

Because currently doing loop 10 [copy blk] or copy/part blk 10, takes 
the same time mostly

I would like to ask, if we could start some very preliminary planning 
for Prague Devcon 2010 (May, June?). It should be time of R3 official 
3.0 launch :-)

Brian, ok... that's good to know.  If it looks time consuming, maybe 
see if we can get some volunteers to help?

Well, those questions are here maybe because we lack few handy diagrams, 
e.g. like you did for Devices blog. But it costs your time, so we 
might prefer you working on that stuff first :-)

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

Each time I see someone mention Erlang model I want to post my last 
"actor-ish" rebol samples I made like 3 weeks ago and still haven't 
found time to post .. it's nothing special, but it can give a little 
feeling and future ideas how it would look in rebol

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.

There were no changes in gfx kernel for quite some time, no? Well, 
but maybe it could be related due to some other changes?

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

for example you and me works on the same file at the same time using 
viva-rebol ide and you fill a part of the file i fill another part 
of the file and we both see in real time what the other is doing. 

(for example you do the parse parse rules and i write the GUI  of 
an applicaton things like that)

well that's not a new thing Moon edit propose that kind of collaboration 
real time since some years already. what i like in wave is the modular 
aspect  you are not limited to a conversation you can create  "wavelets" 
to anykind of  use and extrapolating that system to the already existing 
rebol tools (rebol.org, view/desktop, ios etc...) would be really 
a big thing

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!

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.

well, in some time, the dollar wil disappear, so we'll got one more 
unit free

(some time ago)

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.

I think proposing a collaborative real time tool for making rebol 
script is a good idea as a leading project to make every one acquiere 
or show high level skills. That's in my opinion more productive than 
having Gurus explaining to stupid morons like me things during weeks 
with no concrete result to it.  Sooooooooooo I propose to KEEP IT 
SIMPLE. Instead of explaining me the solution take half of the time 
you normally use to answer me to edit my script make the changes 
and then ofcourse we can have a nice chat on why you used that and 
not this and that will make my level progress a lot. And most important 
of all the problem and my project will be solved and working.

ofcourse if that tool allow 10  personne to build from white page 
a rebol script that can allow them to write a documentation allowing 
them to see how are feeled each part of the documents by the contributors 
and make comment on those parts on real time.

The R3 chat protocol (as it is now) is not suited for real chatting 
with a massive exchange of short messages between users or specific 
channel.
Because each time you sync, all is loaded in local.

loading http://twitter.com/rebol3here is a 14 kb webpage for 8 messages, 
excluding images, so it's probably 20-30 kb each time you want to 
read it. With the information amount we want, R3 Chat can probably 
deliver over 200 times more messages in the same bandwidth, assuming 
that each message is < 140 chars. And also R3 chat only retrieves 
them once. After that, they're local. Twitter loses. :-)

steeve, local caching is not a drawback, its a feature... it prevents 
the client from having to check all messages EVERY time it starts 
instead of just once.  there should be more parameters though, I 
agree, giving a time frame would be good, so that it knows to forget 
old messages you don't care about, for example.

how much time to get a gui in rebol3 linux and other ?

image magic also supports floating point image manipulation and has 
a lot of built-in high-quality filters (real time 200 pixel gaussian 
blur anyone ? :-) and more than 10 image filtering functions IIRC.

Next time the GUI will be touched, will be a redesign of the layout 
engine, which performs poorly right now.

a general question for those of you actively testing using REBOL3. 
 Is it stable, a part from the known bugs or function differences.... 


Once a rebol3 source works... can it be expected to run for a long 
time or are there still many internal bugs which will inevitably 
cause the app to crash (gc instability for example).

If you search curecode.org for [gc] or [garbage collection[ there 
are very few bug reports.

Maybe it is time for someone to step up and try some serious stress 
tests.

I've just finished helping the plumber install a new submersible 
pump in my 50 meter deep well, changed all the electricals too... 
I didn't have water for the last 4 days... 


now I can give myself a rare treat.  taking the rest of the day off 
today, so I can do my things.... and that includes one "fun" project... 
usually a short project that I've been putting off of a long time... 
today its liquid/R3  :-)

I've noticed that devbase has the same problem as altme at recognising 
the daylight saving time... I have a one hour offset in time postings.

OK, got it. If you import a module the first time and it has a name 
header it gets added to the registry - it doesn't matter whether 
it is imported by word or file.  However, any subsequent import of 
the same module by word will reuse the module - if you reimport by 
file it is reloaded (there is a bug in IMPORT too, so the new displaces 
the old even if they are the same version). I'm going to have to 
rethink the flow here.

the guy tried to run a long-running-cpu-intensive-func 2 times one 
after another, and in two native threads (on 2core cpu) that python 
supports and running it in threads took 1.8 more time than running 
it one after another

(but it may be "expensive", i.e. time-consuming)

There is an error in the import process, but modules loaded by filename 
are actually loaded each time. If the module has a name header then 
only the first import works properly. Every subsequent import by 
filename will be a logic error. However, you can import a named module 
the first time with a filename and then use the name for all subsequent 
imports with no difficulty.


If the module is not named and specifically designed to be loaded 
multiple times, then cool, you can do so.

ok, so far it seems strickly related to file based import... specifically, 
when it tries to load the file a second time.  it raises the assertion 
crash.


reloading a module can be needed... it was changed, for example, 
and you want to allow run-time updates, cause your ip ports must 
not be closed.

why is that?  this means we can't create new words in a module at 
run-time?

Yes -- I am hitting bugs, reporting them on curecode and often seeing 
them fixed in just a few days. It's a good time to be evaluating 
R3.

Plus all that binding takes MASSIVE amounts of time for nothing.

Well, summer is going to be a slow time anyway, for many of us ...

It could take a long long time to run an example showing this.

Nice talk. Time for me to move to other things...

I would have thought EQUIVALENT? would imply the same time zone, 
or at least some time zone math. Certainly STRICT-EQUAL?.

Equivalent? - it would use time zone math, even EQUAL? now uses time 
zone math:

>> equal? 7/7/2009/10:00 7/7/2009/10:00-02:00
== false

>> equal? 7/7/2009/10:00 7/7/2009/8:00-02:00
== true

d/zone  = none is related to the d/time = none, yes

So apparently the time zone is never none, but the whole time in 
date! may be none.

R2 words preserve the case they are *first* typed in, not the case 
they are  in every time.

yes, but it takes time: the "probability of encountering" is proportional 
to running time as well as to call frequency

Carl states, that time-zone precision was rised to 15 minutes. Is 
it any usefull? :-) http://www.rebol.net/r3blogs/0217.html

Any and all fixes to time would be good.

If you need to do exact comparisons with floating point numbers you 
need to use subtraction and comparison to 0.0 - it's the only way 
to be sure. Exact comparisons with floating point numbers have to 
take into account that the numbers themselves are not exact the vast 
majority of the time.

It turns out that the length of a tuple is set at tuple creation 
time, and that length affects LENGTH? and PICK, which are called 
by LAST.

http://www.rebol.com/r3/downloads.html- Win and Linux this time. 
I expect non-Win platforms being Core only too ...

ah, damned, latest time related changes brought back so called RED 
ICONS problem once again :-) We are still not reporting timezones 
correctly, ignoring summer time ....

Ah, actually quite the reverse. The problem of R2 is gone. Summer 
shift time is different date each year .... R3 works correctly, R2 
does not ...

That's cool - even a73 was broken - when you set time back to winter 
time, it reported wrong zone information. a74 works correctly.

when we don't find a word in a slot, we fail;  my question is COULD 
we tolerate an unset! where a word! is now expected ... the Rebol 
path! type is just too useful to ignore here ...  and our use of 
the character '/' does have "something" to do with our natural interpretaion 
of file and url - files assume valid hierarchy depth at time of tracversal, 
a web server need not ...  at the moment we have no type corresponding 
to what follows an HTTP schema and domain other than string .... 
or am I mistaken?

BrianH: is there any difference between R2 and R3 'call functions? 
I would like to test the boot time of R2 vs R3, and I thought I might 
use one REBOL process to call another one in a loop. I want test 
R3 vs R2 and R3 vs Rebbase. What methodology would you eventually 
suggest?

My guess is that immediate! types are ones whose values fit within 
a value slot of a block or context, and thus are not reference types. 
I would put all of the numeric types including money! in that set, 
as well as date!, time!, tuple!, and event!. Most of the time gob! 
can fit in there too, afaict, as can error! with codes less than 
100.

meijeru: dunno what rules here are. I always agreed that ppl should 
be able to choose their nick-name here, but some other had different 
opinion on that IIRC. But maybe we could ask for change, as you are 
here for short time yet ....

maybe it's time for a beta version, as most features are in its place 
then?

hmm, no IO, callbacks this time .... I look forward to REBOL gurus, 
bringing some usefull features to R3. However - it is more than clear 
that this type of interface is not for all. So - I still look forward 
for vastly improved DLL interfacing method, which allows even ppl 
like me to have some usefull things done ...

I don't want to allow , in words, I want to have the word be recognized 
and then have the lexer complain about the , next time.

The comma is so bad syntactically that throwing an error every time 
someone tries to use it is considered a valuable feature.

http://tlt.its.psu.edu/suggestions/international/bylanguage/japanese.html


To elaborate on what Gabrielle said, in most languages, there is 
a large and small version of letters for use usually in sentence 
case, and also for abbreviations, etc.  Over time these began to 
be written differently, so the large and small actually look different.


But in Japanese, small letters have a completely separate meaning, 
sometimes used to elongate a sound, or form a subtle guttural stop.

Here is a sample, it is VERY subtle.


http://christopherfield.com/translation/images/hashiriame/story_a.gif


In this image look for all the symbols that look like a backwards 
letter "C" (or letter "U" that fell to the left).

Sentence 1 - 3rd from the right.
Sentence 6 - 3rd from the left.

Notice they are very subtle different sizes.

That is an example.

Bottom line, as stated, don't mess with caps with Japanese.

(it was hard to find a GOOD example of this in the same image).

I will reword my question.  In R3 how can I read in one line of unicode 
text at a time to process it?

Request ... I would like now/time to always return the seconds.

Annoying isn't it? Have you submitted a wish to curecode.org?

For now, I use something like this:
    reduce [x: now/time x/hour x/minute x/second]
    ==[12:30 12 30 0]

to-integer now-time

eh, to-integer now/time ... does it return seconds? I think so ...

I am against now/time returning seconds - it shoul stay "human readable" 
....

to-itime is only really good for consistently printing time, for 
example for a running clock.

Well, it is supposed to be used for forming internet time strings.

You probably don't need to worry about creating entries in the symbol 
table though. Word lookup is constant-time, and there is no effectve 
upper limit to the number of words it can hoid - you'll run out of 
memory in a 32bit address space first :)

I am hoping this is on BrianH radar ...  I thought at one time you 
were kinda the guy who spoke for the community ?  Gab is aware of 
this and Oldes - doesn't he generate FLASH or PDF or something ? 
 At the moment my own option is to take shelter in PHP and PHPTemplate. 
 I wanted to fall back on Smalltalk but all the web frameworks from 
the MVC gurus seem to miss the point that the View was supposed to 
be de-coupled.  Go figure.

I think that in UNICODE raw string is now meaningless to end users; 
Americans ignore that European languages often have variant opening 
quote from closing quote ( as did British English in my youth, as 
I recall )  this is a new phenomenon in America: educated Americans 
spoke French, read French and if they were mean, had often spent 
time at a German university,  The North American shool system was 
of Prussian insoiration, as I recall.  But atleast Carl is learning 
French ... but does he use << and >>  ... that I woulldn\'tt know 
\"  ;-)   So that leave literal strings  such as @"  "@  I still 
use a language with a character count delimiter pair

RobertS, this means that you can do server-side processing of JavaScript 
using R3 right now, without heredocs. All you need to do is escape 
unbalanced { and } in your REBOL syntax { } delimited strings. The 
escaping is resolved at LOAD time, so the resulting strings don't 
have escape sequences in them. Then you can combine and generate 
the resulting string data without concerning yourself with escaping.