AltME groups: search

My point is: an undefined word error is a user error, and exiting 
the interpreter with an error message is currently the best thing 
to do. I've removed the exit points after such errors because you've 
asked me to for making your demos run without exiting. But I shouldn't 
have done that.

I know, but you didn't remove a HALT from word evaluation because 
I asked

I have a loop written that does the evaluation, even without VALUE? 
but it doesn't seem like a good idea to me

Undefined single words were never a problem in the interpreter before. 
That's why I could write Redpages with a header:

They were simply ignored. After I requested the warning message, 
the Red word produces such a warning, so for now I write:

DO doesn't support a Red header yet.

You should strip it from a LOADed block before passing it to DO.

I need to fix some interpreter issues revealed by Peter's port of 
~2500 tests to the interpreter. There's about a dozen failing tests 
to fix.

Once that done, I will have a look again at those error reporting 
issues.

I agree that it is not yet possible to deeply validate user input. 
I'll see if I can find a cheap workaround for the release.

I'm getting a weird crash if I load the following in the GTK-browser:

Great stuff guys,  been taking a bit more time to get to know RED. 
 Great work Doc, Kaj, Peter, and the rest of the testers and submitters.

The right and efficient handling of refinements is really one of 
the most difficult parts in making a Rebol language interpreter/compiler.

I'm not sure yet what the optimal way would be for runtime refinements 
evaluation, I've used a bitfield-based caching method in R-sharp 
to pay the full cost on first evaluation only. I'll try to implement 
a similar method for Red interpreter later. For the Red compiler, 
the cost is paid once only during compilation, there is no specific 
runtime overhead.

I could write a book about designing and implementing a Rebol-like 
language, counting R#, I've implemented two interpreters and one 
compiler. I've also implemented a partial Rebol in Rebol interpreter 
five years ago (never published), mainly aiming at providing step-by-step 
and stop/restart evaluation features for debugging purposes. But 
my first tests showed that it  was running about 50 times slower 
than R2 itself, so unusable for real code.

Once you have free time, that will be a great project. Until then, 
just keep good notes while you work. :-)

My progress on the Red/System random function. I tried to have an 
a declaration of an array as a import, but that failed because is 
was to be declared at runtime so the array was missing at compiletime. 
Yep it is not Rebol.

Does the interpreter need to exit on a missing function argument, 
or could it continue with a warning?

Curses binding for Red/System released: https://github.com/dockimbel/Red/tree/master/red-system/library/curses


Big thanks to Bruno (a new french contributor) for this nice work!

But I won't delay the new release for that. Still a few issues to 
check and test all on ARM before making the release.

A Red dialect would be nice. Does Bruno have plans for it?

I've told him about it, he will give it a look, but he's not familiar 
with the way to achieve it with Red/System (I've pointed  him to 
your own work wrt to dialects), and Red is not yet ready for that 
(routines are not documented at all).

I hardly ever email, but if he has no plans, it would be a nice second 
backend that I could make for my GUI dialect

However, there are no real widgets. I would have to implement them, 
or a widgets toolkit on top of Curses would have to be bound first. 
That's a bit too much work for me

I'm just excited to hear there's a new contributor.  Where did he 
come from?

I have fixed a pointer arithmetic bug on ARM backend. Now all Red 
tests, including interpreter's one are passing (same as for IA-32), 
console is working fully too. I have a few more tests to add before 
making the 0.3.2 release tomorrow (finally!).

after thinking again, I would perfer %./ as the last part of the 
result of split-path, as it has a trailing slash and it  is still 
the samel

if the argument was a directory

What do you mean, if the arg was a directory? Can you give an example 
each way?

%"" looks strange, even if its allowed. %./ has a trailing slash, 
if someone wants to test for that

I'd also prefer a stronger invariant, as REJOIN is relatively weak 
for joining path components.

what do you mean with an empty target?  %./ just means the target 
is a directory, the actual directory

OK, using that as a quality test, here's where the current SPLIT-PATH 
fails:
Path quality failed: %/ %/none
Path quality failed: %// %/
Path quality failed: %. %./none
Path quality failed: %./ %./none
Path quality failed: %./. %././
Path quality failed: %.. %../none
Path quality failed: %../ %../none
Path quality failed: %../.. %../../
Path quality failed: %foo/.. %foo/../
Path quality failed: %foo/. %foo/./
Path quality failed: %foo/../. %foo/.././
Path quality failed: http:// http:/
Path quality failed: http://..http://../
Path quality failed: http://.http://./
Path quality failed: http://../.http://.././

