AltME groups: search

It's true, though, that process-time is currently a primitive function

Seems like a fairly sound timing, then

There's a lot of variation in the results for such a long loop, so 
it does point to timer instability

Yes, it's a good point

That's stable scheduler timing. Problem solved, I guess, but not 
a good verdict for Windows

There could still be a performance issue on Windows

I had a quick look at the code paths of both generated `square-osc` 
and `sin-osc` functions, all seems fine. But I do concurr that the 
results are not intuitive. I guess that the relative performances 
in such case are just too hardware-dependent.

I guess I should have added a few more unit tests from those tickets.

For people wondering what I was working on these last couple of month, 
here's a screenshot of the customer app I'm finishing now: http://sidl.fr/tmp/generator01.png


It's a visual editor for trading strategies that emits MQL4 code 
for Metatrader-based solutions (FOREX trading). The tree is editable 
and redraws itself automatically (no need to drag all the nodes around 
manually). This app also relies on an intermediary DSL for serializing 
the strategy on disk or before compiling it to MQL4. Here's an extract 
from the corresponding dialect representation of the tree from screenshot: 

start on 1 
if 1 buy 5 take 10 stop 10 on-profit [
    buy 6 take 10 stop 10 on-profit [
        buy 10 take 10 stop 10 loop
    ]
] on-loss [
    sell 7 take 10 stop 10 on-profit [
        buy 4 take 10 stop 10 loop
    ]
] 


All is done in REBOL/View 2.7.6 (to avoid CALL bug in 2.7.8) and 
all the source code is 47KB (25KB for the custom styles and VID events 
callbacks).


I'm at 99% completion of that app, so I've resume the work on Red 
since a couple of days.

I chosed VID only because I knew I could do it faster than messing 
around with HTML/JS libs and intricacies. I was just a bit concerned 
about hitting some performance walls or native bugs I couldn't workaround. 
Fortunately, all went well.

I don't know. Please don't be bogged down by things like gui in Red 
too fast! You first have to make a langauge / a platform that others 
(we) can use and build upon and add libs when we need them. And for 
all the love to VID and like, my oppinion is still that usability 
matters the most and it's hard to beat usability (all the little 
conventions) with non-native GUI-s. Or big delevoloped libraries 
that emaulate them well enough (Qt, GTK, ...)

I've pushed the enhanced get-word syntax support, so it's now possible 
to get a pointer on integer!, byte!, float! and float32! variables 
(without having to wrap them in a struct!). For example:

	s: declare int-ptr!
	a: 123
	s: :a
	print s/value		;-- will output 123


I will add the ARM backend support for that and update the documentation 
tonight.

Vid frees you from the browser and its limitations. If REBOL only 
had a HTML interface I would have dropped the language without further 
hesitation.

Ok, but Rebol is better than html5. You write your script and it 
works on MacOS, Windows, Linux, in a browser. "write once and use 
it every where" better than Java.

of course, better than JAVA. But generally it does not work in a 
browser - you still need a plugin for each platform. Don't forget 
mobile devices, etc. But - that is a bit offtopic here in a RED group

We shouldn't forget the idea of ReBrowse, which is Carl's idea of 
a browser written in R3 and is mean to replace the Viewtop. It's 
true that it doesn't run inside other browsers or leverages HTML, 
but it will still be a great technology demonstration of what a webbrowser 
should be.

yes, and it would be cool to run rebrowser in real browser. Remember 
- making a NS plugin is wrapping something like 20 function calls? 
Not a problem for C skilled coder. I am even willing to start a bounty 
for that :-) But - first things first - R3 has to have a future first, 
so waiting for Carl's next step ...

I have personally entirely different ideas for using Red as a basis 
for a new kind of desktop, but I'm not sure if I'm skilled enough 
to build it. We'll see.

#221 is about keeping the x87 FPU stack clean in case of a nested 
`either` expression.

I know nothing about RED, so, would anyoe be so kind to tell me in 
a nut shell where it stands?

