AltME groups: search

Consequently, you're better off with a two character A~ for AND~, 
because you'd end up having to throw in spaces on the left and right 
of the & all the time otherwise, which gets you three characters, 
and you'd probably have to throw one on the left half the rest of 
the time.

So the issue we discussed about needing to build the map ahead of 
time is taken care of right there.  After this step, G is an ordered 
series of two-element blocks... each with two integers, the coordinate 
pair of where that dot is.

I think there's a big gap between the usefulness of a spanish or 
Italian localization and a chinese localization.

 - actually not, as Jerry mentioned some time ago, there are exactly 
 the same reasons why it is not useful

You guys can do better, you know the language better.  I only just 
learned "Any" and "All".  I know the gist of Rebol but I've clocked 
not too many hours with it, this Rebmu thing is the most time I've 
ever spent with it to be honest.

I spent not only time, but money paying some guy to 3D render this 
darn logo: http://www.rebol.net/wiki/REBOL_logo

This entry at Wikipedia seems to suggest that is it OS dependent 
- http://en.wikipedia.org/wiki/System_time#Operating_systems

I tell you what is so surprising about the results:


Since the result is the loop body execution time, it looks, that 
the loop body in Peter's computer works ten times faster. Gabriele, 
Davide, and Peter, could you please post here your result of the 
following expression?:

>> time-block [now/precise] 0,05
== 2.3651123046875E-6


 it looks that your processor works faster, Peter: your result is 
 the loop body execution time, which is about ten times shorter, than 
 the loop body execution time Ga

>>  time-block [now/precise] 0,05
== 9.0625E-7
 
OSX, [Core2Duo-:-2Ghz]

>> do http://www.fm.tul.cz/~ladislav/rebol/timblk.r
connecting to: www.fm.tul.cz
Script: "Time-block" (1-Jun-2010/13:40:09+2:00)

Warning: clock tick too short, the result is the loop body execution 
time!
== 1.78988326848249E-6

>>  time-block [now/precise] 0,05

== 7.1484375E-7

OSX, [Core2Duo-:-2-:-4GHz]

I wouldn't be surprised if OSX had an order of magnitude better resolution 
in all things related to time and its measurement.

and how do you measure the execution?  by accessing some form of 
timing or time information.

Of course, the evaluation time of NOW/TIME may be operating system 
dependent, but it is still interpretation time (of the above expression)

Peter, how about this one?

>> time-block [] 0,05
== 7.80820846557617E-9

Max: "how so?" - I suppose, that you do see, that the TIME-BLOCK 
function is able to measure evaluation time even if it is shorter 
than the system clock resolution?

>> time-block [] 0.05
== 1.45263671875E-8

, so, it looks, that the time the system spends in NOW/PRECISE is 
nonnegligible

what does this do in the time-block  while condition?

(3 * tick-time / time)

>> time-block [ ] 0,05
== 1.251220703125E-8

Out of interest, I ran the same tests in  Windows/XP running under 
Virtual Box:

>> do http://www.fm.tul.cz/~ladislav/rebol/timblk.r
== 1.00330578512397E-2
>>  time-block [now/precise] 0,05
== 7.59124755859375E-7
>> time-block [ ] 0,05
== 7.57351517677307E-9

The times for time-block [] and [now/precise] are quite consistent. 
The time for timblk.r improved to around 9.93E-3.
 

Windows may still have been completing its start-up when I ran the 
very first test.

I've just run the timblk script another 5 times each time the result 
is ~9.937E-3

you do not have to run the script, it is the

    tick-time: time-tick 0.05

expression

What initially surprised me was that there did not appear to be a 
significant difference bewteen OS X (native) and XP(VM) with  time-block[now/precise] 
0,05

I was less surprised that XP(VM) performed time-block [ ] 0,05 about 
1.6 times faster than under OS X (Native) as I suspect that Carl 
is more likely to have better  optimised Rebol on Windows than other 
systems.

>> time-block [] 0,05
== 7.97957181930542E-9

>> time-block [now/precise] 0,05
== 2.11906433105469E-6

so, the time granularity of XP running in VirtualBox looks smaller, 
than when running natively

From a quick browse of the Virtual Box User Manual, a VM uses the 
host systems "time stamp counter" by default. There are a number 
of options to change the "guest clock".


It's section 9.10 in the Virtual Box User Manual if you want to take 
a look.

>> time-block [now/precise] 0,05
== 2.328125E-6