Anton, which is the behavior question. Do you expect SPLIT-PATH to 
return a target you can write to (i.e. a file)?

Here's a few example values and what I would expect: 

http://sprunge.us/AaDJ


Where there is a third column, current R3 split-path differs from 
what I'd expect, and the third column is what split-path returns 
currently.

But with a "path component"-based invariant, the %. %.. and %/ cases 
will require more work to reconcile.


With a "string"-based invariant (rejoin), those cases could more 
easily be described with the neutral %"" element:

Here's some examples based on a string-based invariant:
http://sprunge.us/VeeH


Which is, I guess, what your proposed split-path already implements 
:)

A slightly better path-based invariant:

set [d b] split-path f
clean-path/only f = clean-path/only d/:b

It doesn't match your expected results in a number of cases though.

I don't have a *nix VM up here to check basename and dirname results.

dirname/basename does a clean-path before splitting.

:-) Let me play with an idea here for a bit.

Let's widen the discussion a bit. Spitting a string at a delimiter. 
Easy enough to define clear behavior if the series contains the delimiter, 
but what if it doesn't? Most split funcs return an array, splitting 
at each dlm. If no dlm, return the original series as the only element 
in that array. 


What if we always want to return two elements? e.g., we have a SPLIT-AT 
func that can split a series into two parts, given either an integer 
index or value to match. Let's also give it a /LAST refinement, so 
it can split at the last matching value found, like FIND/LAST works. 


Given that, what do you expect in the case where the dlm (e.g. "=") 
is not in the series?

    SPLIT-AT "abcdef" "="   == [? ?]
    SPLIT-AT/LAST "abcdef" "="    == [? ?]

I haven't had the time to follow all the discussion in detail, but 
to me, the second part of split-path should NEVER return a directory 
path. 


when doing   set [dir file]  I should be able to count on the fact 
that the second part is either a file or none.  The same for the 
first part which should always be none or a dir.  I have my own implementation 
in R2 which makes this strict and it simplifies a lot of code.
so we can do with absolute certainty:

if second set [dir file] split  path [   ]


IIRC some of the versions of my split perform a clean-path to simplify 
and add robustness to the result.

question is, is that invariant useful? 


really, I like consistency almost above all else, but I prefer when 
it not just neutral.   getting empty file specs is very awkward to 
use and doesn't work well with all the none transparency which makes 
a lot of the conditional code so easy to read.  one reason this is 
so readable in REBOL is the limited use of equality operations, when 
doing complex decision making.

question is, is that invariant useful?
 - for me it is, but, of course, it is a matter of preference

I prefer

split-path %foo
== [%./ %foo]


The reason is because I believe split-path shouldn't require an extra 
check if all you want to do is read the base directory that a file 
is in.  I think this is a common use of split-path.

Do our preferences come from the basic difference of whether we want 
SPLIT-PATH to be "smart" about file specs, or whether it should assume 
nothing (the REJOIN invariant case)? For example, Andreas's path 
invariant (p/:t) makes a lot of sense, but some of his examples' 
results look wrong when just viewed as results. e.g.:

;   %/              [%/ %/]
;   %//             [%/ %/]
;   %./             [%./ %./]

And the reason I posted the SPLIT-AT question was to see if we could 
find a solution for both.

Got it. As you might all guess, since my proposal is most like Ladslav's, 
that's my current preference. As I posted, it only misses a couple 
edge cases to also meet the path invariant. 


For Max, I undersand the value of NONE. So much so that I have an 
NONE-OR-EMPTY? mezz.

And while I understand that a file with no path implies the current 
directory, we lose information by assuming it. For example, if I 
let a user specify a path or filename, and I split it, now I can't 
tell if they gave me just a filename, or if they gave me %./<file>.

Can we resolve our differences with a refinement?

we have got quite a few combinations to consider:

missing path:

* yielding %.
* yielding %""
* yielding #[none] 

missing file

* yielding the last directory in the path
* yielding %""
* yielding #[none]


In total that is 6 variants but only some combinations make sense, 
I think

The NONE case, while potentially useful, is only in Max's custom 
version. The current version in REBOL only returns NONE in a few 
edge cases, which I think we all agree is wrong.

And it doesn't satisfy either the string (REJOIN) or path invariant. 
If we care about either of those, it's a problem.

Maxim, the problem with requiring that SPLIT-PATH should _never_ 
return a directory as second component, is that SPLIT-PATH cannot 
decide that based on a file! alone.