Very cool.

So, is there a guess when it will "run" most of the scripts in the 
REBOL public library?

Yeah, Red seems to have the greatest momentum right now. It will 
be very interesting in a few months, hopefully.

I found the cause of this new FPU stack leaking (x87 stack has 7 
slots) and fixed it (it was a regression).

Wonderful! My test now runs without a problem. Time to try something 
more complicated :)

Hi Doc and everybody, since I'm studying the opportunity to create 
myself - in a loooong future - a test  version of Red/system running 
over the JVM - I asked myself, after reading some doc titled "Create 
ypour own programming language" by Marc-Andre Cournoyer, if in any 
case Doc had thought about this way of doing things for his future 
implementation of Red (not Red/system), as described by this excerpt 
from the doc itself under the section :  PROTOTYPE-BASED

Except for Javascript, no Prototype-based languages have reached 
widespread

popularity yet. This model is the easiest one to implement and also 
the most
flexible because everything is a clone of an object.

Ian Piumarta describes how to design an Open, Extensible Object Model 
that
allows the language’s users to modify its behavior at runtime.

Look at the appendix at the end of this book for a sample prototype-based

language: Appendix: Mio, a minimalist homoiconic language. For a 
follow-up about these concerns here is the URL related to the Extensible 
Object Model upon which the author has based his own Mio language, 
itself inspired by the IO language  -  http://piumarta.com/software/cola/objmodel2.pdf

Hi Doc, I didn't express correctly in my last post and you missed 
the point - I already know that Red will be prototype-based but the 
question is : will the object model implementation you'll use be 
flexible enough to permit you and/or the end-user  to easily extend 
  Red with other  new types, or change primitive functionality and 
semantics at some later time. The author of this article has done 
some studies and experiments about this fact and within his 16 pages, 
he explains how it could circumvent these possible limitations without 
sacrificing efficiency - even if I'm not advanced enough to take 
his word as truth per se. I thought it would be useful to you to 
see such writing before you committed to much material, based on 
your current architecture and internal implementation details - about 
which I don't know anything, I must confess. Sorry if this is more 
of an annoyance than a useful tip but I thought it could be useful 
as a reading to anyone interested in implementing some programming 
language - be it not fully Red related.

BTW, yesterday I've encountered a strange bug that's very hard to 
separate. The bug is that EITHER will always execute FALSE block, 
even if the condition is TRUE (EITHER is in function and the function 
is in WHILE loop, but that's not enough to trigger the bug). When 
I try to separate the problem the bug is gone. When I leave the function 
as is and just remove all unrelated stuff, the bug is also gone. 
It happens only when I compile my whole project. When I have more 
time, I will once again try to separate the problem and when unsuccesful, 
I will post the project as is for you to check it.

@Gerard: 


Red will allow to extend itself in several ways. New types could 
be added easily by defining a set of new action! functions associated 
with a new datatype!. Also, the language syntax and semantics themselves 
could be changed by using the internal compiler API (not sure I will 
implement that in the bootstrapped version to avoid compatibility 
issues with the final compiler version).

I am also look forward to the first version of Red. And I am willing 
to rewrite my REBOL book into a Red Book.

Doc, have a look at http://box.lebeda.ws/~rebolek/sintezar.zip

Compile file %sintezar.reds and see function ADSR in %env.reds. Even 
when I pass TRUE, EITHER always executes FALSE block. I tried to 
simplify it, but I wasn't succesfull, so it's bit bigger project 
than just few lines, sorry :)

Looks interesting. I can see how you're finding those expression 
bugs. :-) This is a really nice example of how Red/System can replace 
C

I've just pushed a fix for your issue. I know correctly get the TRUE 
block being executed when it should.

Red: I'm still working on both the compiler and the minimal runtime 
required to run simple Red programs. I have only the very basic datatypes 
working for now, no objects (so no ports) yet. I not yet at the point 
where I can give an accurate ETA for the first alpha, but I hope 
to be able to provide that ETA in a week.