>> time-block [now/precise] 0,05
== 2.43203125E-5
>> time-block [now/precise] 0,05
== 1.526171875E-5
>> time-block [now/precise] 0,05
== 2.44140625E-5
>> time-block [now/precise] 0,05
== 2.42890625E-5
>> time-block [now/precise] 0,05
== 2.4203125E-5
>> time-block [now/precise] 0,05
== 2.4265625E-5

>> time-block [] 0,05
== 1.11503601074219E-8
>> time-block [] 0,05
== 1.11885070800781E-8
>> time-block [] 0,05
== 1.11618041992188E-8
>> time-block [] 0,05
== 1.12886428833008E-8

(btw, i guess Linux is doing timezone conversion in the time system 
calls, while osx is not, and that would explain the huge difference 
in speed.)

Originally I thought, that the FUNCT function was quite adventurous 
doing a deep search for set-words. But, after using it a couple of 
times, it really looks like it does what is useful most of the time.

saves time ..

Now if you created the closure yourself ahead of time, instead of 
creating a new closure every time (as USE does) then it would be 
faster.

If conversion functions aren't done by the time I finish the module 
system revamp, and I have the time, I'll try implementing the model 
suggested in the comments of that blog. Not the struct! type though, 
that would be terrible for conversions.

fork, I undertand your gripe with /only.   but I'd rather have 'Only 
one refinement name to remember for all of the less processing fringes 
cases, than a different one for each of them... even in my code I 
use /only..... everytime I do other wise, I end up cursing, cause 
after a while I forget the refinement name and loose time looking 
it up.

R2's behavior has always worked well for me. Unset is the special 
case I avoid unless I really, REALLY think there's a need to leverage 
it. I very rarely use any-type! for that reason. I like declared 
locals being NONE. I can't think of a time I tripped over using a 
refinement without passing its arg, but there unset would have to 
be intentionally expected as well.

I'd probably stop using func most of the time, and I can't see myself 
typing funct  20 times a day.


everytime I write it, I feel like I'm writing a less savory femal 
genital word in a strange dialect of german ;-)

Happens all the time.

At the time of the last R2 release the documentation was being reorganized 
and no third-parties had access to it. So I couldn't update the documentation.

It can be fixed, but I don't have the time to work on extra docs 
at the moment. I wrote a lot of documentation in the R2/Forward source, 
and it has the advantage of being tied to the specific version of 
the code that it refers to.

Well, Rebol lost the battle for mindshare on desktops and servers 
.. time to see if we can get somewhere on phones

Rebol on mobiles makes sense to provide mobile clients to some commercial 
enterprise apps. Management loves to see the latest real-time sales 
numbers.

1. host-kit release: It's still Carl's job and responsebility to 
release official host-kits. We (RM-Asset team) won't do this.


2. host-kit support: Yes, we spend time to work on the host-kit source-code. 
And yes, we concentrate on these things we need for our upcoming 
projects. All this will flow into the host-kit and be available to 
you. And, I'm sponsoring this effort. Our goal is to help to get 
the host-kit to a stable state ASAP.

5. Extensions: We will create a bunch of R3 extensions we need. Some 
will be quite special, some more generic. For these we use a mix 
from open-source libs, commercial frameworks etc. Which bings up 
the nice licensing issue stuff if things should be released.


As I hate licensing issues at all, and it's a big time killer, my 
rule is quite simple: RM Asset will have all necessary licenses we 
need, if I can release stuff we think about it. If not, than not. 
Sorry. I don't have time to get all this sorted out to provide a 
perfect-R3-framework to everyone.

Am just getting started with Rebol; haven't spent some development 
time with TCL. Would like some direction on where to start: V2 or 
V3 (with the understanding that V3 has yet to achieve commerical 
level release).


Simply looking for the best way to get my head around it without 
the need to unlearn a whole bunch.

IMO focus should be now on bug-fixing and closing open tickets. There 
is still some smaller things to do on the AGG side. And than get 
a V1.0 out of the door. Because I don't see any cause to not make 
an offical V1 release of R3 anymore. It's mostly ready for prime 
time.

Robert: I presume that your comment that R3 is mostly ready for prime 
time relates to R3 on Windows

after we get those two, most of the framework will be ready for the 
prime-time ...

yes... most applications now are multi-threaded if only to make them 
smoother...  the GUI in one thread, heavy lifting in another, for 
example.


async, doesn't allow you to scale, only to time slice.   you can 
still only compute on a single request at a time.