It could only do that in relation to a file system or with the simple 
heuristic used by DIR? as well: based on the presence of absence 
of a trailing slash.

I'm fine with a purely REJOIN-based invariant as well. (Even though 
I personally find a path-based invariant more useful.)

For those interested in the "alpha-channel change":

Here is the branch with first round of related code changes to the 
image! and image codecs: https://github.com/cyphre/r3/commit/472c106a0f177ead82a6f29be1ae98b4cd33b9ad


Note: This code doesn't contain any graphics related changes...just 
the image! datatype + image codecs so you can MAKE images and load 
BMP, GIF, PNG and JPG files. But it should be enough to test the 
change.

(I have this code already intergated with changed AGG graphics and 
it works well but I haven't published it as this part is not compatible 
with the 'official' git source at the moment.)

Note2: the code was not tested on big-endian systems so it is possible 
there can be some quirks. Use at your own risk and let me know about 
any problems.


The RGBA tuples on IMAGE! now work so if the fourth(alpha) value 
is not defined it is assumed the RGB tuple is opaque (ie. alpha = 
255) so 0.0.0 = 0.0.0.255 etc. This way color values in old code 
that doesn't explicitly define alpha values are still compatible.


If you are interested, try to compile and test a bit. Let me know 
if you see any issues. Thanks.

Isn't a convention that %foo/ is a directory while %foo is not?  
That's one way to tell if a given file! directory or not...  It's 
what I generally expect, and I agree with Maxim that it makes the 
most sense for split-path to return #[none] if there is no file.

Andreas, the trailing slash is the separator.  Are you proposing 
that split-path do a system check to verify if its a file?  like 
dir? does in R2?

It can't do a check, because the file may not exist.

Max said: "split-path shoudn't invent information which isn't given 
to it"


I agree, if we consider split-path to be operating in string mode 
(the rejoin invariant). If we want to have a file-system aware option, 
what would we call the refinement? Or should it be a separate function?


As far as returning none for either part, it strikes me as inconsistent 
(if convenient, which it may be). That is, if you split a series 
into two parts, splitting at the head or tail should just give you 
an empty series for that part, shouldn't it? This comes back to my 
SPLIT-AT question.

if it where a generic string handling function I'd agree with you... 
but its not... it has added meaning, it splits filesystem paths. 
 its not just a string.  if it where, I'd use parse or some tokenize 
func.

I see absolutely no merit in trying to make split-path act like a 
generic string handling func.  the point of the func is to separate 
folder and file into two parts.   to me it comes down to either you 
decide that when there is no data you invent a default, or use the 
internal one which is none, which works well with soooo many other 
funcs.  if there is no directory part in the path, do not try to 
find a suitable value for it... there is none... funny, even when 
trying to explain my point of view, the actual sentence reads almost 
like a line of rebol source.  :-)

if you give me split-path %"" I'd return [none none]  if you want 
a meaningfull default for the dir, then just use clean-path before 
supplying the value to split-path, then you'll be assured of always 
getting a directory.

I understand your view Max, but that's not what I asked. It doesn't 
work the way you want today, but maybe there's a way to provide a 
solution that is better than what we have now. I'd love to see your 
custom version, so we can compare its results. And I'm asking about 
SPLIT-AT for a reason, separate from SPLIT-PATH. I'd love to get 
everyone's thoughts.


The funny thing is how much we can all care about the details of 
this func we (at least I) use a lot, and yet which none of us seem 
to like all that much. I think it points out that the normal case 
is the most important, where there is both a path and a file component. 
And maybe now is the time that we can make it just a little bit better, 
a little more consistent.

I asked this in the SO chat, to BrianH, but maybe someone here can 
answer sooner.


@BrianH, can you confirm that that it's a bug that a module loaded 
using import doesn't export any words listed in the Exports: header? 
When I load the same module using Needs:, its exported words are 
visible as expected.

It's not a bug, it's a limitation of Rebol's binding model. Needs 
is called before the script is bound, and before the module context 
even exists (if the Needs is in a module header). Due to a couple 
of tricks IMPORT can mostly as a function running in scripts (shared 
globally referencable context), but it's impossible for it to work 
as a function in modules because the target scope is impossible to 
determine and the code was bound already before it even started running. 
So, long story short, IMPORT is for calling from scripts, or for 
Needs to call internally, or for advanced code where you are doing 
your own exporting.

