AltME groups: search

One thing I'm torn on when it comes to VMs is if I need to write 
my own at all. I know I will have to write a Bootstrapping language 
as an intermediary, but I'm thinking it might be a waste of time 
when LLVM has such aggressive optimization for compilation and also 
supports JIT - both of which I'd have to write myself otherwise.

Ok, IMO it just needs to be made more clear. I'm confusig it after 
not tracking this here for a time. Just make things as simple as 
possible.

But I'm not 100% confident that my changes cover all possible use-cases, 
so I'll delay the 0.2.6 release until tomorrow night to give us time 
to test it better.

I'll willingly help with the doc strings but am a bit short for time 
this week.

Time to try again, I guess :)

No side projects? Well, we will have to keep you alive via some donation 
from time to time then :-)

I have a short-term customer project, but it's a week or so of work 
and I can work part-time on it.


I also have another webapp (cheyenne-based) project that I work on 
from time to time, I'll publish it when it will be fully functional, 
I'm pretty sure you'll like it. Currently only Kaj knows what it 
is about, as I started it last time I've visited him. ;-)

Brian: thanks for the input. 


Oldes: I think this has been discussed in same channel on Rebol3 
world long time ago. Basically, the problem is that it  breaks REBOL's 
syntactic rules (digits as first characters of a word are not allowed). 
Also, this kind of syntax looks cryptic, it's IMHO, and goes a bit 
in opposite direction of what REBOL wants to promote (readable syntax).


Maybe we can do some implicit casting when a float literal is passed 
as argument to a function expecting a float32!.

You need to checkout the branch in a new local folder if you want 
to have several branches of code at the same time (I never had that 
need as switching between them is done in a couple of seconds).

You can't mix things if you use a Git client and do a Switch/checkout 
each time...

I know sysinternals tools for quite some time. Just checked, no failure 
reports ....

Easly creating self-contained DLLs with a R2 / R3 interface would 
be a major time-saver.

Gregg: thanks for taking the time to test it. I think it won't be 
needed for XP x64 as we know it works on XP 32-bit and W7 x64 already.

(I'm pretty sure it was working last time I've tested shared-lib.reds 
script)

Robert - it is just that talking to Cyphre, he was eventually interested 
in a "port", which would be more of a new implementation, supporting 
more advanced stuff in the backend (as switching targets, hw acceleration, 
etc.), and doing it in his free time the initial guess was 12 months. 
Such product would be surely cool, but it seems to me, that it could 
be just the second stage. 


In first stage, I would prefer having windowing/events plus AGG ported 
(still fast enough for many things, I don't understand the obsession 
about the speec, well, apart from devices lacking float support, 
here, AGG would be really slow). Such step could be done in 2-3 months 
of work? Then ppl could start port R3 GUI to it ....

Doc, pardon me because I don't know what the intended datatype model 
is for Red. Something like the REBOL datatype/action model could 
be used to implement the different underlying string encodings that 
you want in-memory support for. Each supported encoding would have 
its own set of action handlers, which would all have the same external 
interface. Swapping the encoding would be as simple as swapping the 
handler set. Resolving the difference at compile time could be similar 
to generic type instantiation, or C++ template generation.

I got math ops for integers working, but I think it's time we get 
a better macro system.

So time really is running out for REBOL

I like the new macro system, too. I've wanted that for a long time 
(in silence :-)

Thanks Kaj, now you can see how all pieces start fitting together. 
Say hello to Peter for me, tell him, I'm sorry we still don't support 
FreeBSD, but I'm looking forward to fix that next time I'll meet 
with him. ;-)

# rebol -qw red.r %red/tests/hello.red

-= Red Compiler =- 
Compiling red/tests/hello.red ...

...compilation time: 	 30 ms

Compiling to native code... 

...compilation time: 	 1282 ms
...linking time: 	 	 25 ms
...output file size: 	 	30912 bytes

# ./hello
42

For those who are excited about what Doc is doing, please remember 
to continue donating.  He's devoting all his time and work to Red 
at this point.

Has anyone here worked with OAuth and/or the etzy.com API in REBOL? 
 I'm currently looking through Christopher Ross-Gill's OAuth implementation 
for Twitter, and interested in writing a REBOL app using the etzy.com 
API.  I understand most of it, but don't get the "oauth_signature" 
spec.  Don't have much time for this, so would like to offer some 
$$$ for anyone able to instruct and or provide help implementing 
the etsy API.  Email reverse "g r o  tod  z r a t i u g  ta  codmorf"

sysconf:I guess it's the right time to add it.