if the request needs time to finish (rendering, for example), it 
effectively blocks all async and I/O handling.

If you've imported a module and then updated the module and incremented 
the version of it and then call import again this time requesting 
a newer version than has been loaded shouldn't the module be reloaded?

R3 is currently undergoing open-heart surgery, with Carl deep in 
system and architecture mode... with all of the stuff fresh in his 
mind.


I think its the perfect time to overhaul the task! system and finally 
make a real architecture/API and identify,  solve,  or decide on 
the potential issues "hard issues".

I'm not sure it's particularly large. It seems that just interfacing 
is very difficult:


The difficulty is not inherent in the design requirements... it's 
because stdio methods are very old (as old as modern computing) and 
have been messed with (inside the OS) for such a long time.

I don't like issues as words. The advantage of  faster acces to #include, 
that is only used one time at startup or even less when encapping 
does not outweight  that I shall no longer generate large numbers 
of issues, but instead strings or binaries for lists.

after a little bit more work on translating to R3... it seems to 
be much less work than it started out to be   :-D


I've got the basics of my dataflow canvas engine working in R3 (which 
is the basis for GLASS and many other tools of mine).


most of the time spent was in fiddling around with learning the changes 
in R3 view engine itself.   this is a 40kb lib running over another 
50kb lib... and its working as-is (once I removed references to the 
word 'FACE and system/words, mostly).

Optimizing file deletes means first avoiding the standard DELETE 
func. It reads the dir each time which can kill you if you have a 
large dir or, heaven forbid, point it at an FTP location. You can 
build on CLEAR easily though.

    delete-all-files-in-dir: func [dir /local port] [
        port: open dir
        clear port
        close port
    ]


I think my tree deleters all rely on some of my other stuff, like 
FILE-LIST and DO-IN-DIR (now standard as IN-DIR). They generally 
have a callback option as well, so you can track progress.

Now for the other binding stuff:


* SET is a low-level function that would be slowed down immensely 
by adding any refinements.

* SET does handle the unbound scenario: It triggers an error. You 
can then handle the error.

* R2 and R3 get their speed from the direct binding model. The core 
speedup of that model is that SET doesn't bind.


* LOAD in R3 is a high-level mezzanine function. It is meant to be 
as fast as possible given its purpose, but being fast is not its 
main goal; user-level flexibility is. Most of the overhead of LOAD 
is in handling all of its various options, as refinements, file extensions 
and script header settings. If you know what you are doing, you can 
always optimize your code by doing it directly instead of having 
LOAD try to figure out that is what you want to do. LOAD is not meant 
for use in tight loops.


* Henrik, ChristianE, the R3 standard answer to the question of how 
to make BIND TO-WORD "a" more efficient or friendly in R3 is this: 
You are encouraged to not program that way in R3. Converting strings 
to words is something you should do once, not all the time in tight 
loops. Your code will be much more efficient if you work in REBOL 
data rather than storing your code in strings and converting at runtime. 
Strings are for data, or script source, not for containing scripts 
at runtime. This is a good rule for all REBOL versions, but especially 
for R3 with its Unicode strings vs. shared UTF-8 words.


* I have recently refactored LOAD so that it is broken into smaller, 
more efficient functions. You might find that those functions would 
work better for you in lower-level code. But this was done to let 
us make LOAD *more* powerful, not less, so the same advice I gave 
above about not using LOAD in tight loops still applies. I don't 
yet know if the new LOAD is faster or slower, but it is safer and 
easier to understand and modify, and you can make your own LOAD replacement 
that calls the same low-level functions if you like. Plus, you get 
compressed scripts :)

Hi, I corrected http://www.fm.tul.cz/~ladislav/rebol/evaluate.r(I 
omitted a USE-RULE call for the last rule in the script), and renamed 
the accumulator 'a in accordance with industry standards.


Also, I added an efficiency note related to R3 protection disallowing 
us to use a simple binding method to create the USE-RULEs during 
function initialization (creation) instead of creating the USE-RULEs 
every time the respective function is called, which is inefficient.


I wonder, whether we should consider a way how to allow the creator 
of the function to perform some additional initialization during 
function creation.

The initialization has to occur in the function body, unfortunately, 
otherwise the R3 protection does not allow BIND to be used, which, 
on the other hand, means, that the IF call is done every time the 
function is called, which means additional overhead

If we had a list of modules, along with their cost in memory consumption, 
"clutter", and load time, it would be easy to weigh their value.