Red string! datatype will support Unicode (UTF-8 and UTF-16 encoding 
internally). I haven't implemented Unicode yet, so if some of you 
are willing to provide efficient code for supporting Unicode, that 
would greatly speedup Red progress. 

The following functions would be needed (coded in Red/System):

- UTF-8 <=> UTF-16 LE conversion routines

- (by order of importance) length?, compare (two strings), compare-case, 
pick, poke, at, find, find-case
- optinally: uppercase, lowercase, sort


All the above functions should be coded both for UTF-8 and UTF-16 
LE.

Please take some time to give good thought about this kind of things 
and specifying in more detail what is needed, so other people get 
a chance to help out with doing a little programming for Red (/system). 
While not everybody is a topgun like yourself, there is a lot of 
legwork that could be taken out of your hands.

In case, you wonder why Red needs both UTF formats, well, it's simple, 
 Windows and UNIX worlds use different encodings, so we need to support 
both. Red will use by default UTF-8 for string values, but on Windows 
platform, it will convert the string to UTF-16 on first call to an 
OS API, and will keep that encoding later on (and avoid the overhead 
of converting it each time). 


We might want to make the UTF-16 related code platform-depend and 
not include it for other platforms, but I think that some text processing 
algorithms might benefit from a fixed-size encoding, so for now, 
I'm for including both encoding for all targets.


It will be also possible for users to check and change the encoding 
of a Red string! value at runtime.

Keep in mind that even UTF-16 is not a fixed-size encoding. Each 
codepoint either takes 2 or 4 bytes.

UTF-32 (aka UCS4) is a fixed-size encoding. It's rarely used though.

For example: 
    a: context [c: 123 d: b/e]
    b: context [e: 456  f: a/c]

cannot be compiled currently.

Will it be possible to put #import's in a context?

Will there be something like USE or BIND to compile code referencing 
a particular context?

Is it/would it be possible to pass context as an argument to a function?

<from !Cheyenne group>


I'll have a look emitting the executable in the working directory 
this afternoon.

In Syllable, I repackage Red and Cheyenne in a package with a Unix-like 
structure, such as a separate subdirectory for the executable, but 
it gets cluttered because they find all their other files related 
to that executable. Actually, that's the way we want it to work for 
Syllable Desktop GUI applications, but for a console program that 
needs to be in the system path, you need the Unix structure with 
separate search paths for separate subdirectories

FEAT: added new WITH keyword for locally specifying implicit namespaces.

Usage: with <ns> [<body>]

    <ns>    : one or several block-enclosed namespace(s)

    <body> : code to execute within one or several implicit namespace

Example: 

    a: context [b: 123]
    with a [print b]

So WITH would be like DO IN a [...] in R3.

first context has the highest priority

: the nearest nested WITH has the higher priority (implemented but 
not tested yet).


Also, when specifying a block of namespaces, the first one in the 
list has priority other the next one, and so on.

I was disappointed when that was rejected. I have a VM where I need 
to bind to dynamic stacks of contexts

the IN block! block! is a must have at least. It's a pain in the 
ass to have to rebind the same block several times.
Kaj, I also worked on VMs and it was a shame.

IN block word is used in the R3 GUI. It does the same context walk 
that Doc says WITH does, but only to retrieve a word.

What we need is to be able to rebind a block of code into several 
context in one time

Yes, I wondered how a language for constructing languages could make 
this omission