It could be worse. Circular Needs references are currently a bug, 
but I'm not yet smart enough to resolve them, or even to know whether 
it is possible to resolve them.

The generic problem to solve is this: You somehow have to specify 
what should happen for different actions. 


Let's start with the "somehow have to specify what should happen". 
For this you have some options:

1. Write the application logic code in the GUI spec block. For sort 
stuff OK, for long not.

2. Just call a function from the GUI spec block and write the rest 
somewhere elese. That's IMO the best way. I used FSM and just send 
"application logic events".

The next part is the "for different actions". Same here:

1. Name them explicitly on-* and specify the code with one of the 
options above.BTW: IIRC R3-GUI has click and right-click blocks for 
convinience.

2. Define an implicit mappging from block order to event type. 1st 
block = click, 2nd = right click, 3rd = double left, 4th double right, 
etc. IMO that's not a good style.


Overall what I never liked about VID was that is was not explicit 
enough. For big projects that's a must. For small you might skip 
this but if those projects get bigger, you are hit again.

We can always build a "shortcut" dialect like VID on top of R3-GUI, 
for common simple patterns, once R3-GUI is complete.

My concern about GOB! is that all the rest seems not useful, probably 
at the present is missing some function, but or you act to GOB! directly 
or you have no other ways to change a facet. Am I wrong?

The problem is, that while the R3-GUI is now more flexible by removing 
reactors, it is also more difficult to understand. I remember trying 
to understand the 'on-action issue in the past, now I briefly re-read 
the doc, and I still can't understand the design. I need following 
things to be cleared up for me, so that I can both use it, and possibly 
explain it to others:


1) If you look into Actors docs - http://development.saphirion.com/rebol/r3gui/actors/index.shtml#
, there is no mention of 'on-action actors. There are many actors 
listed, but not the 'on action one


2) The 'on-action actor is mentioned in the attached doc at the same 
URL, describing, why reactors were removed. So here is the definition 
of 'on-action: 

        a) "The ON-ACTION actor is useful if the style needs to call some 
        default action from multiple places (actors) in the style definition." 
        - understand the purpose, but why and when I would like to do such 
        thing? Any example easy to understand? Just one sentence maybe?

        b) "For example, the BUTTON style needs to call the default style 
        action from the ON-KEY actor and also from the ON-CLICK actor, so 
        it is better to call the ON-ACTION actor from the both code points 
        to avoid the necessity to override multiple style actors." - looking 
        at button or even clicker style definition, I can see no such stuff, 
        as 'on-key or 'on-click calling anything named 'on-action. That is 
        the part that is most confusing for me, and which did not help to 
        understand the 'on-action a little bit. Are we talking about the 
        'do-face here?


There is also a question, if better name could be found for 'on-action. 
Unless I can fully understand, what happens here, difficult to suggest. 
Now to make it clear - I am not judging architecture, just trying 
to get my head around the docs and button/style examples. And being 
average reboller - if I have difficulcy to understand it, the chances 
are, there is more ppl, which will strugle in that area?

Another interesting thing I noticed:

    facets: [
        init-size: 28x28
        bg-color: 80.100.120
        border-color: 0.0.0.128

        pen-color: ; set by on-draw
        area-fill: ; set by on-draw
        material: 'chrome
        focus-color: guie/colors/focus
        draw-mode: 'normal
        materials: none
        face-width: none
    ]


Normally, in regular Rebol code, 'pen-color and 'area-fill, would 
be set to 'chrome, if I would use it to construct an object. But 
maybe it is just a spec block, so I should not care? I mean - what 
about setting them initially to 'none too, for a convenience? :-)

Pekr: I agree the docs are still not corrected...infact it is a mix 
of old(patched) docs from Carl and some '"dev notes" docs from Saphirion 
team who did significant changes.

I started to at least review the Carl's docs to fix the most confusing 
or obsolete parts but I relaized I have not enough time now for that 
instead of programming. 

If you want to help clean-up the documentation or even write new 
document...kind of "User guide" for newcomers I'm offering you a 
help/support with any questions issues etc. during the doc writing, 
just le me know. Also we can discuss the issues in the R3GUI group 
here (I still wonder noone is asking anything...probably noone is 
interested?)

I think ppl in kind of an wait mode. Some interested in Android in 
general, some interested in Red progress, som interested in Ren, 
most of us busy other way.  Max in fact is doing a good job - he 
tries to use the system in a practical way. My questions are just 
theoretical, just by reading docs and looking into the code. I know 
I will be back to GUI at some point, just dunno when ...