Again, I'm not necessarily against it, as long as there is a benefit. 
If the benefit is 3ms faster loading and 30K less memory consumption, 
I will probably say that my time is more valuable than that. :-)

3ms would be a startup time improvement of over 10%.

Pekr, most of the time you will not specify the boot level if you 
are doing CGI. The default (unspecified) boot level loads the module 
system and all of the opt-out modules.

Most of the time you won't specify a boot level at all.

All I needed to know in the past is, that for CGI I need fast system, 
which will not load unnecessary code, e.g. help, etc. Hence I used 
/base executable. Now:


base - initialize only the lower levels. This option is for special 
purpose testing only because it provides no way to load external 
code. (No schemes, such as file access, nor load or do functions.) 
If your host-kit build is crashing on startup, you can use this option 
to confirm that the exe image is loadable and runable.


sys - initialize up to and including the basic runtime lib and sys 
contexts. This option allows you to run a very "lean" system (minimal 
memory and boot time) where your code will be supplying all other 
run-time functions and modules. Provides a basic load function but 
with very limited special options (no import, needs, versions, or 
related features.)


mods - initialize up to and including lower-level resident modules. 
In addition to boot-sys, this level adds high-priority resident modules, 
but not mezz plus (higher level mezzanines).

Henrik - I know, that is just why I am surprised by Carl stating, 
that he liked to early prototypes. This just seems to follow the 
Gab's VID scenario - Carl detached from Gab's VID for quite some 
time, then having difficulcy to understand it, then - scrapping it.

yes, that would be a good first clue, since the current docs give 
no indication on how to proceed right now... 


I should have sourced cause-error, and I usually do... but this time 
well... I guess I assumed it was a native  :-)

Maxim, I felt the same back In time. A tool like anamonitor is not 
anymore possible. (cry on my face)

but you cannot resolve the run-time in data. since things are bound 
dynamically.  the name of a func is useless... we need to be able 
to trace it back to its context by getting its value.


this doesn't give us the context, but at least we can see what the 
function really is.

for example, if I want to do a real time debugger which shows me 
the current content of the block which is being stepped through by 
a loop... 

I can't since I can't get access to the block which is being used 
by that function...

Pekr - "if we can't have full fledged debugger, then we are crap 
:-)"

Agreed, though maybe not complete crap.


Brian - "Heck, even good old print statement debugging would work."

Agreed, to an extent.

Brian - "They could even be trace events."


Ahhh, joy. What can we learn from DTrace, and what should modern 
debugging look like? I have, at times, ached for the ability to step-trace 
and set break and watch points in REBOL. At the same time, I don't 
want to be myopic and focus on how we debugged in the past.


What are the best ways to debug the things we're supposed to build 
with REBOL? And can we hope for mechanisms to let us debug things 
outside what RT says REBOL is targeted at?

using replacement function builders we could, in theory, completely 
control how execution occurs.  this would be at some speed cost and 
possibly not 100% transparent.


but setting break points and real-time value watching is definitely 
in the realms of possibility.

Are all the "^M"s below because of datatypes not implemented yet 
or is this a bug? I'd expected READ/STRING to not only TO STRING!, 
but to DELINE the data read.

>> sql: read/string clipboard://
== {create table scans (^M
               id     serial primary key,^M
               date   date not null,^M
               time   time(3) not null,^M
               job    integer not null, ^M
               branch integer, ^M
               ean    char(13) not null,^M
               box    integer^M
          )}

Any comment onto R3 now displaying security dialog each time it starts? 
Do we have some non-standard exe being generated by hostkit? This 
symptome is not happening with A99 IIRC ...

Time will tell.

speaking for myself...  all of my concerns wrt A108 *are* the changes 
in the core wrt how they affect extensions.


The fact that R3 itself is better is cool, but doesn't really allow 
me to test anything if I can't actually compile the host-kit against 
it.


though I know how preparing working releases takes time, so I'm probably 
a bit more patient than Andreas.  ;-)


I will be starting work on my Custom Gob Renderering A107 R3 host-kit 
sometime this week.  

I still have to *complete* the rendering pipeline architecture from 
end to end (even if its currently very shallow), which is about 80% 
done.

most of what is left is the easy part (the actual OpenGL handling 
itself)

No, as I explained above. Core changes take time to propagate to 
the code surrounding it.

And my time is free now. I work on the core, not really the host 
kit much yet. However, I must run an errand. Later :)

And obviously it takes some time for him to disentangle that from 
what is externally released, along with some copy/pasting and what 
not.