is: func [
		[catch]
		{Current face inherits from a block!}
		spec [block!]
		/local locals old when init
	][
		either all [
			find spec set-word!	; locals founds
			not empty? exclude  ; new ones (not found in the current face)

    first locals: construct copy spec ; copy: because [construct] modifies 
    the block (R2 bug ?)
				first face
		][

   ; Would be simpler, faster and safer using R3 (objects can be expanded)
			; rebuild face with new locals 

   ; (make face spec : can't be used here because of the special bounding 
   rules)

   when: face/when					; prevent copy/deep of when and init blocks
			init: face/init
			face/when: face/init: none
			set locals none

   resolve* locals face			; initialize locals with current face (if 
   intersect)

   face: make old: face locals		; rebuild current face with new locals
			face/when: when
			face/init: init
			do-safe bind bind spec face self; run style constructor 

   bind bind init face self		; rebound current face constructor (which 
   is currently running)

   error? set old :bound-err		; prevent old object from being used anymore
			old: none
		][
			; no new locals

   do-safe bind bind spec face self		; just run style's constructor 
		]
		if error throw-exit
	]

Brian, there was a blog about having RESOLVE, I think, walking a 
list of contexts, but Carl eventually decided that it wasn't needed 
"due to R3's new binding capablities"

Probably. I'm having trouble imagining a use for RESOLVE doing that.

Maybe it could be used for some kind of multiple-prototyping of objects. 
Something like this:

>> resolve/extend context [] reduce [context [a: 1] context [a: 2 
b: 3]]
== make object! [
    a: 1
    b: 3
]

I haven't followed R3 contexts and binding evolutions, but as Red 
will use a slightly different model (more statical), I guess we'll 
come up with different solutions than with R2/R3.

Object expansion is another one of those things. When you say objects 
can't be expanded, it sounds fair enough, but when you say contexts 
can't be expanded in a language meant to create languages, that's 
a serious limitation

`system/words` virtual path support was added in today's commits, 
to be able to get/set a global variable or call a function from within 
namespaces with conflicting local names.

Example:

    e: 123
    a: context [
        e: -1
        print-line e
        print-line system/words/e
        system/words/e: 0
    ]
    print-line e

will output:
    -1
    123
    0

I just need to upgrade Red/System specifications, improve the Red/System 
runtime with this new feature, and I'll be ready to merge this branch 
into master. I might also make a new global release (v0.2.6).

If some external library requires 64bit integer, but Red/System supports 
only 32 bit integers, how can I supply that number? Can I "cover" 
it with a struct?

If you need to pass a 64-bit integer as argument, currently you would 
need to split it in two integers and pass them instead. A struct 
is passed by reference, not by value (yet).

Couldn't you pack them in a float64!?

I'm testing the namespaces branch. I can't use CONTEXT as a local 
variable anymore. Is it necessary to reserve it that strongly?

Actually, I wrote a small lib to perform the 64-bit arithmetic ... 
but I only needed subtract and divide.

it's at:

https://github.com/PeterWAWood/Red-System-Libs/tree/master/Int64

Are #enum's local to a CONTEXT?

IF and others keywords: you surely don't want to mess up your code 
(and the compiler) by redefining them. For CONTEXT, you can't use 
it inside a function body to create a namespace (would need to test 
if this case is correctly caught and raise an error), so it's ok 
to allow it as local name, no possible ambiguity.

I have a lot of #define's in the bindings that I'm now migrating 
to #enum's, and that would be left behind looking out of place once 
I move the bindings into contexts

That also goes for dialects such as GTK. In a WITH context they look 
much better, but they would still not be abstracted if constants 
in them would still need to be prefixed

Just a note: the 0.2.3 milestone is still open on GitHub

For example, I have a check type = system/alias/gtk-window!

Should that become system/alias/gtk/window! in a GTK CONTEXT?

Yes, that would require to add a lot of new code to existing features 
and would take probably several days to code and debug regressions. 
If we could avoid it, that would be nice.

Aliases in Red/System are names for C-like structs. It's quite a 
different concept as anything that would be called an alias in REBOL

In Red, I'm not sure that I will implement ALIAS support (as in REBOL), 
it seems that's a feature that has been very rarely used since the 
beginning of REBOL.

I'm interested in making a Red dictionary that will allow people 
to program in Frisian :-)

Just write a parser that calls Google Translate and does in place 
substitution.

