Archived messages from: gitter.im/red/tests from year: 2018

SteeveGit
16:41hello, since I plan to do my comeback very soon, I first made a local clone and then compiled the console (it's Ok) but the test suite is returning this:
>>> do %run-all.r
** Script Error: Feature not available in this REBOL
** Where: context
** Near: SECURITY_ATTRIBUTES: make struct! [
nLength [integer!]
lpSecurityDescriptor [integer!]
bInheritHandle [int...
>> pwd
== %/Z/red/utils/

what am I doing wrong ?
17:04it builds the 0.6.1 console by default, from the master branch
9214
17:06@SteeveGit current Red version in master branch is 0.6.3.
SteeveGit
17:07so, I fucked up something that early ;)
17:11seems that I'm linked to an old clone of mine
19:32Ok , I got the -=== Red Compiler 0.6.3 ===- now, but still the same error with do %run-all.red
>** Script Error: Feature not available in this REBOL
19:33if it says so... time to work on my project
greggirwin
19:50Nice to see you again @SteeveGit! What version of Rebol do you have installed? And is it %run-all.red or %run-all.r you're running?
19:52With Rebol 2.7.8, running %run-all.r with it, all should be good.
SteeveGit
20:11Hi @greggirwin, I run do %run-all.r as stated in the readme
9214
20:12But you said you run %run-all.red?
SteeveGit
20:14really ? ah yes a typo !
Besides I run it with rebol-core-278-3-1.exe
greggirwin
20:15So, OK then, or still an error with the right filename? Running here fine, in a Rebol 2.7.8 console, so must be something amiss.
SteeveGit
20:17I'll try again

SteeveGit
09:47Hello, I tried again to run the test suite using the original source files (not from my fork).

>-=== Red Compiler 0.6.3 ===-
Compiling D:\red-master\environment\console\CLI\console.red ...
...compilation time : 1001 ms
Compiling to native code...
Script: "Red/System PE/COFF format emitter" (none)
...compilation time : 26513 ms
...linking time : 829 ms
...output file size : 1032192 bytes
...output file : D:\red-master\console.exe
>> do %run-all.r
Script: "Builds and Runs All Red and Red/System Tests" (none)
** Script Error: Feature not available in this REBOL
** Where: context
** Near: SECURITY_ATTRIBUTES: make struct! [
nLength [integer!]
lpSecurityDescriptor [integer!]
bInheritHandle [int...

09:49same errors
10:02I didn't mention I use Winows 10 x64
10:03shoud I try ubuntu ?
9214
12:48@SteeveGit try to use [Rebol/View console](http://www.rebol.com/download-view.html), not Rebol/Core.
SteeveGit
12:56whaaaat !!! don't tell me ?
12:57what a fool T_T
12:59it's running now, thanks @9214
9214
13:01Comeback with a style. :wink:
SteeveGit
13:05Can't believe I didn't see it coming :-1:

greggirwin
04:13Whew!

SteeveGit
08:51I keep getting crashes using the face/para/scroll field.
Does anyone know how to use it ?
view [text left "line1^/line2^/line3" with [para/scroll: 4x10]]

SteeveGit
07:56Wondering why load/next seems to not catch errors, what am I doing wrong ?
>> load/trap ",," 
== [[] ",," make error! [
    code: 200
    type: 'syntax
    id: 'i...
>> load/trap/next ",," 'err 
== [[] ",," none]
>> ?? err
err: [[] ",," none]
9214
08:00@SteeveGit there's no loadable value in your example, so /next does nothing.
08:01And how is it related to tests?
SteeveGit
08:05@9214 because that's not my point, I try to catch errors without the need to load a full loadable script.
And if it's a bug, I'm in the right place, it seems.... no ?
9214
08:05https://gitter.im/red/bugs
SteeveGit
08:07ok I'll try to do better next time, Though I still don't know if it's a bug or a feature :smile:
greggirwin
17:01@SteeveGit, I think /trap and /next are mutually exclusive, as the doc string for /trap says it loads all values. It works as expected, and doesn't error out, but returns the information about errors to you.
>> load/trap ",," 
== [[] ",," make error! [
    code: 200
    type: 'syntax
    id: 'invalid
    arg1: 'value
    arg2: ",,"
    arg3: none
    nea...
>> load ",," 
*** Syntax Error: invalid value at ",,"
*** Where: do
*** Stack: load
17:02
>> print mold load/trap "1 a [] ,, 2 b ()" 
[[1 a []] ",, 2 b ()" make error! [
    code: 200
    type: 'syntax
    id: 'invalid
    arg1: 'value
    arg2: ",, 2 b ()"
    arg3: none
    near: none
    where: 'do
    stack: 77957712
]]
17:03
>> print mold load/trap "1 a [] 2 b ()" 
[[1 a [] 2 b ()] ")" none]
17:05So load/trap is an *alternative* to load/next, where you get 0 or more loaded values, the position to continue from, and whether there was an error or not, to know if you need to continue.

The trailing ")" in the successful load above might be worth investigating, to see why it's not the tail of the input.

SteeveGit
07:55I beg to differ @greggirwin
I still hope I’m missing something important in the design but I don’t understand why you are justifying the injustifiable (to me).
1/ load/next allows the loading of a string bit by bit but never throws back errors if any. So, we can’t track the position of a syntax error in the string.
In fact, we can. Even if it’s not throwing back catchable errors, load/next does not advance the string position in the case of a syntax error (clearly a bug or a missing feature).
2/ Load/trap loads a complete string (like a script) and emits only one syntax error as an object if any (the first encountered one).
Again, What am I missing ? because what you are advocating Gregg, makes no sense to me. An "alternative" to what ? Good day :smile:
greggirwin
17:27@SteeveGit moving to red/help.

PeterWAWood
00:41I have consolidated all currently failing tests in red/tests/failing-tests.red as they get forgotten with the current practice of commenting out failing tests.
00:42In the process of consolidating them I found a number of commented out tests that now work.
greggirwin
04:49Thanks Peter!

greggirwin
23:31@PeterWAWood, I have some new tests, where the compiler (correctly) can't compile a bad func spec (under test), so I use do to test the interpreter: --assert error? try do [...]

When those tests are enabled, I get a "signify error" output, and the tests don't run. Is that expected?
PeterWAWood
23:37@greggirwin No, it is not expected. "Signify error" will be shown when the test fails to compile.
greggirwin
23:39Ah, I think it's me. Hang on.
23:40Yes, that was my fault. False alarm.
23:42Still not getting the error as expected though.
PeterWAWood
23:47What is the function code?
greggirwin
23:47Just a sec. I cleared runnable and am recompiling.
23:48Seems to be hung again.
23:49Woohoo! Works now.
PeterWAWood
23:58:+1:

greggirwin
00:20So close. Locally testing is fine:
>> do/args %run-test.r to-rebol-file "C:\dev\greggirwin\red\tests\source\units\function-test.red"
Script: "Builds and Runs a single Red/System Tests" (none)
Script: {Simple testing framework for Red and Red/System programs} (none)
Script: "Untitled" (none)
Quick-Test v0.12.0
Running under REBOL 2.7.8.3.1
~~~started test~~~ function
~~~finished test~~~  function
  Number of Tests Performed:      115
  Number of Assertions Performed: 138
  Number of Assertions Passed:    138
  Number of Assertions Failed:    0

But doing %run-all.r I get
signify failure
~~~started test~~~ run-all-interp
1
*** Script Error: invalid function definition: return:
*** Where: func
*** Stack:

PeterWAWood
00:45Can you drop function-test.red in a gist? I can then take a look
00:45Or just post the failing test here:
greggirwin
00:46Yes. Just commented the intentionally bad tests out, to see if that clears it.
00:46
===start-group=== "function spec validation"
	--test-- "fsv1"
        --assert function? func [][]
	--test-- "fsv2"
        --assert function? func [a [integer!] "doc a" b [string!] "doc b" /c d [block!] "doc d" e return: [integer!]][]
	--test-- "fsv3"
        --assert function? func [a [integer!] "doc a" b [string!] "doc b" /c d [block!] "doc d" e][]
	--test-- "fsv4"
        --assert function? func [a [integer!] "doc a" b [string!] "doc b" /c d [block!] "doc d"][]
	--test-- "fsv5"
        --assert function? func [a [integer!] "doc a" b [string!] "doc b" /c d [block!]][]
	--test-- "fsv6"
        --assert function? func [a [integer!] "doc a" b [string!] "doc b" /c d][]
	--test-- "fsv7"
        --assert function? func [a [integer!] "doc a" b "doc b"][]
	--test-- "fsv8"
        --assert function? func [a [integer!] "doc a" b [string!]][]
	--test-- "fsv9"
        --assert function? func [a [integer!]][]
	--test-- "fsv10"
        --assert function? func [a "doc a"][]

	; DO is used here, because the compiler will correctly catch errors the interpreter doesn't.
;	--test-- "fsv11"
;        --assert error? try [do [func [a [integer!] returns: [integer!]][]]]
;	--test-- "fsv12"
;        --assert error? try [do [func [a [integer!] return:][]]]
;	--test-- "fsv13"
;        --assert error? try [do [func [a return: [integer!] b][]]]
;	--test-- "fsv14"
;        --assert error? try [do [func [a return: [integer!] /c][]]]
;	--test-- "fsv15"
;        --assert error? try [do [func [a return: b][]]]


===end-group===
00:48Hmmm, does it not like the fsv2 test I wonder? Still failed.
PeterWAWood
00:57If I compile and run this short program, it runs:
Red[]
print error? try [do [func [a [integer!] returns: [integer!]][]]]
greggirwin
00:57Even with that test commented out, I still get the error.
PeterWAWood
00:57and prints "false"
greggirwin
00:58Because you don't have my fix to %function.reds I think.
00:58My fix makes that an error.
PeterWAWood
00:59Well at least you know the tests are correct :-)
greggirwin
01:31Here's what it seems not to like. I added a check to make sure return: [...] was the last thing in the spec.
TYPE_SET_WORD [
					w: as red-word! value
					if words/return* <> symbol/resolve w/symbol [
						fire [TO_ERROR(script bad-func-def)	w]
					]
					next: value + 1
					next2: next + 1
					unless all [
						next < end
						TYPE_OF(next) = TYPE_BLOCK
						next2 = end   ;**** This makes it unhappy ****
					][
						fire [TO_ERROR(script bad-func-def) value]
					]
					value: next
				]
01:31I also added the check on the symbol, which doesn't cause a problem.
01:40Ah, a misunderstanding on my part. Not enough brain it seems. /local can follow the return.
01:40Good thing we have all these tests.
PeterWAWood
01:41You either need a break or a coffee or both.
greggirwin
01:41Yeah. First need to see if I can fix this.
PeterWAWood
01:49From a quick look at function.reds, it might be easier to add the check that return: follows the other parameters in calc-arity which is already ignoring anything after it comes across a set-word.
greggirwin
01:51The problem is #3454. You shouldn't have any other words after return:
PeterWAWood
01:51Though it really wouldn't be good practice from a single responsibility perspective.
greggirwin
01:51So if it just stops, like calc-arity, it won't catch that. Just need to learn how to check the symbol match as /local.
PeterWAWood
01:52Can't any refinement come after return:?
greggirwin
01:53I wouldn't think so. But I guess we don't have a hard func spec yet. Seems like return should be final or penultimate.
01:53i.e. only locals to follow.
PeterWAWood
02:01You can specify /refinements after return: at the moment.
02:01
text
>> f: func [a return: [integer!] /b c] [either b [print c] [print a] ]
== func [a return: [integer!] /b c][either b [print c] [print a]]
>> f 1
1
>> f/b 1 3
3
greggirwin
02:02By design you think?
02:02Seems ugly to me.
PeterWAWood
02:02The code in function.reds suggests so to me ... but I could be wrong.
02:05It may look ugly but it will be helpful when people start asking to alter the return type for specific refinements ;-)
greggirwin
02:06Ooooooh.
PeterWAWood
02:06Like this :

3
>> f: func [a return: [integer!] /b c return: [float!]] [either b [print c] [pri== func [a return: [integer!] /b c return: [float!]][either b [print ...
>> f 1
1
>> f/b 1 3.0
3.0
>> f/b 1 3
3
greggirwin
02:06I'll leave the check at refinement then.
PeterWAWood
02:07I was being very tongue-in-cheek !!
greggirwin
02:08Scary, but reasonable. :^\
PeterWAWood
02:08That said, the pendulum is clearly swinging towards strict type checking in this decade. Luckily the next decade will start in a couple of years.
greggirwin
02:16Nope, compiler doesn't seem to like that kind of spec.
PeterWAWood
02:21There is a difference between the compiler and the interpreter. I used this "horror":
Red[]

f: func [
	/int
		i		[integer!]
		return:	[integer!]
	/flt
		f		[float!]
		return:	[float!]
] [
	if int [ return i ]
	if flt   [ return f ]
]

print f/int 1
print f/flt 2.0
greggirwin
02:22Does that compile for you?
PeterWAWood
02:23No
*** Compilation Error: invalid function spec block: [
    return: [float!]
]
02:24And the interpreter is happy when you define the function but does not actually build the second refinement:
== func [
    /int 
    i [integer!] return: [integer!] /flt 
    f [...
>> f/int 1
== 1
>> f/flt 3.0
*** Script Error: f has no refinement called flt
*** Where: f
*** Stack: f
greggirwin
02:24Same here with a similar spec.
02:24So I'm pushing my fix that just checks for refinements after return, allowing them.
02:24That seems to pass %run-all.
PeterWAWood
02:25Sounds good.
greggirwin
02:25PR out now, builds in progress.
PeterWAWood
02:32macOS and Linux builds passed
greggirwin
02:32All good this time. Yay!
02:33Care to merge me?
PeterWAWood
02:34My pleasure.
greggirwin
02:35Thanks! 1 down, 339 to go. ;^)
02:36338 Forgot my PR covered 2.
PeterWAWood
02:41All looks good with the merged PR.
meijeru
18:19Who will publish the definitive syntax of the function specs? I have put up my own take of this, which is overly strict, in red/specs. Are we going towards completely free form, i.e. arguments, refinements and return spec may occur in any order??
greggirwin
18:21I don't think it can be completely free-form. Nenad has the final say, but we can start with your spec and draft an RFC to nail it down.