Maybe you want to make less bold assertions about the hostkit until 
you actually find time to look into it.

others do both and don't get the time to release  them  ;-)

Just a little tidbit I thought might be good for others still resisting 
the dark side of the force (R3 :-)


I'm at a point where I'm 50:50 in my time spend on R2 and R3 overall. 
which is a nice observation.

ATM, I much prefer R3 for many reasons.

-binding control and dynamic code building is soooo much better.
-embeded modules
-extensions which can (at last) almost do anything with REBOL.

-being able to fix/understand some limitations myself by "looking 
under the hood".

-it really is much better designed, scalable, fast, consistent and 
more.

why is R3 the dark-side?
-it constantly tempts you, 

-promises power (which it ultimately delivers, after kicking you 
in the nuts a few times), 

-allows much easier access to evil dlls (dark lawless libraries) 
than R2, 

-can be a lot more harsh finding your errors, but then removes guilt 
by disarming them 
-some unexpected issues still make it highly temperamental. 
-it will actually KILL your app with mush less discrimination 

-DOS shell makes it a trial by pain experience (and no, making its 
bg color white doesn't changes this ;-)

maybe you should use color next time ... e.g. pink one - in love 
:-)

Pekr, Andreas, ChristianE and anyon who is interested...I published 
win console R3core version that should show correctly ut8 characters. 
IF you can try to dsiplay your native language chars just download 
it from here: http://cyphre.mysteria.cz/tests/r3-core-a107-console.zip
and let me know if it works for you.

Note that this version doesn't work well with STDIN/OUT redirection 
yet. I didn't want to waste time on this part yet until the normal 
console STDIN/OUT works well.

Divergence:  too obscure  a word  time to get the thesaurus... ;-)

waste? [ of time ]

Just added this note to #1722: "Note: This ticket is not a dup of 
#1177. We made the same error again with a new module system. We 
have a better solution this time though."

For one thing, renaming something already imported is an error. And 
a lot of the time IMPORT is just giving you access to stuff you already 
imported earlier with Needs.

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

if that switch exists, people spending way more time on this haven't 
found it :)

Pekr, Andreas is right. The problem is that the 'flag' if the app 
is of Console or GUI type is set at compile time. So when you execute 
file th Windows kernel just checks that flag and if set to 'Console' 
immediately creates console *before* the main() of your programm 
is called. So even if you put: ShowWindow(console, SW_HIDE); as the 
first command in your app you'll always see the console window for 
a while, which is not so nice ;)

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

Actually what is stopping me from using REBOL3 is the lack of GUI 
and SQLite support but I have them in REBOL2 and I'll continue using 
it.

In REBOL3 I am only a spectator. I do not complain on the time it 
gets to be complete. I do not need the very last feature. I am passionate 
about the work you are doing on it. It is very hard.  It is nice 
to see you, genius, at work.

Petr, Java the language has lost a lot of its shine, though you'd 
be surprised how widespread it still is in lots of companies. The 
thing is that the JVM is still a great platform to target and there 
are languages like Clojure and Scala which compile to this VM and 
their rapidly rising popularity will keep the JVM around for a long 
time to come. Remember, by riding on the JVM you instantly cover 
a whole bunch of platforms at once.

Nope, right the first time.

Empty vars or values blocks, like all of the other assignment-related 
characteristics of LET, serves the same purpose that they do in SET. 
Remember, a lot of the time LET will be used on data, not just inline 
words and values. Sometimes you want to screen for #[unset!], because 
being screened for is the whole point to that datatype, so setting 
it should be an option like it is with SET. Other times the words 
will be collected from the body, such as with COLLECT-WORDS/set. 
It is not necessarily an error if there are no words - it depends 
on the programmer's intention.

About the annoyance, that is a side effect of two things combined:

- Starting with R2 we got direct binding, rather than dynamic binding, 
for a 30X speedup IIRC.

- Starting with R3 we got stack-relative contexts for functions, 
for security, task safety and better recursion safety.


You can't have the words in functions lose their bindings once the 
function returns because they will need those bindings the next time 
the function is called, and you can't rebind because definitional 
binding depends on the order of binding operations. So instead the 
context becomes invalid. It's an annoyance, sure, but it is more 
of an understandable side effect of some *extremely* useful features.

My timing tests were flawed.....R3-rehash is __significantly__ faster 
than R2 native hash.


That is still true even if we remove the set-up time and just look 
at random retrieval.

{Of course that is based on my random dataset....your's may vary]