Will see that tomorrow, bed time here...

I'm not coordinating with Nick yet, but will when the time comes.

Finally got around to cloning Red from github and doing the test 
system and Red compiles. I hadn't done so since changing machines, 
so it's great to have it all work the first time out. Great stuff 
Doc.

Branches: no, they are volatile, and I certainly don't want to have 
to thing about updating them on the web site each time I add/remove 
one...

Then create some howto's and in time change from REBOL driven site 
to Red driven site.

Hmm, now I might see, what others mean - the Github link is not apparent 
anywhere on the site. Maybe once you find some free time (hardly 
nowadays), here's what I suggest:

- add Downloads link to the top menu

- add just one sentence - you can download .zip archives of particular 
branches from link-to-github ...

That's might help some users ....

Well, not coming from C kind of languages, I actually used code inclusion 
rarely. The preprocessing stuff in any language looks arcane to me, 
but that's just my feeling, as it is REALLY a long time ago, since 
I used code -> compile -> link technique (CA-Clipper - 1998 :-)


So I better wait for more "clean" way - the other method you described 
- simply what I am expecting is kind of Rebcode - writing any function 
in Red, using Red/System or C or ASM, whatever :-) But most probably 
I am confusing and create a mishmatch even in such case :-)

I've been very busy since yesterday on a new tool for Red: I've built 
a proper REBOL code profiler! (I wonder why I haven't done that since 
a long time...). I went through the profiler scripts on rebol.org 
and couldn't one suitable for my needs or that works with complex 
code, so I wrote one. It is able to deal with complex code, all datatypes, 
recursive calls and it's very simple to use.


Here's a demo profiling Red compiler (output is properly aligned 
when monospace font is used):

-= Red Compiler =-
Compiling red/tests/test.red ...

...compilation time:     40 ms

Compiling to native code...

...compilation time:     10189 ms
...linking time:         60 ms
...output file size:     37888 bytes
>> profiler/report/time


Function                       Count      Elapsed Time         % 
of ET

------------------------------------------------------------------------

compile                        1          0:00:10.249          100.0

comp-dialect                   205        0:00:09.659          94.24

fetch-expression               7505       0:00:09.628          93.94

comp-word                      5668       0:00:08.209          80.09

fetch-into                     427        0:00:07.519          73.36

comp-assignment                597        0:00:07.049          68.77

run                            3          0:00:06.492          63.34

comp-context                   21         0:00:06.398          62.42

comp-with                      1          0:00:05.565          54.29

comp-expression                3172       0:00:04.479          43.70

ns-find-with                   24277      0:00:03.962          38.65

finalize                       1          0:00:03.327          32.46

comp-natives                   1          0:00:03.274          31.94

comp-func-body                 180        0:00:03.271          31.91

comp-call                      2775       0:00:02.732          26.65

comp-func-args                 2861       0:00:01.862          18.16

find-aliased                   9650       0:00:01.86           18.14

resolve-type                   8032       0:00:01.799          17.55

get-type                       10758      0:00:01.546          15.08

ns-prefix                      21765      0:00:01.518          14.81

check-enum-symbol              7509       0:00:01.241          12.10

comp-block                     283        0:00:01.05           10.24

comp-variable-assign           417        0:00:01.034          10.08

The overhead of the current implementation is about 5-6 times the 
program execution time, so it's very usable. I will publish it today, 
and I hope someone will pick it up to improve it and add features 
(like a GUI front-end for the reports, with sortable columns).

BTW, as I was thinking, the above compiler profiling confirms that 
aliases and namespaces support are quite costly currently (ns-* functions). 
So now I know where to improve the code for better performances (not 
that it matters for the users currently, but it matters to me as 
I need to run the whole test suite dozens of time each day, and with 
the addition of now Red compiler, it (and will) adds up to a lot 
of waiting time at the end of the day).

Nothing in particular, I will implement it the same way as in REBOL. 
If you have suggestion about improvements, it's still time.

About error, maybe some indication of the line number. Not prominent 
but as a hint at least, however using find most of the time finds 
the right place where the error is, sometimes it is not so clear.

Ah, there's maybe something that you could do: I need to port my 
current Red test script in Quick-Test (QT) form. I can send you the 
script (very very simple) and the expected unit tests format used 
by QT, you would just have to convert it and check if all tests are 
reported as passing in QT...it's not a big task, but you will save 
me some time for advancing on the code. Interested?

Graham: I was thinking it could be ready for end of year of beginning 
of next year. Currently Red is not for end users, and won't be for 
a while. Red/System could be used in production though, but I don't 
have time to write users docs or tutorials for it.