I actually had to do something like that once, a configuration file 
contained a bunch of strings in english and they needed them in spanish 
but weren't willing to actually get someone to translate them. So.. 
I used Google Translate.

And that was maybe 5 years ago, so I'm sure Google Translate is better 
than it was. A context free dictionary conversion from one word to 
another in a different language would probably not give the desired 
result.

Our crown prince got himself in trouble at a speech in Mexico, for 
the only reason that our crown princess, and probably by extension 
his translators, are Argentinian and a certain Spanish word meant 
something else in Mexico than it does in Argentina :-)

Spanish dialects are a bit more intense than English ones it seems. 
English dialets tend to be unintelligable, very few words mean something 
offensive to others.

Afrikaans is an offshoot of Dutch and they seem to have incorporated 
a lot of interesting slang.

And Red/System is a subset/simplification of Red?

Is there a way to wait for a period of time asyncronously?

I mean that I do same action and then I want start a timer, i do 
something else and when period expires i will wake up.

then you can do some handling. But - if your hanlding takes some 
time, of course during such a time, everything is blocked. If you 
would like to have something more sophisticated, you would have to 
spawn separate tasks, as e.g. Cheyenne app server does ...

Gabriele (and DOc?) wrote a timer module for R2.

Very nice the scheduler, but I have not understand if it blocks program 
activity while waiting and if no why. I have solved my problem by 
using a View timer (face/rate: 0:0:1) since that does not block program 
activity.

If this is a Gui app, wny can't you just wait ?

@grahamC: It is a gui app that sends output to seral port, so I don't 
want to block user input while waiting the job to be  done.

Question: I open a port using rebol2 on my server. It is started 
by cron once every 24 hours and is programmed to shut down after 
1 hour. I need to check if the port is still open and listening or 
has completed and the program has closed. How do I test to see if 
the port is still open from another rebol2 program running on the 
same server?

you can also have the first app open up a second port and give it 
a very simple interface to reply to "are you done?" type messages.

(maybe even a remote kill switch, if required)

if you use a line oriented port it will be very easy to implement 
line by line commands

Hi guys, anyone have a library in Rebol to get Amazon Records passing 
a keyword and sorted by daterank?

View question http://synapse-ehr.com/community/threads/adjusting-a-text-list-starting-point.1447/

That makes sense. The strength: 512 in the code misled me to believe 
it should be possible.


The blowfish algorithm works fine, but I presume it actually uses 
a key of 448 bits and not 512. https://en.wikipedia.org/wiki/Blowfish_%28cipher%29. 
In which case the value returned by the print port/strength is deceptively 
wrong when I test it with blowfish? Or am I missing something?

AES 256 is more than sufficient for most purposes. I am researching 
what Rebol can do so I am aware of the parameters I am working within. 
I am writing code that will be used to encrypt communication between 
clients who want a secure communication facility.


I am looking at the Rebol RSA algorithms now. Thanks for your input.

have an issue:
>> fact1: 'a/a
>> num1: 99.0
>> blk: [greater? to-decimal obj/:fact1 num1]
>> objs: []
>> o: make object! [a: make object! [a: "100.0"]
>> append objs o
>> o: make object! [a: make object! [a: "99.0"]
>> append objs o

>> foreach obj objs [if equal?  do bind blk 'obj true [print obj/a]]
**Invalid path value: a/a

>> foreach obj objs [print do blk]
** Script Error: Invalid path value: a
** Near: a/a

>> foreach obj objs [print do bind blk 'obj]
** Script Error: Invalid path value: a
** Near: a/a

copy that, it must work:

fact1: 'a/a
num1: 99.0
blk: [greater? to-decimal do bind reduce [fact1] obj num1]
objs: []
o: make object! [a: make object! [a: "100.0"]]
append objs o
o: make object! [a: make object! [a: "99.0"]]
append objs o
foreach obj objs [if equal?  do bind blk 'obj true [print obj/a]]