Robert, people like me feels they wont be able to face all the problems 
that will arise from uncomplete/unwritten documentation and prefer 
a REBOL2 version.

I don't know anything about R3GUI
There is an uncomplete documentation

It is difficult for me to understand new things. Since the documentation 
is uncomplete and refers to outdated concept it will be more difficult.
RMA has promised a new documentation
Since then I can wait to work in REBOL3
Also REBOL3 has many bugs and it is still in ALPHA

(Please note, no accuses of any king, only direct word from my mind)

Also REBOL3 has many bugs and it is still in ALPHA

 - what about the (already known for a while) info that R3 has less 
 bugs than R2?

Apart from Unicode, we have no comparison over REBOL2 for new and 
better feature which could motivate the programmer.
 - wrong again, you surely heard about:
- essentially all cycles being natives in R3
- money implemented as a "truly decimal" format

- functions implemented differently to be compatible with multithreading, 
etc.
- closures implemented natively
- Parse improved significantly
- R3GUI improved
- new modules feature
- I do not even have the time to list all...

And while doing this, if you start writing it down for others that 
would be great. And, we get feedback what's not a good design etc.

That's how I think a community should work together.

I think that there is no way to take it as offense. Noone said a 
bad word against R3-GUI today imo ...

Could you please complete the list of changes in REBOL3

 - that is a problem: I do not think such a list can be made "complete". 
 Some changes actually are "code cleanup", e.g. Also, there is a time 
 problem: I would have to browse R3 Chat, CureCode, AltMe, DocBase, 
 Carl's blog, Carl's R3 doc, GitHub, whatnot to do it. Why do you 
 think I am the one who has got the time to do it?

OK, to be of some help I decided to compile a couple of notes of 
this kind as an article for the future reference/improvement.

I think it could be a good start. However, Ladislav usualli works 
on REBOL wiki.

Ren is a new distraction now too. :-) But I think it will be good 
for all of us.

How do you like this "Implementation artefact":

f: make function! reduce [[x /local x-v y-v] body: [
	x-v: either error? try [get/any 'x] [
		"x does not have a value!"
	] [
		rejoin ["x: " mold/all :x]
	]
	y-v: either error? try [get/any 'y] [
		"y does not have a value"
	] [
		rejoin ["y: " mold/all :y]
	]
	print [x-v y-v]
]]

g: make function! reduce [[y /local x-v y-v] body]

>> f 1
x: 1 y: 1

(specailly Andreas should have a look)

Just for comparison, these results are from R2:

f: make function! [x /local x-v y-v] body: [
	x-v: either error? try [get 'x] [
		"x does not have a value"
	] [
		rejoin ["x: " mold/all :x]
	]
	y-v: either error? try [get 'y] [
		"y does not have a value"
	] [
		rejoin ["y: " mold/all :y]
	]
	print [x-v y-v]
	unless value? 'y [g 2]
]

g: make function! [y /local x-v y-v] body

>> f 1
x: 1 y does not have a value
x does not have a value y: 2

Very good catch, Ladislav. A rather nasty bug.

Ok. That's better (even though it is a somewhat ugly hack).

Are they pooled or managed using a custom allocator?

Ah, so they can only be contained within a series.

(Or a gob, maybe.)

So there's a "gob reference" value type?

Ah, I see. A "gob value" is just a pointer to the real gob structure.

REBGOB (the part needing GC) is 512 bits, while Reb_Gob (fits within 
128 bits and points to a REBGOB)

I am quite curious whether it would be possible to fit a Rebol value 
to less than 256 bits when using 64-bit memory pointers

Hi, all, a "stupid" question: R3 is still called "alpha" (and there 
*are* issues I want solved before moving it to beta). One of the 
issues is the "gotcha" represented by the DECIMAL! name. I know that 
it is used consistently in Rebol, but it is still a "gotcha" for 
any possible newcomers actually stating something like: "here mathematics 
is not welcome", which is not true so much as I (mathematician by 
the education) would say.


Also, having a "truly decimal" datatype called MONEY! in R3, I would 
prefer a rename:

MONEY! rename to DECIMAL!

DECIMAL! rename to REAL! or FLOAT! (or something else that could 
be popular)


So, how many of you prefer to keep the DECIMAL! name for the 64-bit 
IEEE 754 binary floating point format used in Rebol and

how many of you prefer to rename the DECIMAL! datatype to something 
else?