Well, I think that I will be a nice guy for quite some time, not 
trying to steal the happiness of guys out there :-)

So let me just say what I am thinking.. I wonder if R3 would be released 
already if you weren't making so much progress with Red..  I hope 
2 (or more) options will be able to bring even more people into Rebol 
family of languages. The time is about to be right. Python is getting 
sort of backlash (finally).

I agree with you about the runtime choice. I wish Gabriele had more 
time to work on Topaz.

... but - it is a long time I tried it, so not sure ...

We certainly have better ways to spend your time than debugging SQLite 
internals, so keeping the same SQLite codebase subset seems the right 
thing to do.

Yes, it would really help to more easily backup at the file level 
- not just one monstrous file each time, but certain tables ...

Kaj - last I checked it was long time ago. It did not use SQL syntax, 
and was not even free IIRC. But I don't follow mySQL for many years 
now ...

Just give it time

Most probably the binding was not tested for quite some time, and 
Red + Red/System evolves, so there might be some regression there. 
Better wait for experts, though ...

There is little opportunity for being out of sync, as I tested them 
all the time

Wow! the Mandelbrot is fast - elapsed time 0, process time 0.22

Rebol 2 elapsed time: 17.473 seconds - yawn!

Sorry - I tell a lie - that last elapsed time for R2 was for the 
fib - the mandelbrot is 4.436 seconds - still very slow comapared 
to Red/System - this is cool!

Elapsed time for fib on Reds is 0, process time is 0.103 - so fib 
is hundreds of times faster on Reds compared to R2 - so I guess it 
depends on the program as to the speed difference

mirror is MUCH more fun now that the numbers on the edge react in 
real time.... really makes it one big step more playable.

its also much more obvious what the game is about.

Having the 3 layers on top of each other was a nice REBOL feature 
saving a little time redrawing the grid and other mirrors as was 
necessary in Java (well I am not an experienced Java programmer, 
so it was necessary for me to solve it like that)

That prediction was correct. Now diving in to find what was already 
loaded when building this, just like last time. Hang in there!

Have you checked the new version yet? Learning a lot of new stuff 
about VID, getting more code out right the first time, etc.

Ehm, sorry, I don't have time

It would only be R3. Spending time on opening R2 would probably cost 
Carl too much money on legal expenses.

Max, yes, docs for VID (beyond the basics) have always been lacking. 
It took me a long time to find OF for grouping as well. Part of the 
issue is the design of VID itself, where you need to know internals, 
and there isn't a documented public interface for styles.

Endo, preferences should be preferences not just last time settings 
imho those could be some quick test experiments. But preferences, 
indeed preferences is what I missed while testing this bugger. Prefs 
filename something like app-name.preferences.ini? When prefenced 
start dir is set via preferences probably the rsc.r script will always 
be found? But testing for existance is more robust, so I agree definitely. 
Maybe in time there will be a completely different way to compile 
Red or other changes needed to keep this script actual and useable, 
so I invite everyone interested to feel free to add and sculpt this 
script!

The main issue I have with this script is this. My script did not 
compile. I used 'now in my script to time a kind of loop foreach 
versus forall and this failed. The control was not passed back to 
my script, I just compiled hello.reds script and this was successful 
and my script got the focus again. So that is nice but with unsuccessfull 
build it woul be nice to gather results and maybe restart compiling 
with different setting (for verbose for example). I have no idea 
how to do this.

Pekr, look for Oldes' UTF8 package for Rebol 2, I believe it's on 
rebol.org, it can convert anything (it supports downloading code 
pages from net) to/from UTF8, I really saved me lot of time when 
I was working on translations for Windows Vista.

If the number of texts doesn't vary, it might be simpler to make 
the fields manually instead of using an iterated face. The reason 
for this is that you need to write the SUPPLY code yourself, which 
will run every time you run the code and will run on every mouse 
move, if your text has a FEEL object with ENGAGE, OVER or DETECT 
functions, whereas simply making 8 texts once with VID is both faster 
and requires less code.

Oh small mistake, no need to COPY each time: this is much better:

f: func [b /local c r n1 n2] [r: copy [] foreach v unique b: copy 
b [n1: length? b remove-each w b [v = w] n2: length? b append r reduce 
[v n1 - n2] ] r ]

that is a massively interesting mail from Joel Neely.  


He is one of the old-time rebolers I miss most.  He has a very good 
sense of how to explain his points.

Aha, I checked and Joel's code actually *is* using SORT, which means 
it is O(n * log n) algorithm. While, at the same time, the above 
REMOVE-EACH is O(n * n), which is *much* slower as far as I am concerned.

you can make it a bit smoother than that by wrapping the whole thing 
in a panel and assigning a new face tree to that panel every time. 
Then you won't need to close and reopen the window.

the mod has been so heavily modified, its almost a complete rewrite. 
 its also heavily embeded within our production environement (libs 
and stuff) so that making it a stand-alone mod again will take some 
time... some time which currently, I don't have.  though note that 
we didin't actually add json support but greatly increased the flexibility 
of the i/o format conversion.

like I said , right now I can't rip it out easily because a lot of 
the code is shared with the code it serves (which is not part of 
the open source package).   It wasn't built with the task of making 
it independent... but it can be done.  It just takes time, which 
I currently don't have.

In my previous example b/data had a value none in stead of false 
and I could have two radioselections selected at the same time.

isn't that sort of time-critical?

I think Henrik means that you can get bitten by REBOL hanging for 
short periods of time in the garbage collector

Hi looking for a better REBOL way to do the next thing: a: [ 1 2 
3 4 5 6 ] I have 1 of the values in this series and  want to do a 
foreach/forall on the series left of this value from right to left 
and also a foreach on the series on the right of this value but now 
from left to right. So say I chose 3 for the value then I need [ 
2 1 ] and [ 4 5 6 7 ]. This is my solution b: reverse copy/part a 
find a 3 and c: reverse copy/part a find reverse a 3 but now >> a
== [6 5 4 3 2 1]

And I don't want that and I don't like undoing the reverse each time. 
Do I need a temp for reverse a because c: reverse copy/part a find/last 
reverse copy a 3
** Script Error: Invalid /part count: 3 2 1
?

Steeve, I like it. Most of the time I prefer readability over speed. 
This time a little speeding things up comes in handy.

IIRC in all the tests I did, the binding overhead is dwarfed by all 
other considerations. 


a single execution of the block is usually longer than the binding 
process (which is slow, but rebol execution is slower still ;-) . 
 


forskip is by far the slowest loop in R2.  it was several orders 
of magnitude slower than foreach.  and much slower than an until 
block ... not worth it..   I'm happy its native in R3.


obviously, the time spent within the block with relativise the time 
spent in the iteration handling.

Time-out! :D

I have enough information to make my script working with reasonable 
speed. After I publish it on rebol.org we can write out a competition 
to have it gain speed ;)

Here is the benchmark results (execution time for 1.000.000 calls)


>> benchmark [rle [a a a b b c A A a a]] ;BrianH (the old one, not 
the crashing ones)
== 0:00:29.765

>> benchmark [rle [a a a b b c A A a a]] ;endo
== 0:00:32.953

providing an optional output buffer  (which the user can pre-allocate 
to some ideal size)  would make a VERY big difference on large inputs.


usually, when it goes into the hundreds of thousands, repetitive 
series re-allocation on growing mutable series,  will kill any kind 
of optimisation you can dream of. 


rle: func [s [series!]   /into out  [block!]  /local out emit pos1 
pos2 cont][
	out: any [ out     make block! 2 ]
 ...
]


this is especially effective on repetitive calls to the above function 
and using clear on the given buffer so that it auto-grows to an optimal 
size and is fast on later calls.


just today, I was doing some encryption benchmarking and when I hit 
strings larger than 1MB it was taking several minutes... thats until 
I realized that it was my dataset generator (a looped string insert) 
which was taking 98% of the cpu time.  !

But I didn't use parse at that time

Arnold, 'stack is local to the function.  Ordinarily you would make 
a copy each time the function is called so that you have an empty 
new block.  But here the function does not so that the block contents 
are available unchanged between calls.

this is not subject to GC?

 - Such a function looks like a subject to GC, but you need to find 
 out *when*.


- in R2 it is a subject to GC right after the button is pressed and 
released

- in R3 the function *may* persist after the button is pressed for 
the first time and *before* it is pressed for the second time

have you written a paper on GC in Rebol ?

 - the reason why the function persists between presses in R2 is based 
 on the fact that USE modifies its argument block "leaving" the local 
 variable in it. (it is described in Bindology). In R3 USE is a closure 
 written in REBOL, that is why there may be some "persistence" until 
 the USE function is called next time

GrahamC, It was simpler than that. The program I am working on has 
over 1300 lines of code, and I mis-typed a variable name! So it turns 
out I was trying to access a word that did not exist, was not defined. 
I'll remember that for next time. (Yes, there will be a next time). 
Thanks for all the help. I am beginning to feel competent programming 
in Rebol2.

Thank you, this works! I found and old conversation on ALTME this 
afternoon but that could not convince me being the answer, this answer 
will replace the old one. (I even typed get_env the first time). 
And for completeness I will write how to use it (cut and paste code) 
requestedurl: get-env "REQUEST_URI"

That was a long time ago, and it should say "Feature not available 
in this REBOL"

to allow full (run-time) extensibility of R3 as it is, it needs two 
other apis:
-a decent event registration mechanism (add new types and specs)

-a device registration system (so we can link schemes and protocols 
to them).

I must admit that if you can receive events in the host, you can 
just execute a code string within the root ( just like if one enters 
a command in the prompt).   It worked very well for interfacing with 
GLUT ... I had just built a little pseudo event system which I called 
from within the glut callback and it was fast enough to handle all 
events in real-time.

Haven't had time to try the above yet. It would be interesting to 
see more complex examples of parsing. No need to write it here, only 
if you can redirect me to any existing code online. The examples 
I have found seems simple, but maybe there are things implicated 
in those examples that I don't grasp ...

Gregg, yes. Ladislav, I'll check that also. The example Maxim gave 
was more what I was looking for, I think. Haven't had time to test 
it yet. Thanks for the help..

When AltME was introduces a decade ago, many communication systems 
were unencrypted, so it was good then. Like Lotus Notes at the time

does anyone have time to sanity check / comment on the style of the 
following script: http://0branch.com/highlight/snippets/rfunc.r?

Not really fair, you redefine the throw word and expect it to work 
as is ?

Your function got the same problem on my pc, except it occurs at 
the execution time.
** Script Error: Cannot use path on integer! value
** Where: tail-call
** Near: throw/name none 'tail-cal
or maybe you have a new version right now

(Actually I have problems with Altme to synchronize with some recent 
posts I can't see all of them currenly)

Ladislav: would you be interested in improving the 'proxify function 
from the REBOL profiler I've built for Red project, it has the same 
kind of constraints as 'tail-call? The current code is a bit "rough", 
I don't have time to make a cleaner and simpler version of it.


See code at: https://github.com/dockimbel/Red/blob/v0.3.0/red-system/utils/profiler.r

About the #[function!] vs func equivalence.

It's not. The first one is a singleton, meaning only one version 
exists in memory (not recreated each time)

This time it's really really my final version T_T
- Both f/recur and recur allowed
- Catch/throw interferences ok.

NB: The code would be simpler in R3 since several workarounds are 
used to correct misbehaviors of object related natives of R2.

Also the lack of the reflexive capability for a function to read 
its own context in a easy way is definitivly a huge miss.

(On can't create anonymous functions without analysing their specs 
first. What a pain)

One would need a reserved word holding the context (like SELF for 
objects).

These shortcomings are making the code too much obfuscated and huge 
for my taste.
I hope it will be corrected in R3..

rfunc: func [
    [catch] spec [block!] body [block!] 
    /local ctx args call-tail
][
    ctx: bind? first second throw-on-error [
        func spec: append copy spec /recur [recur]
    ]
    args: bind head remove back tail to-block form first ctx ctx
    call-tail: func ['word] compose/deep [
        set/any [(args)] second bind? word 
        throw/name (ctx) 'recur
    ]
    ctx/recur: func spec reduce [:call-tail 'recur]
    func spec reduce [
        quote #[function! [
            [throw] 'recur 'call-tail ctx args body /local ret
        ][
            if get/any recur [call-tail :recur]
            set recur get in ctx 'recur
            while [true][
                set/any 'ret catch/name [return do body] 'recur
                unless all [value? 'ret same? :ret ctx][
                    throw/name get/any 'ret 'recur
                ]
                set/any args second ctx
            ]
        ]]
        'recur :call-tail ctx args body
    ]
]

Depends on how much time it took you to do it.

No, we haven't had time to make emulator images for 0.6.7 yet. The 
Enlightenment port isn't published in binary yet, but you could compile 
it with the Syllable build system

Be aware that we're not fond of serving anything. We've always made 
a lot of effort to keep our downloads as small and clean as possible. 
We welcome contributions, but we also like them to contribute their 
own hosting. Otherwise, it takes more of our time than it saves

no, the second time around, I put the cd on the second controller

We're hosting on Amazon S3 and several other places. I appreciate 
the Box.net offer, but it would just complicate our infrastructure 
further. A lot of our time over the years has gone to managing that, 
so I am firm on simplifying things