Archived messages from: gitter.im/red/bugs from year: 2017

x8x
07:08File test:
Red []

? system/script


Linux:
# ./red test
*** Script Error: image! has no value
*** Where: =

macOS:
# red red/read/test

*** Runtime Error 27: non-existent physical address
*** at: A17340E4h
dockimbel
07:13@x8x Confirmed on Linux using red-28apr17-bbd8e43.
x8x
07:50I have an issue on macOS, open a Terminal.app window with 2 tabs, now run red console in one and paste this code:
to-int: function [value [percent!]][to integer! 255 * value]

view [
    below
    r: slider
    g: slider
    b: slider
    base react [
        face/color: as-color to-int r/data to-int g/data to-int b/data
    ]
]

Now after closing the View window I notice a 2 seconds delay when switching Terminal.app tabs,
also the window closing should be instantly but it also has a delay.
Now paste again above code and I get this https://pastebin.com/raw/4tADZxHG in the Terminal Window while the View window runs fine.
Never seen this latency with any other software.
Another strangeness, while red console is open (compiled with View) the icon in the Dock when control-clicked says Application Not Responding, normally that is only for unresponsive apps.
07:54Well it's worst, all my UI clicks suffer delays until I close red, not sure how to debug that.
07:57It is not a recent regression.
dockimbel
09:13@qtxie ^---
qtxie
09:27@x8x Thanks. I'll check that. Are you using macOS 10.12?
12:05Seems only the console has this problem. When compile the script as a standalone executable, it works fine.
x8x
12:19yes 10.12, yes interpreted, didn't try compiled
dander
16:46I know this is not the right way to define an op!, but it looks like it works at first, and can generate a crash:
>> plus: make op! [[x y][x + y]]
== make op! [[x y]]
>> ? plus
USAGE:
        x plus y

DESCRIPTION:

        PLUS is an op! value

ARGUMENTS:
        x
        y
>> 1 plus 1

*** Runtime Error 1: access violation
*** at: 02BD5F0Ch

dockimbel
16:28@dander Worth a ticket, for the crash, and for blocking such syntax. An op! is just the infix version of a prefix binary function, it has no constructor defined for a spec/body blocks input.
dander
17:00@dockimbel two separate tickets? or just one?

dockimbel
05:11Just one.
maximvl
15:19I saw directory loading in Rebol examples, but in Red it fails with a cryptic error:
>> load %.
*** Script Error: transcode does not allow block! for its <anon> argument
*** Where: transcode
meijeru
17:04Shouldn't that be read %. ???
maximvl
23:10@meijeru read works, but maybe there was a plan for load too, as in Rebol

dockimbel
08:59@maximvl I'm not sure if that's an intended feature in Rebol, or a side-effect of the implementation. We'll see once we implement the file and directory ports in 0.7.0.

x8x
10:29Just been bitten again by the copy/paste/autocomplete issue.. pretty annoying and now that we have presenters doing copy/paste it is maybe time to consider fixing it 😜
10:31This should work right? (note that there is a tab before ;comment
f: func [
	fun	;comment
][fun]
f 1

but this is what comes by pasting in console:
f: func [
[    func function function! function? 
[     func;comment
[    ][fun]
;   func [
    func
][fun]
  f 1
*** Script Error: fun has no value
*** Where: f
10:35There are 2 issues open about this https://github.com/red/red/issues/1164 and https://github.com/red/red/issues/2265
qtxie
23:17@x8x Just tried the bracketed paste mode on Mac, it can be used to fix this issue. Will push a fix later. :smile:
x8x
23:23Thank you very much @qtxie ! This is really great! From what I read it should work also on Linux while on Windows, I really don't know.. 😉
23:33While you are at escape sequences.. 😁, if it's not too complicate could you have a look also at these 2 issues https://github.com/red/red/issues/1844 https://github.com/red/red/issues/1845 . Just a wish 🤓.

x8x
08:49Wonderful THANKS !! Works in macOS and Linux! Well done! :smile:
qtxie
09:23For issue #1845, I have an idea how to fix it, but more code need to write, so I'll postone it.
x8x
09:27No hurry and thanks for looking into it!

geekyi
13:40@x8x I guess it's not much of a problem on windows because of gui-console. Also, I guess we don't need anything like that on Unix?

x8x
17:54The workaround in compiled scripts till we get dyn-stack is to do the block containing a function passed as an argument.
My understanding is that what is in the do block will run interpreted at execution time.
So I'm wondering if this is also related to missing dyn-stack or a bug.
This script:
Red []

object [
	a: func [i][i]
	set 'b func [f][do [f 1]]
	set 'c does [b func [i][print a i]]
]
c

when compiled and executed, returns:
?function?

That is the a function called in the function passed as an argument to function b inside function c should be executed interpreted as it is evaluated inside the do block in the body of function b.
But a is not executed, it returns instead it's function value.
To get it properly working I have to write it like this:
Red []

object [
	a: func [i][i]
	set 'b func [f][do [f 1]]
	set 'c does [b func [i][print do [a i]]]
]
c

That is do [a i] instead of a i inside the function passed as argument to function b that is run inside the do block of function b
Hopefully I'm clear enough ;-)
18:04Also I'm wondering if writing code that needs the dyn-stack is bad style ( probably due to too much freedom in rebol ) and just curious if there is an eta for when the dyn-stack will come. 🤓

dockimbel
06:20You can't have your cake and eat it too, either you want to use a very flexible style, and it won't be compilable, in such case, wrap your whole code in a do, so that the interpreter takes over it (maybe we should make that a compilation option) and you won't be limited by the compiler. Dyn-stack branch should solve most (maybe all those cases), though, performances will suffer from it, for use cases like that (closer to interpreted performances than compiled ones). No ETA, they are too many other higher priority tasks for now.
x8x
06:23@dockimbel Thanks, but why would a returns it's function value and not be executed instead?
dockimbel
06:27Because compiling functions in functions is not well supported by the compiler for now. I plan to work on that once we implement the HOF.
x8x
06:27How should I write the same functionality in a way that would please the compiler?
dockimbel
06:28Just wrap the expression in do as you did in the second example.
x8x
06:29OK thanks! 😊
geekyi
11:22@x8x :point_up: [May 14, 2017 10:54 PM](https://gitter.im/red/bugs?at=591899bd331deef464691306)
> The workaround in compiled scripts till we get dyn-stack

Did you put this info in a github issue (If I'm remembering correctly)? So that info is not lost.
Probably worth putting in the wiki under a.. maybe Red[] Compilation troubleshoot?
It's in the gray area between the interpreter, and *Red/System*
11:23https://github.com/red/red/issues/2485#issuecomment-294886825
11:24I find there's quite a log of bugs like this, and the workaround in most cases is to do it
maximvl
20:14Inside system/view/evt-names in latest windows build:

key-up on-key-up 
    ime on-ime 
    focus on-focus
20:15seems like somebody forgot to throw out the second line
20:15cause time on-time is there

qtxie
02:27@maximvl This event is for [input method editor(IME)](https://en.wikipedia.org/wiki/Input_method) support.
maximvl
07:02oh, I see

meijeru
21:35I am puzzled about continue. The help says "Throws control back to top of loop" and from a few tests I suspect that this is indeed what it does: restart the loop body with the loop counter the same as it was. But that leads to endless loops. Shouldn't it rather throw control to the *end* of the loop, where the loop counter is tested and possibly increased?

dockimbel
02:59@meijeru
>> loop 3 [continue]
>>

Where is the issue?
geekyi
06:25@meijeru
loop, while,until: no counter, *NA*
repeat: counter increases
forall: *infinite loop (implying counter doesn't increase)*
foreach: counter increases
rebolek
06:27@meijeru can I see some example, where the counter does not increase? Here's one where it does:
>> repeat i 5 [if odd? i [continue] print i]
2
4
geekyi
06:34
red
things: [1 2 3]
forall things [if 2 < first things [break] print things continue]
06:35(warning: infinite loop)
rebolek
06:37Interesting, thanks. But the infinite loop happens only when continue is last value:
>> things: [1 2 3 4 5 6] forall things [if 4 < first things [continue] print things]
1 2 3 4 5 6
2 3 4 5 6
3 4 5 6
4 5 6
geekyi
06:40@rebolek not for me, maybe because you don't reset to head things?
06:41
>> system/build
== make object! [
    date: "13-May-2017/3:26:47+5:00"
rebolek
06:42@geekyi You've changed your example, I had infinite loop with first one, what's the point of resetting to head, when in cannot be reached due to infinite loop?
geekyi
06:42@rebolek good point..
rebolek
06:43Sorry, I was wrong, there is infinite loop even with my code.
geekyi
06:43Ah, ok.. I was trying to reproduce your condition :smile:
rebolek
06:44It's Monday morning... ;)
meijeru
06:56It is as I suspected: an infinite loop with forall. I will make the issue later today.
06:57No need. Doc made it himself...
rebolek
07:03...and released a fix for it :)
dockimbel
07:03... and fixed now: https://github.com/red/red/issues/2707
meijeru
18:44See %interpreter.reds at lines 215 - 220. There is a definite typo
switch TYPE_OF(arg) [		
					TYPE_LOGIC	 [push logic/get arg]
					TYPE_INTEGER [push integer/get arg]
					TYPE_LOGIC	 [push float/get arg]
					default		 [push arg]
				]

The second TYPE_LOGIC should be TYPE_FLOAT

dockimbel
04:22@meijeru Good catch, fixed now.
AlexanderBaggett
16:46Geeky told me I should post this here. There is a way to create a set of windows such that you Lockup the REPL in Red.
16:46
p: layout [ 
            button "Create" [
                do view [
                    button "Lockup Red REPL"[
                        unview/only p 
                        view p 
                        unview 
                        unview p 
                    ]
                ]
            ]
]
view p



16:46The basic idea is simple. You create a window. You create a child window. You close the parent window from an event from the child window. After doing that the REPL is locked. Even if you close the child window, or re-open and reclose the parent window from the child window, the REPL stays locked.
16:48@dockimbel , Is this something we should open a github issue for?
geekyi
18:37Additional info from bolek:
18:37>
p: layout [ 
            button "Create" [
                do view [
                    button "Lockup Red REPL"[
                        unview/only p 
                        view p 
                        unview 
                        unview/only p 
                    ]
                ]
            ]
]
view p
18:38This code doesn't lockup

dockimbel
02:04@AlexanderBaggett What is the do in do view for?
02:05@qtxie Please have a look at the above case.
AlexanderBaggett
13:48@dockimbel , it's not important to the reproduction of the issue. You can leave it out. Its really just part of my particular coding style.
dockimbel
16:06@AlexanderBaggett FYI, do view will try to evaluate the return value of view, which is very odd, as viewshould return a face or a value from the event loop.

geekyi
13:29:point_left: [May 29, 2017 2:48 AM](https://gitter.im/red/help?at=592b45b02b926f8a67a01de7) view and borders, what I'm getting:
13:29[![image.png](https://files.gitter.im/red/bugs/tPGJ/thumb/image.png)](https://files.gitter.im/red/bugs/tPGJ/image.png)
13:30Only popup doesn't have borders, a different result from what @justjenny is getting (noflags doesn't work for her either)
13:32But also reproducible with python and rebol (?)
13:34Win 10 1607
13:35What popup looks like when focused (only top blue border is visible):
13:35[![image.png](https://files.gitter.im/red/bugs/M2Dc/thumb/image.png)](https://files.gitter.im/red/bugs/M2Dc/image.png)
dockimbel
14:10@geekyi I'm not sure to understand what problem you are reporting, could you be more specific (expectation vs result)?
14:14We are currently working on improving window size depending on the set of flags used, so we're very interested in issues about that.
geekyi
14:19@dockimbel just trying to reproduce
dockimbel
14:21@geekyi Ok, so you didn't notice any issue there?
geekyi
15:02Sorry @dockimbel not sure if you got my last message. On mobile. So here's it again. I was able to reproduce in popup. With @justjenny bug with borders, if you see the last image, the popup version doesn't have blue border except at the top. Given, it's just a minor visual thing. And jenny says it happens with python and rebol too (which I've not checked)
dockimbel
16:10@geekyi Thanks, I will investigate that tomorrow. As I'm not a regular Win10 user, I'm not sure if that's the expected layout for a popup window or not.
meijeru
17:37Saw the Showcase/last-commits.red example. Great! Only, when I run it as is, the window is minimal size, and cannot be enlarged. I had to add dimensions to the text-list (say 800x600) in order to have a useful picture. Missing or wrong default size for text-list?
greggirwin
18:07What OS @meijeru? Works on Windows here. Text list is 454x155 that demo.

Very cool demo BTW!
meijeru
20:05W10. I use the 23 May build. Maybe something improved since....
geekyi
21:02@meijeru I think it's always been that way, i.e, you can't maximize, try view/flags [] 'resize
21:04But even without it, gives me a useful, scrollable layout
21:05[![image.png](https://files.gitter.im/red/bugs/6rcu/thumb/image.png)](https://files.gitter.im/red/bugs/6rcu/image.png)
21:08Tried May 19 build, works the same for me

dockimbel
02:44@meijeru We don't have built-in resizing yet, you need to pass the flags to view, then write the resizing event handler yourself.
02:46BTW, that demo code can be rewritten as a single expression:
view [
	text-list data parse 
		read https://api.github.com/repos/red/red/events
		[collect [any [thru "message" 3 skip keep to ["\n" | {"}]]]]
]

As I don't think that mixing a lot of Red code inside VID dialect is very readable, I opted for the separated expressions outside of VID. Though, this version gets rid of events and list words definition, so it looks more *pure*.
02:52Though, if you think that this version is a better *showcase*, let me know. ;-)
rebolek
05:26Or you can use GitHub API:
view [
    text-list data collect [
        foreach commit github/list-commits 'red/red [
            keep commit/commit/message
        ]
    ]
]

:satisfied:
geekyi
10:11@rebolek you should mention where your github api is 😉
rebolek
14:25@geekyi Oh, sorry :) Currently it is available as a part of Gritter: https://github.com/rebolek/gritter

meijeru
08:54I may be doing something wrong, or I am using an older version, but see this result of compiling a very small program (only essentials shown):
Compiling to native code...
...compilation time : 53527 ms
...linking time     : 641 ms
...output file size : 882176 bytes
...output file      : C:\Projects\Red\programs\red-inspector\libRedRT.dll 

...compilation time : 62 ms

Target: MSDOS 

Compiling to native code...
*** Compilation Error: attempt to redefine existing function name: red/object/get-values 
*** near: [332x1 
    #import ["libRedRT.dll" stdcall [
            get-values: "red/object/get-values" [obj [red/red-object!] return: [red/cell!]] 
            get-values: "red/object/get-values" [obj [red-object!] return: [cell!]]
        ]]
]

> Terminated with exit code 1.

10:03Bug disappeared when using latest version. Please forget the above.

meijeru
09:20I am puzzeled about the requirements for the type spec of a routine formal argument. Inspecting the Red compiler, convert-types allows there to be no type spec at all, but when such a routine is actually compiled, a compilation error occurs, presumably coming from the Red/System compiler. Wouldn't it be easy to allow no type spec and substitute any-type for that? OR, am I doing something wrong?

rebolek
06:39I would expect false and true to be printed here:
>> case [(probe equal? 1 2) [print "asd"] (probe equal? 1 1) [print "xyz"]]
xyz

A bug?
dockimbel
06:40I get false and true printed here.
rebolek
06:41Interesting. I will recompile my console and try it once again.
06:43Works fine now, probably some bad build. Thanks.
dockimbel
11:37@meijeru The absent type is filled with a [red-value!] when the routine is called the first time (emit-routine). So if you never call the routine, its spec block will remain invalid. The following code compiles fine:
r: routine [a][probe TYPE_OF(a)]
r 123
11:38The injection should rather happen in convert-types, so that it will not error out if the routine is never called.
meijeru
13:41I will raise a suitably formulated issue.

Oldes
12:16@dockimbel there seems to be bug with quoted arguments on Windows... using code:
argument: system/args-list + 1
home-dir: argument/item
print-line ["Julia home dir: " home-dir]

and than:
c:\dev\GIT\Red>julia "c:\dev\Julia-0.5.2\bin\"
Julia home dir: c:\dev\Julia-0.5.2\bin"

Notice that there should be: c:\dev\Julia-0.5.2\bin\ not c:\dev\Julia-0.5.2\bin"
dockimbel
12:31I think \" is treated as an escape sequence for double quote. I guess such rule should not be used on Windows. You can open a ticket for it.
Oldes
12:49https://github.com/red/red/issues/2772

iArnold
07:46When compiling using 'rc in Rebol console with --no-runtime option, console gets flooded and no executable is generated.

dander
22:28get-env doesn't seem to work correctly with a word! argument (but I'm not sure how it's supposed to work)
>> env: 'temp
== temp
>> env2: "temp"
== "temp"
>> get-env temp
*** Script Error: temp has no value
*** Where: get-env
*** Stack:
>> get-env env
== temp
>> get-env env2
== "C:\Users\davidan\AppData\Local\Temp"
>> get-env 'env2

*** Runtime Error 13: integer divide by zero
*** at: 0041A295h

>> get-env  'temp

*** Runtime Error 1: access violation
*** at: 0041A2CBh

dockimbel
02:19@dander It's clearly a bug, except for get-env temp where you are not passing a valid argument. Please open a ticket for it.
dander
03:47red/red#2814
iArnold
21:05No one could reproduce the --no-runtime issue? ... or ... no one cares for creating small executables?
PeterWAWood
21:53I think you misunderstand the --no-runtime option.
21:58If you use it you must provide a replacement for the runtime in your own code. Most people would only use this for compiling code for very small platforms such as Arduino or if they want to write their own operating system,
22:01It just doesn't make sense to me to use the --no-runtime option on a
22:06machine running a mainstream operating system.
22:07Why did you use the --no-runtime option?

ghost~5680c5f416b6c7089cc058a5
03:54@iArnold for --no-runtime, there was this https://github.com/red/red/issues/1772
03:58I am able to atleast compile using --no-runtime though. Maybe you are trying to compile Red files where the --no-runtime expects it to be R/S
03:59From red --help
--no-runtime                   : Do not include runtime during Red/System source compilation.

iArnold
06:01@nc-x Thanks Neelesh! The key word in this is Red/System SOURCE compilation. So when you compile a Red program you will *always* get the runtime included.
ghost~5680c5f416b6c7089cc058a5
06:46@iArnold You are welcome :smile:
06:47@dockimbel Would it be possible for the compiler to give error in case --no-runtime is used with Red source code?
iArnold
09:03Somehow I also thought that because the second step in compiling *is* the compiling of the generated Red/System code, --no-runtime automatically applied to that step.
dockimbel
09:56@nc-x Yes, but it doesn't look like something that needs to be done before a 0.9.x version, if that option still exists by then. ;-)
ghost~5680c5f416b6c7089cc058a5
11:21Well, I am by no means an expert but doesn't writing operating systems and other low level stuff require something like --no-runtime
11:21> if that option still exists by then.
dockimbel
11:23@nc-x What I meant is that such feature might become accessible in a different way, instead of a command-line compilation option, as its usage is not very common.
ghost~5680c5f416b6c7089cc058a5
11:55Oh, thats great! :smile:
iArnold
19:06Most of my programs actually never use the runtime. The majority of programs will never use it I think, yet it will be included in every executable. The compiler directive could be to include it, were it not for the consoles that get compiled so often to justify the current behaviour.
19:07And I still don't get why I cannot get --no-runtime to work for Red sources.
greggirwin
21:47If you're not using the runtime, I assume you're writing Red/System code, in which case, why do you need that feature in Red? I don't understand the problem.

PeterWAWood
06:37@dockimbel The object on-change event is not activated when the value of a word defined in a nested object is changed (or a value in a block in the object is changed).

>> o: make object! [
[    b: [aa 1 bb 2]
[    on-change*: func [w o n] [ print "activated" ]
[    o: make object! [oa: 1 ob: 2]
[    c: 1
[    ]
== make object! [...
>> o/c: 1
activated
== 1
>> o/b/bb: 4
== 4
>> o/o/ob: 4
== 4

Is this the expected behaviour or a bug?
meijeru
06:53Isn't that for on-deep-change* ??
dockimbel
06:55@PeterWAWood on-change is triggered by changed values in the root object only. on-deep-change is what you want (though, IIRC, nested objects needs to be manually "owned" for now using modify).
PeterWAWood
07:17@meijeru @dockimbel Thanks.

iArnold
07:57@greggirwin Because I am curious about what is generated.
It turns out that compiling the script
Red/System []
print "Hello world!"

with --no-runtime results in
*** Compilation Error: undefined symbol: print
07:58So the runtime is getting used in my simple programs, but not all features are used ;-)
PeterWAWood
08:06@iArnold The print function is part of the Red/System runtime. You cannot use it if you want to compile your code without the Red/System runtime.
08:09The Red/System runtime is similar to the C language runtime. (It actually makes use of it as it is pre-installed on Windows, macOS and Linux).
08:10If you're still at a loss, this [stackoverflow answer](https://stackoverflow.com/questions/2766233/what-is-the-c-runtime-library#2766421) might help.
iArnold
08:17Thank you Peter!
greggirwin
16:48Ah, I see your question more now @iArnold, you want to include only the parts you use. That will certainly be possible, and is part of the plan as I understand it, but it's not important right now. When we get to modular compiling and linking, it will be a natural side effect.
iArnold
20:53Indeed @greggirwin and knowing the minimal code generated helps in unraveling the way the sources do their work, so I can understand better what is needed for 64 bit versus 32 bit. ( http://ref.x86asm.net/ http://0xax.blogspot.nl/2014/08/say-hello-to-x64-assembly-part-1.html http://yasm.tortall.net/ and the like)
Because the need to support 64 bit for the desktop increases continuously. If you are going to install a new OS on your desktop it is practically a no-brainer that it will be the 64 bit version. Having the programmers and worse the users of their programs install 32-bit libs on their systems where other languages do have 64 support is so 2017. Similar concern I have is with the Rebol dependency. Rebol.com has been out, so no R2 available for download, and this will probably become a yearly exercise. Selfhosting of Red in my expectation should get a higher priority. For one thing I hope this new release of macOS will be the last one in the series of releases that took up much more time because of the very large scale, and following releases will follow up significantly quicker.
21:04According to Henrik in AltME the High Sierra will be the last release of macOS to support 32 bit, given the current release frequency of macOS of a year avarage, this situation of 32 vs 64 bit is pretty soon an actuality.
greggirwin
21:43The importance depends on the target market. Have to balance appealing to developers with modern machines and the huge number of devices out there that aren't.

iArnold
06:55Last thing you hear me say is to drop 32 bit support ;-) I am only pointing out the upcoming urgency of this issue.
greggirwin
16:11I didn't think you meant that, just that mobile is a higher priority right now, and I think ARM (for example) is maintaining 32-bit instruction compatibility even as they move forward, for now.

Everything is urgent. :^)
iArnold
17:49Mobile priority bugs me yes ;-)

x8x
01:59Can anyone reproduce this issue? https://github.com/red/red/issues/2837
dockimbel
05:28@x8x You should rather post that in red/red as very few people have subscribed to this channel.
rebolek
05:45@x8x @dockimbel I can't repro, because I have troubles compiling Red/View under macOS. I've added Needs: 'View to header but the compilation breaks with error
*** Compilation Error: invalid #call function name: face?
*** in file: /Users/sony/Code/red/environment/console/console.red
*** near: []
06:42@x8x I managed to compile View and tried your example, but cannot reproduce it. I will add comment to GitHub
x8x
10:22@rebolek Could you try this one:
sudo  red
Password:
PROGRAM ERROR: Invalid encapsulated data.
rebolek
10:31@x8x I can reproduce this one
10:32
fakemac:red sony$ sudo red
Password:
PROGRAM ERROR: Invalid encapsulated data.
fakemac:red sony$
dockimbel
10:32@x8x You cannot call sudo directly on a Rebol encapped executable, you need to wrap it in a shell script. Though, we have a generic solution for such issues that will be part of 0.6.4.
rebolek
10:33sudo ./console works
x8x
10:51@rebolek Yes that works. @dockimbel Good to know. Thanks both!
10:52@rebolek What version of macOS are you running?
rebolek
13:18@x8x 10.11.6

9214
16:04
alphabet: {AaBbCc}
replace alphabet #"a" 1
probe alphabet

Results in
"1aBbCc"

It seems that replace is case-insensitive
rebolek
16:05Red is case-insensitive by default. So it's a feature, not a bug ;)
9214
16:06@rebolek it's not that funny :confused: what am I supposed to do?
rebolek
16:07@9214 replaceis function that uses find for matching. find supports /case refinement, so I think that replace should also support it.
9214
16:07@rebolek I thought it does!
>> replace/case
*** Script Error: replace has no refinement called case
*** Where: replace
>> ? replace
USAGE:
     REPLACE series pattern value

DESCRIPTION: 
     REPLACE is a function! value.

ARGUMENTS:
     series       [series!] 
     pattern       
     value         

REFINEMENTS:
     /all         =>
rebolek
16:08It does in Rebol, in Red not yet.
9214
16:08Worth a ticket?
rebolek
16:09Yes, a WISH ticket.
16:13@9214 here you go https://gist.github.com/rebolek/f5731bc1d9234ef15e2d4fe31f4f531f
9214
16:13@rebolek :+1:

9214
12:38Question about [get-arguments](http://www.rebol.com/docs/core23/rebolcore-9.html#section-3.3). In Rebol2:
print-body: func [:foo] [probe second :foo]
print-body print-body

Results in
[probe second :foo]


But in Red it gives me
*** Script Error: second does not allow word! for its s argument
*** Where: second


Turns out in Red :foo in spec is equivalent to 'foo. Why is that?
12:53But this one works as expected
print-func: func [:foo] [probe get/any foo]
print-func print-func
13:11I'm asking because I wanted to implement |> pipe operator. For now user is forced to use get-word! on calling side:
|>: make op! func [x :f] [f x] ; :f could be 'f
[1 2 3] |> :reverse |> :print

Instead I'd like it to be
|>: make op! func [x :f] [f x]
[1 2 3] |> reverse |> print
dockimbel
13:38@9214 In Rebol 2, first, second and third correspond in Red respectively to words-of, body-of and spec-of.
13:39> Turns out in Red :foo in spec is equivalent to 'foo. Why is that?

Compatibility with Rebol3, but actually the Rebol2 behavior might be more useful, so we should change that in the future (there's a ticket for that on github).
9214
13:46@dockimbel what about using get-word! on calling side? Comparing with Rebol2:
REBOL []

pipe: func [x :f] [f x]
pipe [1 2 3] print

Red []

pipe: func [x 'f] [f x]
pipe [1 2 3] :print
dockimbel
13:48Yes, that's a valid workaround.
9214
13:50@dockimbel but IMO Rebol one is more elegant (writing print instead of :print)
13:50:point_up: [3 июля 2017 г., 18:11](https://gitter.im/red/bugs?at=595a427b329651f46e4ab00b)
dockimbel
13:51Yes, I agree. I also think the Rebol2 way is better than Rebol3's for that feature.
9214
13:51Okay, so there's a wish ticket for that already?
dockimbel
13:52There's a ticket for that, but can't remember which one.
9214
13:54https://github.com/red/red/issues/1850 ?
dockimbel
13:55Yes, should be that one.
9214
13:56Alrighty then, thanks Doc!
dockimbel
13:58Welcome. ;-)
9214
16:55The following code:
Red [
    Config: [red-strict-check?: off]
]

#do [
    unfold: function [
        range [block!]
    ][  
        bit: make bitset! range
        len: length? bit
        str: make string! len
        
        repeat i len [if find bit i [append str to char! i]]
        return str
    ]
]

#macro alphabet: func [] [unfold [#"A" - #"Z"]]

probe alphabet

Then interpreted results in:
"ABCDEFGHIJKLMNOPQRSTUVWXYZ"

As expected. But if I try to compile it:
*** Red Compiler Internal Error: Script Error : Invalid argument: -
*** Where: unfold
*** Near:  [bit: make bitset! range
len:
]

Any ideas?
19:37Also, if I'll try to specify named macro without arguments and with some /local words (i.e. has function):
#macro whatever: func [/local some-word] []

*** Macro Error: invalid specification
*** Where: [whatever: func [/local some-word]]
*** Throw Error: no catch for throw: halt-request
*** Where: throw
*** Stack: expand-directives expand
19:41But this one is OK (though basically it's the same as above):
#macro whatever: function [] [some-word:]

PeterWAWood
22:22@9214 The current alpha compiler is build in Rebol. If you want code inside a macro to run in both the interpreter and the compiler, the code must be valid in both Red and Rebol.

There is a [note](https://doc.red-lang.org/en/preprocessor.html#_implementation_note) in the pre-processor docs.
22:25function in Red is equivalent to funct in Rebol 2. function in Rebol 2 takes 3 arguments the second being a list of local words.
22:44The error with #macro whatever: func [/local some-word] [] seems like a bug to me.

9214
05:34@PeterWAWood ah, so Rebol doesn't support [ - ] bitset generation?
greggirwin
06:29@9214, that should be fine. What Rebol doesn't like is function with just two args. For R2 it takes 3: FUNCTION spec vars body
06:30Function is one function that is not Rebol compatible.
dockimbel
06:35@greggirwin @9214 function is redefined in the toolchain to match Red's definition, you can check it by compiling the following code:
Red []
#do [probe :function]
greggirwin
06:35Ah, my mistake. Sorry about that.
dockimbel
06:35The *** Macro Error: invalid specificationerror looks like an issue with the preprocessor macro validation code.
9214
06:52I've rewrite unfold as func just for sanity check but error still persist. Rebol2 actually supports charset generation, so now I'm confused :confused:
06:57I even reinvented the naive charset wheel, and now error message is even more cryptic:
Red []

#do [
    charset: func [
        range [block!]
        /local
        bs blk start bump
    ][  
        bs: make bitset! copy []

        while [not tail? range] [
            blk: head remove at take/part range 3 2
            start: to integer! blk/1
            bump:  to integer! blk/2
            
            while [start <= bump] [
                bs/:start: on
                start: start + 1
            ]
        ]

        return bs
    ]

    unfold: func [
        range
        /local
        bit len str
    ][  
        bit: charset range
        len: length? bit
        str: make string! len

        repeat i len [if find bit i [append str to char! i]]
        return str
    ]
]

probe #do keep [unfold [#"A" - #"Z"]]

*** Red Compiler Internal Error: Script Error : Invalid argument: '00000041
*** Where: charset
*** Near:  [start: to integer! blk/1
bump:
]
07:06@dockimbel :point_up: [4 июля 2017 г., 11:35](https://gitter.im/red/bugs?at=595b374fbf7e6af22c9fbc47) should I fill a ticket?
dockimbel
07:12@9214 Yes, please.
9214
07:13Roger! I'll tackle with unfold for a while.
08:48Okay, here's the trick. This one works flawlessly:
Red []

#do [
    unfold: func [
        range [block!]
        /local
        index bump blk
    ][  
        to string! collect [
            while [not tail? range] [
                blk: head remove at take/part range 3 2
                forall blk [poke blk 1 to integer! to char! blk/1]
                set [index bump] blk
                
                until [keep to char! index (index: index + 1) > bump]
            ]
        ]
    ]
]

view [text #do keep [unfold ["A" - "Z"]]]

But on this one compiler (preprocessor?) chokes up (while interpreter works fine):
Red []

#do [
    unfold: func [
        range [block!]
        /local
        index bump blk
    ][  
        to string! collect [
            while [not tail? range] [
                blk: head remove at take/part range 3 2
                forall blk [poke blk 1 to integer! blk/1]
                set [index bump] blk
                
                until [keep to char! index (index: index + 1) > bump]
            ]
        ]
    ]
]

view [text #do keep [unfold [#"A" - #"Z"]]]

*** Preprocessor Error in #do
*** Script Error : Invalid argument: '00000041
*** Where: [#do]
*** Near:  [forall blk [poke blk 1 to integer! blk/1]
set [index bump]
]

The only difference is that in first example I use string!s in range block and explicitly convert them to char! and then to integer!, while in the second case this conversion is avoided because I use chars! as usually.
09:12Also
probe #do keep ["1 2 3"]       ;== "1 2 3"
probe #do keep [[1 2 3]]       ;?? 1

; crude workarounds
probe load #do keep ["1 2 3"]  ;== [1 2 3]
probe #do keep [[[1 2 3]]]     ;== [1 2 3]

Maybe it's worth to create /only refinement (i.e. #do keep/only) for such cases?
09:18Same with named macro
11:36I feel like a Starship Trooper today :bug: (sorry if it looks too obtrusive!)
|>: make op! func [x 'f] [f x]

[1 2 3] |> :reverse |> :print

Result in
*** Compilation Error: invalid path value: intrinsics/func*
*** in file: <snip>
*** at line: 332
*** near: [
    get-word/get ~reverse
    intrinsics/func*
    stack/unwind
    get-word/get ~print
    intrinsics/func*
    stack/unwind
]
11:48:bug: :gun: currently I'm working on some hash decoding algorithm which involves a lot of bit-twiddling trickery, so, for the sake of simplicity, I've defined some shortcuts (in the same context where this operations are used):
&: :and
|: :or
~: :complement

So, the thing is - this one compiles:
&: :and
|: :or
~: :complement

complement 100 and 200 or 300

This one crashes:
&: :and
|: :or
~: :complement

~ 100 & 200 | 300

*** Compilation Error: invalid path value: ops/&*
*** in file: <snip>
*** at line: 332
*** near: [
    integer/push 200
    ops/&*
    stack/unwind
    integer/push 300
    ops/|*
    stack/unwind
]
11:54Workaround:
bit-twiddling: context [
    &: :and
    |: :or
    ~: :complement
]

complement 100 and 200 or 300
do bind [~ 100 & 200 | 300] bit-twiddling
dockimbel
12:54@9214 You're hitting on some interesting edge cases there, will review that in detail after I merge the date! type branch.
9214
13:07@dockimbel good! Should I fill some tickets for you? Though I'm not sure which of the three reported issues (unfold macro, |> weirdness, and bit-twiddling crash) are worthy and what exactly I should write in description :(
dockimbel
13:07@9214 No need until I get a chance to review it in detail.

9214
17:40[![Starship-Troopers.jpg](https://files.gitter.im/red/bugs/N3tm/thumb/Starship-Troopers.jpg)](https://files.gitter.im/red/bugs/N3tm/Starship-Troopers.jpg)

Red []

context? 'context?

Compiling to native code...
*** Compilation Error: undefined symbol: red/natives/context?*
*** in file: <snip>
*** at line: 332
*** near: [
    natives/context?* true
    stack/unwind #user-code
]

PeterWAWood
09:31@dockimbel It looks as there is a formatting error when molding dates:
>> a: 1/1/0000
== 1-Jan-0000
>> b: 1/1/0001
== 1-Jan-1000
>> b/year
== 1
09:33Also:
>> a: a - 1
== 31/Dec/-100
>> a/year
== -1
dockimbel
09:34@9214 About the context?error, did you compile in dev mode (using libRedRT) or in release mode? Worth a ticket for a deeper look anyway.
9214
09:34@dockimbel I think in dev mode
dockimbel
09:34@PeterWAWood Odd, will fix that now.
9214
10:11
#do [foo: does [1 % 1]]
#macro make-some-foo: func [][foo]

probe make-some-foo

...using libRedRT built on 6-Jul-2017/15:05:21+5:00
*** Red Compiler Internal Error: Script Error : % has no value
*** Where: foo
*** Near:  [% 1]



Changing % to mod works
#do [foo: does [mod 1 1]]
#macro make-some-foo: func [][foo]

probe make-some-foo
dockimbel
10:14@9214 Compile-time macros are run by the Rebol interpreter (which powers our toolchain), the % character alone is invalid syntax in Rebol, so you need to either use // or mod in that case.
9214
10:14@dockimbel oh, right, thanks!
10:22Regarding |> crash, it seems that binding block of code to some context fixes it (as with | & ~ shortcuts issue)
|>: make op! func [x 'f][f x]

do bind [[1 2 3] |> :reverse |> :print] system/words
dockimbel
10:25That's odd, as by default those words are bound to global context (aka system/words).
iArnold
11:33Is this correct behaviour? Latest sources used.
>> block1: [12uifehwiguhig] 
*** Syntax Error: invalid integer! at "12uifehwiguhig]"
*** Where: do
*** Stack: load
PeterWAWood
11:42Yes it is. The contents of a block need to be loadable so they must be valid values. The contents of a block are not evaluated upon loading (which is why you can include words which are not bound to a value in a block).
11:43Try it in Rebol and you'll get a similar error message.
xqlab
11:52
>> 1/1/001
== 1
>>  probe 1/1/010
1-Jan-2001
== 0

latest version
dockimbel
11:54@xqlab
>> [1/1/001]
== [1-Jan-2000 1]
11:55It's parsed correctly, just missing an extra rule to avoid such sticky integers and return an error to block a confusing syntax.
iArnold
13:18@PeterWAWood Thank you for the explanation.

PeterWAWood
06:51@dockimbel You can set the time of a date to an integer!. Though doing so seems to adjust the time rather than set it. Shouldn't this raise an error as does Rebol?
>> d: now
== 7-Jul-2017/14:46:37+08:00
>> d/time: 1
== 1
>> d
== 7-Jul-2017/6:46:01+08:00
>> d/time: -10
== -10
>> d
== 6-Jul-2017/22:46:50+08:00
dockimbel
06:53@PeterWAWood Good catch.
06:53BTW, random on dates seems broken.
PeterWAWood
06:59@dockimbel Setting the 'date/time to a negative time also appears to give incorrect results. Perhaps it should also raise an error? text
>> d: now
== 7-Jul-2017/14:56:24+08:00
>> t: -24:00
== -24:00:00
>> d/time: t
== -24:00:00
>> d
== 6-Jul-2017/0:00:00+08:00
`
dockimbel
07:00No, that's correct, and it's a needed feature, otherwise you cannot do arithmetics using /time. Rebol behaves the same (for same reasons).
07:04The previous issue with setting /time to an integer is fixed now.
PeterWAWood
07:09Is there a definition of the result of setting the time of a date to a negative value that could be included in the Docs?

It seems that the result of doing so is to subtract one day from the date and then set the time to 24:00 plus the negative time value supplied.
dockimbel
07:11@PeterWAWood Setting time to a negative value means counting time backwards from the same day, starting at 0:00:00. So -24:00 will give you same time (0:00:00), but minus one day.
PeterWAWood
07:14Thanks for the explanation.
dockimbel
07:15BTW, I'm currently writing a doc for date! (while it's all still fresh in my mind).
meijeru
08:18Should the two bugs mentioned above not be formulated as issues (setting time in date to integer, and random being broken)?
dockimbel
08:21@meijeru No need, the first one has been fixed already and I posted the second one, which means I have it on my todo-list already.

Oldes
12:44@dockimbel reading the date! documentation, this was the first thing I tried:
>> d: 31/Dec/32767
== 7
>> d
== 31-Dec-3276
12:54Also:
>> probe 28-Feb-0341 probe 28-Feb-341
28-Feb-0341
28-Feb-2034
== 1
12:55In Rebol2 it is possible to write:
>> 28-Feb-341
== 28-Feb-0341
dockimbel
14:15@Oldes Issue fixed. 3-digit years now allowed.

9214
08:30:point_up: [4 июля 2017 г., 16:48](https://gitter.im/red/bugs?at=595b808976a757f808d50417)
Surprisingly
set '& get 'and
set '| get 'or

Compiles. @dockimbel I'm sorry to bother you, you'll get a chance to review all of this in more detail after 0.6.3 launch, right?
dockimbel
08:30@9214 Right, thanks for your understanding.
9214
08:36Another report:
entry: [a b c]
foreach :entry [1 2 3 4 5 6 7 8 9][
    print [a * 2 b * 3 c * 4]
]

Interpreted
2 6 12
8 15 24
14 24 36

Compiled
...using libRedRT built on 6-Jul-2017/15:05:21+5:00
*** Red Compiler Internal Error: Script Error : add-symbol expected name argument of type: word
*** Where: comp-foreach
*** Near:  [add-symbol word: pc/1
add-global word
]
08:39And some inconsistency in while behavior, it always returns unset no matter what.
I expect it to return last evaluated expression like with other iterators.
probe while [true][break/return 42] ; unset vs. 42
i: 1 probe while [i < 5][i: i + 1]  ; unset vs. 5
08:40Workaround is to wrap while loop in catch/throw
probe catch [while [true][throw 42]]
i: 1 probe catch [
    while [i < 5][
        i: i + 1 
        if i = 5 [throw i]
    ]
]
08:46@dockimbel keep up the good work! But do you mind if I fill the tickets? I worry that we will forget everything that I wrote here :( (+ weird behavior with macro inclusion :point_up: [6 июля 2017 г., 02:28](https://gitter.im/red/red?at=595d59fa3230e14f3a2c3da6))
dockimbel
08:47@9214 Please go on with adding tickets.
9214
08:47:muscle:
dockimbel
09:06:sweat_smile:

PeterWAWood
00:11When the time of a date is 0:00, mold ignores it. This makes sense when the user sets only the date (with no time) but not when a date is being incremented.
>> d: 2016-11-23/23:57
== 23-Nov-2016/23:57:00
>> loop 6 [print d: d + 0:01]
23-Nov-2016/23:58:00
23-Nov-2016/23:59:00
24-Nov-2016
24-Nov-2016/0:01:00
24-Nov-2016/0:02:00
24-Nov-2016/0:03:00

Rebol2 treats dates with a 0:00 time differently and also has a '/date' refinement to display dates without the time:
>> d: 2013-11-23/0:00
== 23-Nov-2013/0:00
>> e: 2013-11-23     
== 23-Nov-2013
>> d/date
== 23-Nov-2013

00:26The date! docs suggest that any of the "ordinal" paths can be used with pick. However, trying to pick 12 (week) or 13 (isoweek) gives a script error:
>> e: 2017-11-23/0:00
== 23-Nov-2017
>> pick e 12
*** Script Error: value out of range: 12
*** Where: pick
*** Stack: 
>> pick e 13
*** Script Error: value out of range: 13
*** Where: pick
*** Stack: 
>> e/12
== 47
>> e/13
== 47
00:26Let me know if the docs need changing and I'll do it.
00:29Large dates suffer from integer overflow when converting to epoch time:
>> f: 9999-12-24
== 24-Dec-9999
>> to integer! f
== -1460864
dockimbel
03:37@PeterWAWood Funny that I forgot to implement /date accessor. :smile:
03:40@PeterWAWood The Unix epoch time is not defined beyond [year 2038](https://en.wikipedia.org/wiki/Year_2038_problem).
03:42For the zero time displaying, we should be able to support that too.
greggirwin
03:46Do we need "commonly used" in the first sentence of the docs? There's no special meaning there, correct? Just that date values are common.
dockimbel
04:14@greggirwin Correct. Maybe represent calendar dates would be better?
greggirwin
04:26Agreed. I'll make the change.
04:57Playing with setting negative days and months, and out of range args.
== 1-Jan-2017
>> d/month: -1
== -1
>> d
== 1-Nov-2016
>> d/month: 1
== 1
>> d
== 1-Jan-2016
>> d/month: 2
== 2
>> d
== 1-Feb-2016
>> d: 31-jan-2017
== 31-Jan-2017
>> d/month: 2
== 2
>> d
== 31-Feb-2017
>> d: 31-feb-2017
*** Script Error: cannot MAKE/TO date! from: [day month year]
*** Where: do
*** Stack: load
dockimbel
04:59@PeterWAWood pick issue fixed.
greggirwin
05:03Is there a good reason to support out of range months? Things can get tricky, and unpredictable. Common needs like last-day-of-month and same-day-next-month can wrap behavior to some extent. I don't know a good reference offhand, since this isn't just basic date math, but design.
dockimbel
05:04@greggirwin Without support for out-of-range values, we cannot do any math on date fields (except for days, as we can do <date> + <days>). The result should always be normalized, so this is not an issue. Same as in Rebol.
greggirwin
05:07Just thinking about how best to explain it, since the results are counterintuitive.
dockimbel
05:07Here's an example:
>> last-day-of-month: func [d][d/month: d/month + 1 d/day: 1 d - 1]
== func [d][d/month: d/month + 1 d/day: 1 d - 1]
>> last-day-of-month now
== 31-Jul-2017/13:06:56+08:00
greggirwin
05:07
>> d: 1-jan-2017
== 1-Jan-2017
>> d/day: 32
== 32
>> d
== 1-Feb-2017
>> d/day: -1
== -1
>> d
== 30-Jan-2017
dockimbel
05:08@greggirwin IIRC, Rebol/Core Manual doesn't try to explain it beyond that you can do math with date fields and get a correct resulting date.
greggirwin
05:08Yes, I have almost that exact func as well.
dockimbel
05:09The current docs I write are "reference documentation", so they aim at describing exhaustively the datatype's features. A tutorial and/or User Manual should present things differently.
greggirwin
05:11I'm adding some examples as I go through it, to help clarify. The month example above, creating a bad date, was what caught my eye. Other things I've checked against R2 and make sense.
dockimbel
05:11
lisp
>> d: 1-Feb-2017
== 1-Feb-2017
>> d/day: 1
== 1
>> d
== 1-Feb-2017
>> d/day: 0
== 0
>> d
== 31-Jan-2017
greggirwin
05:12Right. The 0 gap.
dockimbel
05:12> The month example above, creating a bad date

It's a bug, I'm fixing it.
greggirwin
05:13Great. Thanks!
dockimbel
05:14Fixed. FYI, the GUI console seems to be broken currently because of a recent commit from Qingtian, but the CLI console is fine.
11:45@PeterWAWood This is what you can do in Red now:
>> d: 2016-11-23/23:57
== 23-Nov-2016/23:57:00
>> loop 6 [print d: d + 0:01]
23-Nov-2016/23:58:00
23-Nov-2016/23:59:00
24-Nov-2016/0:00:00
24-Nov-2016/0:01:00
24-Nov-2016/0:02:00
24-Nov-2016/0:03:00
>> d/time: none
== none
>> d
== 24-Nov-2016
>> loop 6 [print d: d + 0:01]
24-Nov-2016/0:01:00
24-Nov-2016/0:02:00
24-Nov-2016/0:03:00
24-Nov-2016/0:04:00
24-Nov-2016/0:05:00
24-Nov-2016/0:06:00
12:02I had to use 1 bit in the date! value slot for the time presence flag, so the range for years is reduced to -16384 to 16383.
PeterWAWood
12:14Great! I don't think many people will worry about the reduced date! range.
x8x
16:33
1-1-10000
*** Syntax Error: invalid date! at "10000"
*** Where: do
*** Stack: load 
  31-12-9999 + 1
;   1-Jan-10000
meijeru
17:08That is not a bug, it is a feature :smile:
dockimbel
17:09@x8x From the date doc:
> Supported dates range from 1/Jan/-16384 to 31/Dec/16383, wrapping around on overflowing math operations. On input, that range is reduced to 1/Jan/-9999 to 31/Dec/9999 for practical reasons.
x8x
17:10Thanks, so I can input dates till 9999 but I can do maths on years till 16383, correct?
dockimbel
17:10Right.
x8x
17:10Perfect thx!

Oldes
10:35@dockimbel compile this script with -t Windows and press the button... the application quits:
Red [Needs:	 'View]

view [
	button "Press me" [print "pressed"]
]
10:37That is the reason why view-test.red script does nothing when compiled with -t Windows and not -d.
dockimbel
10:41From red/help:
> Yes, -t Windows redirects the standard output to the GUI console, which is not (yet) part of the runtime. So the app then silently fails to run.
PeterWAWood
10:42@dockimbel I ran the tests, latest master, under Windows 10 and got a failure:
--test-- libWin32-1 FAILED**************

geekyi
11:03Just so it doesn't get lost, posted on red/help channel :point_left: [July 14, 2017 12:56 AM](https://gitter.im/red/help?at=5967d06ebf7e6af22cd64b22)
PeterWAWood
11:04@dockimbel If I change line 30 of the %lib-win32-test.reds from
lw1-len/int: 15

to
lw1-len/int: 16

the test passes on Windows10.
11:06(I found this out because after the call to get-computer-name, lwl-len/int had been set to 16).
dockimbel
11:15@PeterWAWood Good catch!
PeterWAWood
11:16@dockimbel Should I update the test ?
dockimbel
11:16@PeterWAWood Yes, please.
PeterWAWood
11:18Done

Oldes
09:33@dockimbel I'm trying to find out, why bass-test.red from Red/Code is not working and found strange behavior.... with this code:
#define BASS_FETCH_OPT_NAMED_VALUE(type) [
			pos: cmd + 1
			if pos < tail [
				value: either TYPE_OF(pos) = TYPE_WORD [_context/get as red-word! pos][pos]
				if TYPE_OF(value) = type [cmd: pos]
			]
		]
		#define BASS_FETCH_OPT_SETTINGS(blk ms) [
			blk: null
			BASS_FETCH_OPT_NAMED_VALUE(TYPE_BLOCK) 
			print-line [pos " " cmd " " blk]
			if pos = cmd [
				blk: as red-block! value
			]
			print-line ["blk: " blk]
		]

I get this result:
028ED348 028ED338 00000000
blk: 029119A8

any idea how it is possible?
09:33notice that pos <> cmd
09:54Similar result when I include content of the BASS_FETCH_OPT_SETTINGS directly into the code. Simply pos = cmd is true even when the values are different.
10:48To be more precise.. pos = cmd is false, but if block is evaluated anyway.
PeterWAWood
10:53@Oldes I don't think that either returns a value in Red/System. So you will get some unpredictable results with:
value: either TYPE_OF(pos) = TYPE_WORD [_context/get as red-word! pos][pos]
Oldes
10:53it was working.
PeterWAWood
10:56@Oldes It looks as though it does now support returning a value.
10:57(I must try to keep up with the times).
dockimbel
10:59@PeterWAWood either can return a value (for setting a variable or returning from a funciton), but either should not be used nested in expressions otherwise.
Oldes
10:59It looks that the if/either is somehow corrupted... I had similar case... using:
#define BASS_FETCH_OPT_NAMED_VALUE(type) [
			pos: cmd + 1
			print-line [(pos < tail) " " pos " < " tail]
			either pos < tail [
				value: either TYPE_OF(pos) = TYPE_WORD [_context/get as red-word! pos][pos]
				print-line [(TYPE_OF(value) = type) " " TYPE_OF(value) " = " type]
				if TYPE_OF(value) = type [cmd: pos]
			][
				print-line "?"
			]
		]

I get:
true 0285D348 < 0285D368
?
dockimbel
11:05@Oldes That's odd, never seen similar behavior before. I would bet on something else in your code having a side-effect. Does it work if you inline manually the macros?
11:08In %system/compiler.r, at line 3885, just before compiler/run job src file, you can add a write %src.reds src and examine the output of the preprocessor.
Oldes
11:13I will check it.. but I have limited time now.
11:22Used save %src.reds src (to have it readable :) but see nothing suspicious there.
11:32When I compile the bass-test.red with version of Red from 04/03/2017, it is working I will try to find the last working commit. Later.
12:59@dockimbel I found it... this is the commit which is causing above mentioned issue: https://github.com/red/red/commit/6f89becc879a1d3e8775196273b95fb704298adf
13:08And just for a test, I replaced in my code lines like:
value: either TYPE_OF(pos) = TYPE_WORD [_context/get as red-word! pos][pos]

to:
either TYPE_OF(pos) = TYPE_WORD [value: _context/get as red-word! pos][value: pos]

but the result is still the same.
dockimbel
13:15@Oldes I would need a simple way to reproduce it. Could you please open a ticket for it, with the minimal code you can come up with that shows the error?
Oldes
13:15That will not be an easy task:/
dockimbel
13:16Just remove everything that is not in the code path/branch of the issue.
Oldes
13:16And you have bass.dll?
13:17I will try it.
dockimbel
13:17No, but it doesn't look like it's needed to reproduce this issue, is it?
13:17Anyway, it won't make it in 0.6.3 release.
Oldes
13:18what about revert the commit which made this issue?
dockimbel
13:19Reverting such commit will likely create regressions, so no.
Oldes
13:22Reverting it just resolves the current invalid behavior... if I understand the commit well, it was used just to provide compiler detection and error reporting for nested assignment.
dockimbel
13:25I don't want to take any risk when the new release is imminent, nor do I want to retest everything manually again on all platforms.
Oldes
13:25But then you are providing very odd version, because this is really odd. But true is, that there is not many users who would notice it.
dockimbel
13:27I don't want to delay the release for 24h more because of that. The 90k LOC of R/S in the runtime seem to be unaffected by this issue, so there's no urgency.
Oldes
16:22@dockimbel here it is: https://github.com/red/red/issues/2893
raimundasa
17:52A refinement request-dir/dir does not work properly if an argument is a string. A starting directory always is user`s home directory. My system is Windows 8.1
greggirwin
20:39Confirmed. It looks the same for request-file/file. Both internal funcs (OS-request-dir/OS-request-file) look like they may have been written for file support, and strings were added to the func spec later, without them being updated. They coerce file! values to OS-local format, but don't seem to prime pbuf if it's a string.

PeterWAWood
02:04When compiling tests under FreeBSD32, libRedRT fails to compile:

-=== Red Compiler 0.6.3 ===- 

Compiling /mnt/Red/red/tests/source/runtime/unicode-test.red ...
Compiling libRedRT...
...compilation time : 792 ms

Compiling to native code...
*** Compilation Error: invalid path value: image/encode 
*** in file: %environment/codecs/png.red 
*** in function: exec/ctx259~encode
*** at line: 1 
*** near: [as cell! image/encode img where IMAGE_PNG]
02:07runtime/tools-test.reds fails to compile under FreeBSD32:
-=== Red Compiler 0.6.3 ===- 

Compiling /mnt/Red/red/tests/source/runtime/tools-test.reds ...

Target: FreeBSD 

Compiling to native code...
*** Compilation Error: #export directive requires a library compilation mode 
*** in file: %start.reds 
*** at line: 67 
*** near: [
    #export [environ __progname]
]
iArnold
11:35And if you fix that there will be other errors ahead, I did some investigations a while ago: https://github.com/reddoc/develop/wiki/DEV-GOAL-FreeBSD-support

iArnold
07:27Testing for virusses of the simplest Red [] Print "Hello World" program created with 0.6.3 release on
https://www.virustotal.com results in positives for:
Virusscanner Result Version
Avira (no cloud) TR/Crypt.XPACK.Gen2 20170720
CrowdStrike Falcon (ML) malicious_confidence_60% (D) 20170710
Cylance Unsafe 20170720
Endgame malicious (moderate confidence) 20170713
Invincea heuristic 20170607
Qihoo-360 HEUR/QVM20.1.9ABE.Malware.Gen 20170720
(eScan AV is not included in the tests)
13:16eScan seems to have changed something, my program now is allowed to run again.
greggirwin
17:21Thanks for testing that Arnold.
kermitaner
18:40
Red[]
m: make map!["a" 1 "b" 2 "c" 3]
foreach k keys-of m[probe k]
18:42its giving me an error when compiled , target dos, win 10, "entry point exec/f_words-of" not found in dll, values-of is working correctly, using latest build for windows
greggirwin
18:48Are you compiling in release mode? Maybe an old libRedRT on your system?
kermitaner
18:51libredRT was built new, it was the first compile on my new machine
18:57ok, its working now, compiled again with -r flag, sorry
greggirwin
18:58If I compile in release mode, it works here.
19:02If I compile with -u, the compile completes fine, but then gives the same error you posted. Please open a ticket.
kermitaner
19:03ok, my first one :smile:
greggirwin
19:04Congratulations! :^)
19:07Looks like an aliasing issue on keys-of. If you change that to words-of, it works fine.
kermitaner
19:10ah, thanks, i'll use that, ticket opened :)
greggirwin
19:10Thanks!

raimundasa
21:45A behavior of a code snippet on the paragraph 10 (Red/View Graphic Engine) is strange. If I click "Change" text-list data not changes. But if I click any Name and then click "Change", it substitutes to lowercase "john"
greggirwin
21:52Should do this instead?
view [
    list: text-list data ["John" "Bob" "Alice"]
    button "Add" [append list/data "Sue"]
    button "Change" [lowercase list/data/(list/selected)]
]
21:53If so, I agree.
22:13Updated.

9214
02:24Good morning gentlemen :shipit:
Red []

case []

Results in:
Compiling to native code...
*** Compilation Error: datatype not allowed
*** in file: %<snip>
*** at line: 332
*** near: [none
    either logic/true? none [stack/reset none/push-last]
    stack/unwind #user-code
]

02:28Another tricky bug which boils down to something like this:

my-ctx: context [
    my-other-ctx: context [
        f: func [c][
            object [x: 100 * c y: 100 / c]
        ]
    ]

    foo: func [c][my-other-ctx/f c]
]

probe my-ctx/foo 3

view []

my-ctx/foo should always return object! and that's exactly what happening in interpreter:
make object! [
    x: 300
    y: 33
]

But If I'll compile this script and launch app, my-ctx/foo for some reason returns 3.
02:34Another example which is more similar to my original situation:
with: func [
    contexts [block!]
    body     [block!]
][  
    forall contexts [bind body reduce first contexts]
]

my-ctx*: context [
    my-other-ctx: context [
        f: func [c][
            object [x: 100 * c y: 100 / c]
        ]
    ]

    some-other-ctx: context [field: 'whatever] ;<-- if I'll comment out this line compiled app will silently crash
    
    foo-body: with [some-other-ctx][my-other-ctx/f c]
    foo: func [c] foo-body
]

probe my-ctx*/foo 3

view []

Again, in interpreter it's good ol' object!, but once compiled probe returns
func [c][some-other-ctx]


Alternatively, if I wrap up my-ctx*/foo 3 call inside view block like this:
view [do [probe my-ctx*/foo 3]]

I'll get object! in interpreter (as usual), and, uhm, object! in compiler, but not the one I expected
make object! [
    field: 'whatever
]

02:41Further if I want to access, say, x field of returned object! I'll get an error, since there's no x field! (because it's not *that* object) :(
04:33
ctx: context [
    ctx*: context [
        ok?: func [x][yes]
    ]

    foo: func [thing][
        case [
            not ctx*/ok? thing [return "UNNACEPTABLE!"]
        ]
    ]
]

...using libRedRT built on 22-Jul-2017/7:13:40+5:00
*** Compilation Error: CASE is missing a value
*** in file: <snip>
*** near: []
04:35Alternatively:
ctx: context [
    ctx*: context [
        ok?: func [x][yes]
    ]

    foo: func [thing][
        if not ctx*/ok? thing [return "UNNACEPTABLE!"]
    ]
]

...using libRedRT built on 22-Jul-2017/7:13:40+5:00
*** Compilation Error: expected a block for IF-BODY instead of word! value
*** in file: <snip>
*** near: [thing [return "UNNACEPTABLE!"]]
04:36With ok? moved out of inner context everything works fine.
dockimbel
05:28@9214 Please log those findings into new tickets, so we can process them when possible.
9214
05:29@dockimbel yessiree!
06:46I expected it to spit out generic syntax error (I know that it should be valid hex color)
view [backdrop #itscrash]

*** Runtime Error 1: access violation
*** at: 0042535Dh
dockimbel
06:47@9214 Good catch! Please fill a ticket for it, will fix it today.

raimundasa
09:42@greggirwin
view [
    list: text-list data ["John" "Bob" "Alice"] select 1
    button "Add" [append list/data "Sue"]
    button "Change" [lowercase pick list/data list/selected]
]
xqlab
10:51
>> wait  0:10:0
== none

wait does not wait for specified time
11:16wrong time
Rebol
>> help system/version
SYSTEM/VERSION is a tuple of value: 2.7.8.4.2
>> now
== 25-Jul-2017/13:13:52+2:00
>>


--== Red 0.6.3 ==-- 
Type HELP for starting information. 

>> now
== 25-Jul-2017/12:14:17+01:00
>>
11:18It seems summertime saving is not considered
9214
11:37@dockimbel Doc, can you give any ETA on https://github.com/red/red/issues/2910 or give a tip on how to bypass it? I'm asking because this unpleasant bug prevents me from using compiled app and my attempts on refactoring and full rewrite did not lead to anything :(
geekyi
11:38@9214 foo: func [c][do [my-other-ctx/f c]] helps? In general, if there is a compiler error with function, that instead runs the function in an interpreter
9214
11:39@geekyi which func exactly? I start to remember something among this lines in compiler vs. interpreted behavior...
11:42no, wrapping my-ctx/foo 3 in do block doesn't help
11:44@geekyi oh, I see your edited message
11:45:O yes! Thanks a bunch @geekyi !
12:00and now I have no idea where to insert this do
PeterWAWood
12:07@9214 If you insert do [ straight after the Red header and ] at the end of your code, the whole program will be compiled to be interpreted. The compiler will still give you a single binary executable to run. When it runs the code will be interpreted by the Red runtime.

We use this "crude" method to create interpreter tests for Red.
9214
12:11cheers to @PeterWAWood and @geekyi :beers: ! I thought I'll go nuts sooner or later :smile:
12:14Sigh... I'll probably go nuts, compiled app got detected by AV
12:14[![изображение.png](https://files.gitter.im/red/bugs/orqF/thumb/___________.png)](https://files.gitter.im/red/bugs/orqF/___________.png)
dockimbel
12:16@xqlab wait issue confirmed, a recent regression, will be fixed in a few minutes.
12:18@9214 Could you please report it as false positive to Avast? You can always check against other AV using: http://virustotal.com
9214
12:18@dockimbel sure thing!
12:40Compiled with -c -r -t Windows app can't be launched - View window just never pops up.
12:40:point_up: [25 июля 2017 г., 17:11](https://gitter.im/red/bugs?at=5977357689aea4761dd14349)
dockimbel
12:41@9214 -c and -r are contradicting options, should be either one or the other. When compiled with -t Window, you give up on having a console, so any output attempt using print or probe will result in the app quitting. Or it could just be your AV preventing the executable from launching.
9214
12:42if I want to compile self-contained exe which I want to share with users, should I use -r?
dockimbel
12:43@9214 Yes, -r is for compiling in release mode, so a self-contained exe.
9214
12:44Thanks for pointing out probe and print, I think I forgot to remove them after debugging :D
dockimbel
12:49@9214 We'll try to improve that in the next release.
9214
13:38@dockimbel I've re-checked source code, it seems that app compiled with -r flag silently crashes (console window blinks for a second and disappears).
13:43just out of curiosity tried to run compiled exe on old Win XP machine and got
Entry point in procedure GetGestureInfo not found in DLL USER32.DLL
13:48Same with -c flag. Though I can try to compile without -t Windows... Edit: nope, still the same error.
13:55Okay, only standard compilation with -c flag from VSCode produces working executable, compilation with other options (-o, -r, and -t Windows) doesn't work.
14:10Gosh, turns out exe compiled with -r -t Windows -o ... works *only if* all .red scripts are present in the same directory... is it because of do/expand workaround?
dockimbel
14:11@9214 There is a WindowsXP compilation target.
14:13@9214 Possible, if you do the other .red script at runtime, if you include them it should work, though #include in Red is still limited for now.
9214
14:13@dockimbel right, but what should I do if I want a *real* self-contained app? :( :point_up: [25 июля 2017 г., 19:10](https://gitter.im/red/bugs?at=5977513d714ea96f781f088a)
If I throw away do/expand then #2910 pops up.
14:14
do/expand [
    #include %decoder.red
    #include %injector.red
    #include %gui.red
]

Doesn't work. Should I do them instead?
dockimbel
14:17@9214 do/expand [#include ] does not work?
9214
14:17@dockimbel no, and neither do [do do ...]
14:18app works only if I place exe among all needed scripts
dockimbel
14:20@9214 Sounds logical, do will load files at run-time, so the exe location matters.
9214
14:21Sigh, I'm doomed :(
dockimbel
14:23You should include those files directly if you want them embedded in your exe, putting them in a block with a do/expand postpones their processing to run-time.
9214
14:24@dockimbel you mean copy-paste everything in one script and wrap this big chunk of code into do/expand?
14:25do/expand needed (or not?) because there's macros
14:31Hooray, it seems to work like that!
dockimbel
14:32@9214 No the opposite, no wrapping it with a do. The compiler resolved macros already, do/expand will preprocess and evaluate the argument block at run-time, though, the compiler should have expanded the macros in the block before, unless there are hidden behind an include, and as #include is rather limited currently...
9214
14:34@dockimbel thanks a lot for your guidance, I appreciate that. Will this compile limitations be throwed away on the road to 1.0? Because, frankly, working with interpreted Red was *very* joyful experience, but then it comed to compilation... yikes, my arse still hurts :fire:
14:37:point_up: [25 июля 2017 г., 19:32](https://gitter.im/red/bugs?at=5977567245fc670746c61912) to clarify, I copy-pasted all scripts into one big blob and wrapped it up inside do/expand, so far exe is trully self containted.
dockimbel
14:38@9214 By mixing compile-time preprocessing with run-time preprocessing and limited #include capabilities, you are jumping right in the middle of uncharted behaviors. I don't think anybody tried such mix until now. Given how young is the preprocessor and the various compiler rough edges, you should be going there step by step, so we can identify bugs and limitations one by one and fix or workaround them.
14:42You need to give me the time to process the tickets you opened recently about the preprocessor and includes. That would probably clear up most of your issues.
9214
14:45Sure thing, no pushing here! I just badly wanted this compiled exe, otherwise whole project of mine is useless.
dockimbel
14:47@9214 You can send me an archive with whole sources in private message if you want, so I can have a more global look at what is going wrong.
greggirwin
16:43With R2, the preprocessor (or Ladislav's include) let you bundle all your scripts into one for encapping. The downside, of course, is that then you need a main script to do the build. Not hard, but not as easy as just running interpreted. Here is where we can build tooling to help, but need to think about notations. With R2, I sometimes had multiple build scripts (bundle, encap, encap for distro on CD, build for IOS).
16:43What matters, then, is the notation we use for tooling. e.g., can tools safely find all do instances and handle them.

geekyi
11:42
red
Red []
print unset ; doesn't work but prints error after eval next line (4 + 2)
print 4 + 2
11:43Example in gui console (have to run from file):
6
*** Script Error: unset does not allow unset! for its word argument
*** Where: unset
*** Stack:
9214
11:43@geekyi
>> print unset
*** Script Error: unset is missing its word argument
*** Where: unset
*** Stack:  

>> print 4 + 2
6
11:43
>> system/version
== 0.6.3
>> system/build/date
== 25-Jul-2017/14:54:28+05:00
maximvl
11:44@geekyi this is correct, unset expects argument so evaluation goes to the next thing which is print 4 + 2
geekyi
11:44@9214 I'll have to check with latest version also, using stable 0.6.3
maximvl
11:44it prints the result and returns unset! which becomes argument for unset and then fails
geekyi
11:45@maximvl silly me! I was wondering why print [unset] was working fine
9214
11:45so it's unset unset?
maximvl
11:46do not believe the line breaks, they are an illusion :D
11:46@9214 yup:
>> probe print 1
1
unset
>> unset unset
*** Script Error: unset is missing its word argument
*** Where: unset
*** Stack:
geekyi
11:47Actually was trying to reduce an error, maybe I reduced it too far..
maximvl
11:48do you even reduce? :D
geekyi
11:51@maximvl too much XD , actually same problem higher up..
s: reduce [:append 42]

print type? s/1  ; incomplete line
print [4]

11:52Maybe if I'd used probe, would catch sooner..
9214
11:53how can you append if 42 is not a series?
maximvl
11:54this code doesn't run append, it evaluates to the function itself
geekyi
11:54@9214 not trying to, just trying out *compile* vs *interpret*. Could have been any other func
maximvl
11:55
>> s: reduce [:append]
== [make action! [[
    {Inserts value(s) at series tail; returns series head} 
    series [ser...
>> print type? s/1
*** Script Error: s/1 is missing its series argument
*** Where: type?
*** Stack:
11:55to make sure you don't run it use the colon:
>> print type? :s/1
action
9214
11:56get-word! ;)
geekyi
12:15Got caught by nested blocks! of length 1. ? doesn't distinguish between.. no, you can't simply find the difference from console output. Found out there isn't a bug (probably)
12:16@geekyi was inspired by @9214 bug https://github.com/red/red/issues/2910 :evil:
9214
12:17@geekyi don't mention it, I won't sleep if I see number 2910 ever again :(
12:17@9214 still fights with compiler
geekyi
12:19Due to the way it works now, compiled vs interpreted code can give different length? for blocks, if you have nested functions
9214
12:19@9214 fun factoids: 2910 is almost like 9214 only messed up and without 4
geekyi
12:20@geekyi noticed it too
9214
12:21@geekyi have you tried to wrap script inside do block?
geekyi
12:21@9214 not a bug, just testing stuff. Using do and reduce
9214
16:09make error! 100 silently crashes REPL. Bug/feature?
rebolek
16:23Certainly a bug. I've reported similar one recently.
9214
20:27
text
view layout/flags [] 'some-valid-flag

*** Script Error: cannot set none in path none
*** Where: eval-set-path
*** Stack: view layout eval-set-path
meijeru
20:37crash of make error! 100 is also in comments to issue #2628
9214
20:38@meijeru :+1:
greggirwin
21:38@9214, confirmed that layout has the issue, but view itself is fine. Is that what you mean?
9214
21:44@greggirwin yup
greggirwin
21:44Seems worth a ticket, if one isn't there already.
21:44Nice find.
9214
21:46quickly skimmed through open issues with layout, couldn't find anything related, currently filling a ticket.
21:47https://github.com/red/red/issues/2936
greggirwin
21:47Thanks @9214.

geekyi
07:20> crash of make error! 100 is also in comments to issue #2628

red/red#2628

9214
12:30What is prefferable format for issues in red repo?
rebolek
12:31What do you mean by format?
9214
12:34I mean how to format your bug finding so it's easier to read/track/reproduce by Red team? Say, instead of foo chokes up on bar arg maybe I should write SOME-TAG-IN-CAPS: FOO chokes up on BAR arg or vise versa? Same for content of the issue, I know that it should contain at least minimum code example, but anyway.
rebolek
12:36I usually try to describe the problem in in title, add detailed description and example code to body. TAG-IN-CAPS is usually left for WISH:, or maybe [VID] and/or [View].
dockimbel
14:38@9214 You can put emphasis on some parts using typographic styles: italic, bold, underline, that's usually enough. Or do you mean specifically for the issue's title?

9214
13:00yes, issue's title
dockimbel
14:45An informal tag can help, but more for searching duplicates than for processing it. Actually, titles should be really be optimised for duplicates identification. Not sure what should be the best rules for that.

toomasv
13:32Bug?
>> bs: make bitset! 1
== make bitset! #{00}
>> repeat c length? bs [print bs/:c]
false
false
false
false
false
false
false
false
>> b: [true false true] 
== [true false true]
>> repeat x length? b [bs/:x: b/:x]
== true
>> repeat c length? bs [print bs/:c]
true
true
true
false
false
false
false
false

I expected second bit to be false.
13:48Sorry, got it. Right way would be:
>> repeat x length? b [bs/:x: reduce b/:x]
== true
>> repeat c length? bs [print bs/:c]
true
false
true
false
false
false
false
false

x8x
17:13I think it's a bug:
make date! [1 2 3 4 5 6 4]
;   1-Feb-0003/4:05:06+04:00
  make date! [1 2 3 4 5 6 5]
*** Script Error: cannot MAKE/TO date! from: [1 2 3 4 5 6 5]
*** Where: make
*** Stack:
greggirwin
17:51Looks like it. There has been some recent work on date, but I don't know if it's a regression.
17:52Zone is good down to -16 in that construct, then wraps back to -1.
17:53Please file a ticket.
x8x
17:53Will do thanks for checking :-)

dockimbel
09:25@greggirwin Are "file a ticket" and "fill a ticket" equivalent expressions, or is the latter incorrect?
09:25MAKE date! issue is fixed now.
x8x
09:26Thanks! Works fine now. 😃
greggirwin
15:43@dockimbel, "File a ticket" is like "Submit a ticket" or "File a report". If you want to use "fill", I would say "Fill *out* a ticket."
geekyi
17:00"Fill out a form, then file it for later" :)
dockimbel
17:27Thanks for the explanations. :+1:
raimundasa
19:34A button is not colored. win 8.1
'''
view [button red "Click Me"]
'''
greggirwin
19:59Not supported at this time. Native controls offer both benefits and limitations.
20:06You can work around it, by creating images to use on base faces (or drawing directly on them). Depends on how much work and what effects you need. e.g.
>> i: make image! 100x24
== make image! [100x24 #{
    FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
    FFFFFFFFFFFFFFFFFFFFFFFFF
>> draw i [pen black fill-pen red box 1x1 99x23]
== make image! [100x24 #{
    FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
    FFFFFFFFFFFFFFFFFFFFFFFFF
>> view [base i]
raimundasa
20:13Then clear

x8x
00:07There is probably a recent regression in compiled code, this used to return 123.0, it now returns 123:
Red []
object [
	to-float*: :system/words/to-float
	set 'to-float func [n][to-float* n]
]
print to-float 123

tried with -c and -r
dockimbel
03:43@x8x Will have a look at it.
xqlab
11:52Anyone else seeing strange behavior of the gui-console under Win7? Sometimes the active area is smaller than the window size.
dockimbel
12:29@xqlab Please share a screenshot for such kind of cases. Can you provide some ways to reproduce it?
rebolek
16:10@dockimbel Here's a question from IRC:

> I just downloaded latest red binary "red-63" and tried to run it, but all i get was:
Compiling compression library...
Compiling Red console...
*** Runtime Error 23: illegal operand
*** at: 0806202Dh
whats that about?
it's a bit old pentium 4 linux machine
dander
21:32@dockimbel I was just seeing a strange behavior that sounds like what @xqlab was describing when I pasted and slightly modified the code from @rebolek's post :point_up: [August 4, 2017 3:51 AM](https://gitter.im/red/red/gui-branch?at=598451b8210ac2692052ad4a)
It didn't seem to happen every time, so thought it was something I was doing, but I can get it to happen without making any changes to that line. Just open console, paste, enter. It seems like the text area of the window shrinks down when it shows the new view window. If I resize the console window by dragging the corner, it goes back to normal
21:33[![image.png](https://files.gitter.im/red/bugs/n5KT/thumb/image.png)](https://files.gitter.im/red/bugs/n5KT/image.png)
21:42looks to me like the text area takes the same size as the child window

dockimbel
04:55@rebolek We are missing [SSE3 detection](https://github.com/red/red/blob/master/red.r#L96) for non-Windows platforms, so that the compiler will emit unsupported instructions. If someone wants to add SSE3 detection for Linux and macOS platforms, a PR is welcome. (Should be trivial for Linux using /proc/cpuinfo).
04:56@qtxie Please have a look at the console issue above.
04:57@dander You can open a ticket for that.
dander
06:20@dockimbel @qtxie issue #2962 created
xqlab
07:03I am not on windows now. My observation is similar, but also a little bit different to what @dander sees. It looks same, but it happens immediately after opening the gui-console without any interaction. Resizing cures it.
ne1uno
07:15changing background color from the menu fixes it even for next start. but now it won't remember it's last position, so it must involve the config file somehow
07:16win7
rebolek
12:27@dockimbel Thanks for info, I've passed the message.
dockimbel
13:00The console resizing issue has been fixed.

PeterWAWood
01:12Error message for invalid escaped characters show #"^^..." instead of #"^...". Is this a consequence of the bootstrap toolchain using Rebol?
>> #"^"
*** Syntax Error: invalid char! at {#"^^"}
*** Where: do
*** Stack: load 
>> #"^8"
*** Syntax Error: invalid char! at {#"^^8"}
*** Where: do
*** Stack: load

01:15Invalid escaped characters "crash" the bootstrap compiler:
*** Syntax Error: Invalid issue! value
*** in file: /Users/peter/VMShare/Code/Red/test.red
*** line: 3
*** at: {"^^4"}
>>

Is this avoidable at all with the bootstrap compiler?
meijeru
08:52Curiously, ^4 within a *string* is accepted, i.e. in that case ^ quotes anything following it, which does not have a special meaning.
08:55This could easily be allowed within a character literal as well.

PeterWAWood
09:52When molding a date Red formats any timezone as ±hh:mm. Rebol suppresses leading zeros with hours. Personally, I prefer Red's formatting. Is the difference intentional?

Oldes
16:45@dockimbel I believe that [this line](https://github.com/red/red/blob/master/runtime/simple-io.reds#L692) should be:
res: either zero? res [-1][read-sz]

and not:
res: either zero? res [-1][1]

Currently on Windows it always return 1 as number of bytes read as it is in other oses.

maximvl
16:40is ; allowed as a word?
16:41
>> to-word ";"
*** Syntax Error: invalid character in: ";"
*** Where: to
*** Stack: to-word  

>> to-word first ";"
== ;
rebolek
16:42No, it shouldn't be imo
9214
16:43Alas
>> set to word! "a" 2
== 2
>> a
== 2
>> set to word! #";" 42
== 42
>> ;
>> ; ???
>> ; :^(
maximvl
16:47is there any way to specify exactly how to parse content of paren!?
16:47eg subshell: [ '( compound-list ') ]
16:48(this one doesn't work)
16:51hm, I guess into can do that
rebolek
16:56ahead paren! into ... to make sure you are not parsing content of a string, for example
maximvl
17:46thanks :)
9214
18:03looks like an issue with cd
>> to-red-file "C:\Program Files"
== %/C/Program%20Files
>> cd to-red-file "C:\Program Files"
*** Access Error: cannot open: <snip>
*** Where: do
*** Stack: cd change-dir cause-error  

>> change-dir to-red-file "C:\Program Files"
== %/C/Program%20Files/

toomasv
05:50
>> set to-word first ";" 42
== 42
>> get to-word first ";"
== 42
>> set to-word #";" 24
== 24
>> get to-word #";"
== 24
06:05Same with other special chars:
>> set to-word #"{" 'left-brace
== left-brace
>> get to-word #"{"
== left-brace
PeterWAWood
07:32@toomasv The issue appears to be with the to function:
>> to word! #";"
== ;
toomasv
07:35@PeterWAWood What issue? :) to word! works the same:
>> set to word! #";" 42
== 42
>> get to word! #";"
== 42
PeterWAWood
07:36; is not a valid character in a word
toomasv
07:39Is it an issue? These are very special cases and not too easily confused with usual word manipulation.
PeterWAWood
07:46From the Rebol 2:
"Words are composed of alphabetic characters, numbers, and any of the following characters ? ! . ' + - * & | = _ &~"

The lexer enforces this rule, the to function should also enforce it.
toomasv
07:48Also interesting:
>> set to-word first "1" 42
== 42
>> get to-word first "1"
== 42
>>

to seems to accept any char:
>> set to-word first "^/" 42
== 42
>> get to-word first "^/"
== 42
dockimbel
08:59@toomasv to-word should be checking for a valid character before allowing the conversion. You can open a ticket for that.
09:02@9214 cd is not a shortcut for change-dir, it is meant to work as its system shell counterpart, so only works with literal values, and not with function calls (change-dir is there for that).
9214
09:02@dockimbel :+1:
09:03@9214 can't wait to see @maximvl's shell dialect
dockimbel
09:05@9214 Yes, it will be interesting to see how we can best interface a shell-like environment with Red expressions.
9214
09:06yeah, then I can throw away Win7, forget about switching to emacs and just sit in Red's REPL for eternity :older_man:
dockimbel
09:08Making the Red environment good enough to avoid using the underlying OS at all, is one of my goals. ;-)
toomasv
10:55 @dockimbel https://github.com/red/red/issues/2988
Somewhat reluctantly though. It seems like an interesting feature:
>> set to-word #" " 'space
== space
>> get get to-word get get to-word #" "
== #" "
11:26
code: "v[t"
v: 'view
t: "text {One-letter-command mini-language!}"
set to-word #"[" 'to-block
reduce parse code [collect some [s: keep (get to-word first s) skip]]
maximvl
18:13@9214 here you go ;)
https://gitlab.com/maxvel/red-shell-dialect
9214
18:14@maximvl :clap:
maximvl
21:54
>> call/console {grep doesn\'t}
21:55not sure how the escaping is done, but this ^ hangs interpreter

geekyi
00:16@maximvl which shell/terminal emulator? I think it's possibly problem there
00:46@maximvl what about
>> call/console {grep blah}

I think anything should hang as grep waits for input in that case (when you don't pass in a file to process)
~$ grep foo
blah
foo
foo
01:00Not sure if this would help:
>> call/console form reduce [{grep foo} newline 'blah newline 'foo #"^D"]
maximvl
06:55@geekyi lol, you are right
06:56ill do more tests in the evening
06:56thanks

9214
07:51
text
probe collect [
    foreach [l d] "a1b2" [
        keep reduce [
            subtract to integer! to char! l 1
            to integer! form d
        ]
    ]
]

results in [96 1 97 2]. But logically identical
probe collect [
    foreach [l d] "a1b2" [
        keep reduce [
            -1 + to integer! to char! l
            to integer! form d
        ]
    ]
]

gives me
[
    96 1
    97 2
]

i.e. new-line markers inside block are setted for some reason
rebolek
07:53keep is probably adding them to make the block more readable. If you do not want them, you can remove them.
9214
07:56@rebolek okay, why then it formatted a block only in the second example with -1?
07:57I mean, -1 + x is the same as subtract x 1
07:58theoretically at least :smile:
rebolek
08:01This is indeed strange behaviour.

PeterWAWood
12:24@dockimbel If an error! is made in a function it only appears to be activated when the value is returned. Is this by design or a bug?
>> i: 11
== 11
>> if i > 10 [make error! "too big"]
*** User Error: "too big"
*** Where: ??? 

>> f: func [i][if i > 10 [make error! "too big"] print i]
== func [i][if i > 10 [make error! "too big"] print i]
>> f 11
11
>> f: func [i][if i > 10 [return make error! "too big"] print i]
== func [i][if i > 10 [return make error! "too big"] print i]
>> f 11
*** User Error: "too big"
*** Where: ???
greggirwin
15:05I think it's by design. You need to use cause-error to make them hot. The console forms error info, so you see it that way:
>> f: func [i][if i > 10 [e: make error! "too big"] print i]
== func [i][if i > 10 [e: make error! "too big"] print i]
>> f 11
11
>> e
*** User Error: "too big"
*** Where: ???

endo64
08:56@dockimbel foreach v [] [] returns unset! on Red but none! on R2. Is it a bug / known issue or intentional?
9214
12:09@endo64 yes, it's known behavior for some (or all?) iterators
endo64
17:07Is it decided or TBD?
9214
17:09I think @dockimbel mentioned that this behavior will be reconsidered

dockimbel
11:39@endo64 There's at least one ticket about that. We need to decide what to return for each iterator, and then implement it.
11:41@9214
> @rebolek okay, why then it formatted a block only in the second example with -1?

Most probably a side-effect of re-using the value slot internally and not resetting the slot's header bits. Could be considered a feature though. ;-)
11:42@PeterWAWood Errors are form-ed by default when returned in the console. As this can be confusing, I guess we should change that to the mold-ed version (make error! [...]) rather.
12:01@Oldes About your simple-IO question, we don't use the number of bytes read, we just need a success/failure value. If you need it, we can change it to return the number of bytes read (or you can do it directly and send a PR).
9214
13:44
text
>> [<]
*** Syntax Error: invalid tag! at "<]"
*** Where: do
*** Stack: load
>> ?? <
<: make op! [[
    {Returns TRUE if the first value is less than the second} 
    value1 [any-type!] 
    value2 [any-type!]
]]
>> [< ]
== [<]
13:47should I file it as a bug?
rebolek
13:57@9214 definitely
Oldes
14:10@dockimbel thanks.. I will.
9214
17:53am I right that extend doesn't support object!s yet?
rebolek
17:58@9214 you are right and the question is if it does not support it *yet* or at *all*.
9214
17:59I guess _yet_
>> ? extend
USAGE:
     EXTEND obj spec

DESCRIPTION: 
     Extend an object or map value with list of key and value pairs. 
     EXTEND is a native! value.

ARGUMENTS:
     obj          [object! map!] 
     spec         [block! hash! map!] 

REFINEMENTS:
     /case        => Use case-sensitive comparison.
rebolek
17:59We will see.

maximvl
08:24
>> switch type? :to-path [function! [probe "func"]]
== none
08:24is this a bug?
dockimbel
08:25@maximvl You are trying to match datatype! values with word! values. Use type?/word instead.
maximvl
08:26@dockimbel ok, I understood the reason, didn't know about /word!, thanks :)
dockimbel
08:27Alternatively, you can define inlined datatype!values using the construction syntax (#[...]), though, it's just partially implemented for now, and anyway looks uglier in code. ;-)
maximvl
08:40@dockimbel looks like refinement can have multiple arguments, is that by design?
>> f: func [/a b c] [probe reduce [a b c]]
== func [/a b c][probe reduce [a b c]]
>> f/a 1 2
[true 1 2]
== [true 1 2]
>> f
[false none none]
== [false none none]
08:40I don't think I ever saw this in the code
08:40but this means refinements are not equivalent of optional arguments, but something more powerful
meijeru
09:33That is indeed by design!
9214
09:37sure thing it is
dander
16:30@maximvl check out the /trace refinement on parse: https://github.com/red/red/blob/master/environment/natives.red#L348 :open_mouth:
Oldes
16:50@dander trace refinement in your code have only one argument - a function callback ;)
16:53@maximvl it is for sure by design.. even help can recognize it:
>> f: func [/a b "this" c "that" /d] [probe reduce [a b c]]
== func [/a b "this" c "that" /d][probe reduce [a b c]]
>> ? f
USAGE:
     F 

DESCRIPTION: 
     F is a function! value.

REFINEMENTS:
     /a           => 
        b             "this".
        c             "that".
     /d           =>
dander
17:01@Oldes not my code... but I was amazed at how much detail could be added to a refinement argument
17:02I was just used to seeing the type blocks and descriptions. I didn't know you could describe the whole callback signature, and I thought that was really cool!
18:26Would it be worth opening a wish ticket to request making unset! falsey? It's sort of related to #2645, but I think there might be a stronger case for unset!. My concern is that I might be conflating it with none, and I don't totally understand the implications it would have with functions that return unset!. However this kind of thing seems confusing/surprising to me (I know that's not an argument in itself for doing it):
>> unset 'w
>> if (get/any 'w) [print w]
*** Script Error: w has no value
greggirwin
18:49There's a bit of historical discussion about unset!, with no clear right/wrong answer. It's a design choice. I don't think it's worth a wish ticket, but I doubt Doc wants to take time right now to document his thoughts in more detail. http://www.rebol.net/r3blogs/0318.html has some good thoughts in it, WRT the truthiness of unset! from Carl's perspective. There is a note about why it exists at all, which is important, and simple: https://github.com/red/red/wiki/Guru-Meditations#why-does-unset-exist.

It does mean we will have some "Don't do that" cases. An alternative, timely with the current Haskell chat here, is what happens when everything has to be Maybe enabled.
9214
18:53I'd say that you should not rely on unset! as a true or false at all, it's kinda of a special value as @greggirwin pointed out
18:55I already stumbled on this once while creating a macro which relies on a returning value from a while - in Red it's always unset!, but not in Rebol; so, in interpreter everything worked, but broke after compilation (since macros currently rely on R2)
dander
19:15@greggirwin, @9214 Thanks, that rebol post kind of flipped the switch for me. I think my confusion was based on coming from languages which only have null, which needs to be differentiated between an invalid condition, and also a valid empty placeholder. I hadn't realized that redbol had a solution to that problem :smile:

maximvl
07:24is this a bug?
>> find reduce [function! op! action! native!] datatype!
== [function! op! action! native!]
07:25
>> function! = datatype!
== false
rebolek
maximvl
07:49what's going on then?
07:49I don't see any logic here
rebolek
07:50You can search by datatype:
>> find ["asdf" 123 456,789 bflm] float!
== [456.789 bflm]
07:50So if you search for datatype!, it returns first found datatype, in your case function!
maximvl
07:51how do I search for datatype! itself?
rebolek
maximvl
07:53ok, to-word seems to work:
>> find [function! op! action! native!] to-word datatype!
== none
>> find [function! op! action! native!] to-word function!
== [function! op! action! native!]
rebolek
07:54But then you are not searching for datytype! but for word!
maximvl
07:55btw I foresee a lot of problems with debugging having two things represented in the same way like function! as a word and function! as a datatype
rebolek
08:00Yes, it brings some problems. They are fortunately solvable.
maximvl
08:25@rebolek is there any way to make an object callable?
rebolek
08:26@maximvl You can call function in an object, if that's what you mean. I'm not sure how you want to call whole object.
maximvl
08:26a: object ... and then a x y
08:26eg if an object has a function, lets say call it's called
rebolek
08:27So object would have some function with predefined name that would be called automatically?
maximvl
rebolek
08:28No, that's not possible.
maximvl
08:28why? I believe this is a super important feature
08:29it allows you to switch between function and object worlds
rebolek
08:29But function has its own context, so why not just call function?
maximvl
08:29because then I can't make objects look like functions
08:30ok, let me give you an example
rebolek
08:31
>> o: object [a: 1 b: 2 set 'f func [][a + b]]
== make object! [
    a: 1
    b: 2
]
>> f
== 3
maximvl
08:31I'm working on curry function which should allow one to bind arbitrary parameters of a function
08:31it's super easy to implement with objects because I can store the state and everything
08:32but the result should be the same a a function, you should be able to call if afterwards
08:32otherwise you always have to check if you have a function - call function and if you have a carried object - call a function of this object
08:33which is just stupid
rebolek
08:33Hm... any code?
maximvl
08:33I can create and return a new function, but then if you want to curry it again you have to go through all parsing process
08:34while if I would have an object I could just reuse it's state
08:35this is essential feature - to have a state which is useful for internal stuff and be able to behave as a function for users without breaking abstraction details
rebolek
08:36I think you want closures.
maximvl
08:36the code is in progress, but thinking about how and what should I do I found this issue
08:36how would a closure help?
rebolek
08:37For storing state? Certainly.
maximvl
08:37but the closure stores state inside the function, isn't it?
rebolek
08:37Right.
maximvl
08:38so how do I access it from outside?
rebolek
08:40Hm, you can't.
08:40But see my above example where I define function in an object.
08:41You have access to both function and to the object that holds its internal state.
maximvl
08:41but I need only one thing
08:42I can return only function and then look for object using context? or something, but this is too hacky
08:43and there will be too many things which can go bad
08:43every dynamic language out there can do it
08:44https://docs.python.org/3.4/reference/datamodel.html#object.__call__
rebolek
08:44The problem with automatic call of a function in an object is that if you define that function, then you can't get whole object: reduce [my-object 1 2] <- is this a call to my-object/call with args 1 and 2 or do I want to reduce object and two integers?
maximvl
08:48depends on if my-object has a call method
08:48and it accepts 0, 1 or 2 arguments
rebolek
08:49So if it has a call method, how do I override it and get whole object?
maximvl
08:49idk with :my-object ?
rebolek
08:50Hm, that could be possible.
maximvl
08:51btw in common lisp functions belong to the object system
08:51so it's super natural that you can extend function class and do wherether you want
08:52same in js
08:54smalltalk, IO and some others
rebolek
08:55I see. I think this more a question for @dockimbel
dockimbel
16:39@maximvl It's a natural feature in OO languages where functions derive from objects, so that's a no-go for languages which are not sharing those characteristics (like Redbol). JS [doesn't seem](https://stackoverflow.com/questions/19335983/can-you-make-an-object-callable) to support such feature. What you really want is closure!.
rebolek
22:45I'm encountering some strange bug in console on Linux in gtk branch (cannot confirm it yet on main branch), where after some time float math stops working. It returns zero. It's hard to reproduce, console must be running for some time.
greggirwin
23:06> I foresee a lot of problems with debugging having two things represented in the same way

> because then I can't make objects look like functions

Life is confusing. :^) @maximvl, you've seen Doc's specialize func, right?
specialize: function [fun [function!] defs [block!]][
    spec: copy/deep spec-of :fun
    body: copy/deep body-of :fun

    foreach [arg value] defs [
        arg: to word! form arg
        pos: find spec arg
        remove/part pos pick [2 1] block? pos/2
        parse body rule: [some [change only arg value | into rule | skip]]
    ]
    func spec body
]
23:07
>> foo: func [x y][x + y]
== func [x y][x + y]
>> bar: specialize :foo [x: 5]
== func [y][5 + y]
>> bar 10
== 15
>> baz: specialize :bar [y: 5]
== func [][5 + 5]
>> baz
== 10

maximvl
11:51@greggirwin haha, good catch :D
11:51I'll think about Dock's approach, thanks
9214
12:21@maximvl so, you want to implement curry function that gets another function with inner state, changes its state, and returns a new function, right?
12:22and state is represented as some anonymous object which can be refferenced only with that function?
12:27
text
context [foo: on bar: off set 'f func [/state] compose [if state [return (self)]]]
12:28if called with /state refinement it spits out its internal state, otherwise performs some function
12:28though I haven't checked if you can modify this state directly
12:29yay!
>> f/state
== make object! [
    foo: true
    bar: false
]
>> set in f/state 'foo 'poop
== poop
>> f/state
== make object! [
    foo: 'poop
    bar: false
]
luce80
16:00I thing while shouldn't return unset

n: 1 probe while [n < 3] [n: n + 1]
9214
16:00@luce80 that's a known behavior for most iterators
luce80
16:02loop, repeat, and until return last evalued value. forever returns unset if ends with break. Those are all correct.
9214
16:03@luce80 https://github.com/red/red/issues/2873
greggirwin
18:24@9214, @chrisrg often uses use in his R2 work to create an anonymous context that returns a function. No way to get at the internal state, unless you add it as a refinement, like you do. That's clever.
18:25I've used a similar /state type trick for aggregator funcs.
9214
18:26I think it could be nicer to create a custom constructor which will generate boilerplate of refinements depending on the spec
18:27so instead of doing set in blah blah you can just call foo/set-blah
greggirwin
18:27One of the interesting things here is that, with Red, we can not only curry things, but we can potentially uncurry them as well.
9214
18:27and that way we can simulate objects just like in mainstream languages I suppose?
greggirwin
18:28Ultimately, it's about finding what various approaches let us express clearly.
9214
18:28i.e. you have well-defined interface and no way to probe something, because it's anonymous
18:28though you still can probe self in function's body :confused:
greggirwin
18:29Yes, we can absolutely do things like that.

maximvl
12:07
>> read https://raw.githubusercontent.com/minimaxir/big-list-of-naughty-strings/master/blns.txt
*** Access Error: invalid UTF-8 encoding: #{EFBFBE0A}
*** Where: read
*** Stack:
12:08https://github.com/minimaxir/big-list-of-naughty-strings
12:08list of weird strings for testing unicode support

geekyi
01:05http://www.fileformat.info/info/unicode/char/fffe/index.htm
01:05[![image.png](https://files.gitter.im/red/bugs/uiUK/thumb/image.png)](https://files.gitter.im/red/bugs/uiUK/image.png)
01:10> Unicode Data
Name Noncharacter
Block Specials
Index entries Noncharacters
Comments may be used to detect byte order by contrast with U+FEFF
See Also zero width no-break space U+FEFF
01:12https://www.wikiwand.com/en/Byte_order_mark#UTF-16:
> If an attempt is made to read this stream with the wrong endianess, the bytes will be swapped, thus delivering the character U+FFFE, *which is defined by Unicode as a "non character" that should never appear in the text*
01:17**tl;dr** it is a swapped UTF-16 byte-order mark (indicating the endian-ness has been reversed)
02:08Side note:
https://github.com/minimaxir/big-list-of-naughty-strings/blob/master/blns.txt#L136
Red accepts other EFBF characters, including the UTF-8 [Byte order mark](https://www.wikiwand.com/en/Byte_order_mark#/Byte_order_marks_by_encoding) EFBBBF
a: read/binary https://raw.githubusercontent.com/minimaxir/big-list-of-naughty-strings/master/blns.txt
b: find a #{EFBFBE}
a1: take/part a2: copy a index? b

Also, it looks like it's the only character that gives an error in Red:
>> back back back back b         ; UTF-8 Byte order mark
== #{
EFBBBF0A...
>> to-string a1           ; before 
== {#^-Reserved Strings...
>> to-string at a2 3      ; after
== {^/^/#^-Unicode Symbols

xqlab
08:39Today I could not start red (gui-console), as my console-config.red file was corrupted. The content consisted of many NULLs.

xqlab
08:21console-config.red = console-cfg.red
PeterWAWood
10:42Setting the width of a text field stops the height of the field being calculated. Is this a bug?

Script and Screenshots:
view [
	size 232x300
	across
        text "Font-Size 24"  font-size 24
	return
	text "Font-Size 24" 230 font-size 24
]
10:43[![Windows.png](https://files.gitter.im/red/bugs/81ei/thumb/Windows.png)](https://files.gitter.im/red/bugs/81ei/Windows.png)
10:43[![macOS.png](https://files.gitter.im/red/bugs/yXTM/thumb/macOS.png)](https://files.gitter.im/red/bugs/yXTM/macOS.png)
10:48This is different from Rebol/View.
dockimbel
10:56@PeterWAWood Worth a ticket to improve such cases.
PeterWAWood
12:10#3020

luce80
18:22this quits Red 0.6.3 on Win7:
view [base on-create [show face]]

dockimbel
04:09@luce80 Please open a ticket for it.
maximvl
17:33interesting ask behaviour:
>> ask "test> "
test> 
== "q"
17:33what I did - pressed C-d
17:33return value for some reason is "q"
17:34which seems to be indistinguishable from typing "q"
9214
18:35Ctrl-d is a shortcut for typing q word, which halts the REPL
maximvl
18:36maybe it's fine for repl, but how do I know if user wanted to enter just "q"
9214
18:37yeah, ask should check for such key shortcuts before processing them
18:41same for Ctrl-c (returns "q"), Ctrl-[ returns "^[" and Ctrl-m returns ""
18:45Ctrl-3 is treated as "^[" (escape?), Ctrl-8 acts like backspace (dunno why I'm investigating this :D)
18:49and only Ctrl-<1 9 0> puts actual digits, though it works for all of them with numpad
maximvl
19:58is there any way to call a saved op!?
>> a: #()
== #()
>> a/+: :+
== make op! [[
    "Returns the sum of the two values" 
    value1 [number! char! pair! tuple! vector! time!] 
    value2 [number! char! pair! tuple! vector! time!] 
    return: [...
>> 1 a/+ 2
== 2
20:50to-block somehow evaluates it's argument:
>> to-block "abc"
== [abc]
>> to-block "1"
== [1]
>> to-block "1/0"
*** Syntax Error: invalid integer! at "1/0"
*** Where: do
*** Stack: to-block
20:59shouldn't this collect [a b c]?
>> parse [a b c z] [ collect [ [keep skip] thru 'z ]]
== [a]
rebolek
21:00No, keep skip will keep a and thru 'z will go to end.
9214
21:01
text
>> parse [a b c z][collect keep to 'z]
== [[a b c]]
rebolek
21:02
>> parse [a b c z] [ collect [ some [keep [not 'z skip]] thru 'z ]]
== [a b c]
21:02@9214 yes, that's shorter :)
9214
21:02though I don't get why collect returns nested blocks
rebolek
21:03@9214 because keep in parse works as keep/only, see https://github.com/red/red/issues/2899
9214
21:04@maximvl regarding op! - I bashed my head over this and IMO it's easier just to store their function counterparts
21:05
text
>> a: #()
== #()
>> a/+: :add
== make action! [[
    "Returns the sum of the two values" 
    value...
>> a/+ 1 2
== 3
maximvl
21:06@9214 hm, somehow I hoped to cares about left arg as well
21:07didn't know about add thanks :D
9214
21:08and I hoped that this one would work
>> a/+: :+
== make op! [[
    "Returns the sum of the two values" 
    value1 [n...
>> do reduce [1 a/+ 2]
*** Internal Error: reserved for future use (or not yet implemented)
*** Where: do
*** Stack:
maximvl
21:09why doesn't this work?
>> parse "[1]" ["[" any skip "]"]
== false
rebolek
21:10Because any matches also nothing
9214
21:10I think because any is greedy, it matches 1]
21:10@maximvl why you're not in help room btw? :D
maximvl
21:11because I suspect those are bugs :D
9214
21:11:shipit:
21:12
text
>> parse [what ever really][any skip]
== true
21:12iterators (i.e. any some and while) repeat rule maximum possible times
21:13this means that in your example any skip skipped to the end of the series and "]" failed the match

dockimbel
02:45@maximvl
> to-block somehow evaluates it's argument:

No, it just applies a load on a string value, before wrapping it in a block. In your case above, you specified a non-loadable string.
02:49@9214 @maximvl
>> ++: :a/+
>> ++ 1 2
== 3
02:50(typically a case that the compiler will not process correctly for now, so will require a do [...] wrapper for ensuring ++ is processed as a function call).
9214
14:53congrats with 2k closed issues :bug: :sparkles:
dockimbel
15:57@9214 Thanks :+1: :fire: :smile:
dander
19:20looks like tab-completion on an unset word is causing a crash (or at least quits) in both consoles (I pressed tab after the /)
>> foo/*** Script Error: w1 needs a value
*** Where: set
*** Stack: ask red-complete-input red-complete-path
greggirwin
19:53Confirmed. Please file a ticket.
dander
20:06opened red/red#3033
greggirwin
20:11Thanks @dander.
dander
20:11thanks for repro :thumbsup:

luce80
08:49Unimplemented feature:
>> first now/date
*** Script Error: first does not allow date! for its s argument
*** Where: first
*** Stack: first  

>> second now/date
*** Script Error: second does not allow date! for its s argument
*** Where: second
*** Stack: second

9214
08:50@luce80
>> series? now/date
== false
luce80
08:52@9214
>> first now/time
== 10

9214
08:53hm, now this makes sense
maximvl
08:53
>> help first
USAGE:
     FIRST s

DESCRIPTION: 
     Returns the first value in a series. 
     FIRST is a function! value.

ARGUMENTS:
     s            [series! tuple! pair! time!]
08:53time! is there, but not date!
9214
08:54but since ordinal path notation is allowed, i guess first, second and etc should accept date! too
luce80
08:55I wrote "unimplemented" ;) not "bug".
9214
08:55but you wrote this in red/bug room :D
maximvl
13:28is this a proper behaviour?
>> parse [1 2 3] [collect [keep collect any [keep number!]]]
== [[1 2 3] [1 2 3]]
9214
13:28@maximvl why do you think it's not?
maximvl
13:29I would say the second collect/keep should collect all three numbers
13:29and then the first collect/keep's argument should be a block
13:29and result should be [[1 2 3]]
13:31and I don't see how it would produce double block anyways
9214
13:32
text
>> parse [1 2 3] [collect keep any number!]
== [[1 2 3]]
maximvl
13:34I wonder if I can keep result of a collect in the same way
9214
13:37perhaps topmost collect collects both keep collect ... and keep any number! ?
maximvl
13:37looks like it
9214
13:37it's the same [1 2 3] in both cases
maximvl
13:37
>> parse [1 2 3] [collect [keep collect [keep number!]]]
== [[1] 1]
13:38well, first question - is that a bug? I'd like keep to affect the closest collect only, if possible
9214
13:38could be considered as a feature though :)
maximvl
13:38because then one can nest them in any way
13:40and the second question - if that's not possible, how do I go about parsing recursive structures?
13:41once a rule uses collect/keep - it can't be used recursively because of this behaviour
9214
13:47@maximvl recursive - ahead / into combo?
maximvl
13:49yes, but how do I collect the data? :)
9214
13:50idk, set, copy, collect set, collect into
maximvl
13:50I don't see a way to keep structure using these
13:56hm, I guess I need to make a stack of structures
rebolek
13:58@maximvl keep/collect preserves structure
maximvl
13:59@rebolek could you show me an example?
14:00looks like I'm missing something
14:01it actually feels like I asked this question before
rebolek
14:02@maximvl I will try, wait a minute...
9214
14:07@maximvl bingo! :tada:
>> parse [1 2 3][collect [keep ahead collect any [keep number!]]]
== [[1 2 3]]
rebolek
14:07@maximvl copy/deep the parse way :godmode:
>> rule: [collect some [into rule | keep skip]]
== [collect some [into rule | keep skip]]
>> parse [a b [c d]] rule
== [a b [c d]]
9214
14:07so I'd say it's a rather nice feature
maximvl
14:09@9214 @rebolek now I don't get why it works in your examples and doesn't work in mine
9214
14:09ahead basically says "first match this rule before doing anything else"
14:10after that [1 2 3] is collected
maximvl
14:11ahead shouldn't adjust the input
rebolek
14:12It does not, it is basically if
9214
14:12first collect any numbers into block, then collect this block
14:12makes perfect sense to me
rebolek
14:13
>> parse [a "b" #c 'd][collect some [ahead issue! keep skip | skip]]
== [#c]
maximvl
14:13but why ahead is needed there at all
14:13I don't get it
14:14how is it different from parse [1 2 3] [collect [keep collect any [keep number!]]]
rebolek
14:14@maximvl because into parse series! and string! is series! too.
maximvl
14:15wait, wait my input is a string, I can't use into
rebolek
14:16Ah :)
maximvl
14:16I'm trying to understand this ahead approach
rebolek
14:17ahead is like if, it matches some rule, but does not advance. If it matches, next rule is matched. If it does not, it backtracks.
maximvl
14:18ok, let's start from the beginnig
14:18
>> parse [1 2 3] [collect [keep collect any [keep number!]]]
== [[1 2 3] [1 2 3]]
14:18why do I get two blocks here?
rebolek
14:19because you do collect/keep twice
maximvl
14:19but I collect numbers only once
9214
14:19keep any numbers (innermost), then keep numbers again (topmost), then collect everything together
14:23and with parse [1 2 3] [collect [keep ahead collect any [keep number!]]] it's: keep any numbers (innermost), collect them, then keep collected numbers (topmost), then collect them
maximvl
14:23does it mean that collect appends to the result automatically and I don't need to do it second time?
9214
14:27not sure what you mean
maximvl
14:27@rebolek is there any way to make this structure without into?
rebolek
14:29@maximvl keeping your own stack
dockimbel
16:17@maximvl
> does it mean that collect appends to the result automatically and I don't need to do it second time?

Precisely, so the first keep is the cause of your troubles:
>> parse [1 2 3] [collect [collect any [keep number!]]]
== [[1 2 3]]

Actually, a single collect is enough there, unless you really want a nested block.
16:21collect automatically appends to its parent collect and the root one returns the block as result. This auto-appending feature works only on "naked" collect (not followed by any optional keyword, like set, into, after). So, you can control for every collect where the resulting block will go, either let it flow to his parent, or redirect it somewhere else.
maximvl
16:40@dockimbel that's a good explanation, thanks!
16:43now this one works even with nested structures :D
mal-map: [
         collect set tmp-series [ "{" any [not "}" mal-expression] "}" ]
         keep (to-map tmp-series)
      ]
16:44and one word is enough because it's being set only after sub-rule is done
20:04here's the code I have:
Red []

do %/home/max/projects/mal/red/mal-utils.red
probe "worked"
do probe to-file append system/options/path "mal-utils.red"
probe "worked 2"
20:05this is how I run it:
~/projects/mal/tests $ red ../red/step0_repl.red
"worked"
%/home/max/projects/mal/red/mal-utils.red
*** Access Error: cannot open: %/home/max/projects/mal/red/mal-utils.red/
*** Where: do
*** Stack: do-file change-dir cause-error
20:06looks super strange that do works with the constant but fails with constructed one though it's exactly the same
greggirwin
21:14I see a trailing slash in the constructed %/home/max/projects/mal/red/mal-utils.red/.
21:16Is system/options/path being modified by append the issue? i.e. copy it before the append.
maximvl
21:54@greggirwin it worked, that's something new to keep in mind, thanks :)

maximvl
08:32there is something wrong in specs return values:
>> spec-of :odd?
== [
    {Returns true if the number has a remainder of 1 when divided by 2} 
    number [number! char! time!] 
    return: [number! char! time!]
]
08:32return should be logic!
dockimbel
12:20@maximvl Indeed, same for even?. You can post a PR to fix it.
maximvl
12:21@dockimbel will do, I did a search for all things which have "returns false/true" in their doc string
12:21will check how many of them actually have logic type in return spec
12:22but first tests for hash! :)
12:56things are quite bad with it:
>> h
== make hash! []
>> put h 1 2
== 2
>> h/1
== 1
>> h
== make hash! [1 2]
dockimbel
12:58@maximvl That looks fine, you are doing an indexed access there, not a key lookup. Hashs are just blocks with fast lookups.
maximvl
12:59okey %)
9214
13:00@dockimbel bug/feature? (see discussion) :point_right: https://gitter.im/red/help?at=59be3d9ebc4647297443e15a
maximvl
13:01@dockimbel should make hash! [1 2 3 4] and make hash! [3 4 1 2] be equal?
13:08my test constructs make hash! [b 2 a 1 a 4] using put only
13:08I can't even reproduce it in the repl :D
13:16@dockimbel not sure what's going on, but github puts my new changes into the old PR
9214
14:17@maximvl same for me (tried to do 2 PRs yesterday)
dockimbel
15:54@9214 Looks like a serious regression...we really need more unit tests for hash!.
15:54@maximvl No they should not, no more equal than [1 2 3 4] and [3 4 1 2].
15:55@maximvl I'm not a PR expert, I only did a few ones, but I think you need to make a new branch for a PR, to avoid new and unrelated commits to pile up in the PR. @qtxie might know better.
maximvl
17:36done
17:38@dockimbel could you tell me anything about https://gitter.im/red/help?at=59bd9e90b59d55b82305527f ?

dockimbel
03:08@maximvl It's the usual issue of trying to run an encapped Rebol binary from another app, just use a wrapper script: https://github.com/red/red/issues/543. Why do you need to run the Red toolchain from Python? If you need to run your Red script interpreted, just use the console binary which does not suffer from the limitation of the encapped Red toolchain binary.
9214
10:52@maximvl ?
>> h: make hash! [1 a 2 b]
== make hash! [1 a 2 b]
>> find h 1
== make hash! [1 a 2 b]
>> find h 'a
== make hash! [a 2 b]
>> select h 1
== a
>> about
Red for Windows version 0.6.3 built 18-Sep-2017/15:48:26+05:00
maximvl
11:24@dockimbel this is the way they run tests in MAL, python script sends input and verifies output
11:25will try with a helper script later
dockimbel
11:25@maximvl So you don't need to use the Red toolchain, the console binary is enough to run your script, right?
maximvl
11:25what is console binary and what is toolchain ? :)
dockimbel
11:27@maximvl The red.exe you download from Red's web site is the toolchain, the console is precompiled on first run and put in a cache folder. To find the console binary: list-dir system/options/cache, then you can just make a copy of the latest console binary to your working folder, and use it to run your Red scripts interpreted.
endo64
11:28console binary is the compiled binary usually under %ProgramData%: C:\ProgramData\Red\console-2017-9-17-80805.exe
11:28Sorry, I interfere.
dockimbel
11:29@endo64 Not at all.
maximvl
11:30on linux I believe it's somewhere in ~/.red
11:30@dockimbel isn't this something we can fix?
dockimbel
11:31@maximvl What exactly do you mean by "something"?
maximvl
11:31the issue in #543
11:31the fact that red binary fails to run under certain conditions
dockimbel
11:32@maximvl No, it's a limitation of the Rebol Encapper (Rebol/SDK), which is closed source. Once we ditch Rebol and run the toolchain on Red, that issue will disappear.
maximvl
11:33ok, looking forward to self-hosting then :)
dockimbel
11:35@maximvl There is still a mitigating measure we plan for that in 0.6.4, which is swapping the current roles of the toolchain and console. Currently the toolchain is red.exe and acts as the master, while the console is the slave. We should be able to reverse this relationship, and that will fix most of those cases, where the red binary is run by another app with redirected I/O.
maximvl
11:39nice
9214
23:03looks like the following attempt to make a new reactive source from reactor! prototype with is "linkage" breaks entire reactive framework
>> r1: make reactor! [x: 1]
== make object! [
    x: 1
]
>> r2: make r1 [x: is [r1/x]]
*** Script Error: set-quiet does not allow set-word! for its word argument
*** Where: set-quiet
*** Stack:  

>> ;-- boom
>> what: make reactor! [ever: 'really]
== make object! [
    ever: 'really
]
>> nope: is [what/ever]
== really
>> what/ever: 'yeah
== yeah
>> nope
== really
23:07checked with every example from docs btw
23:10and what I've tried to simulate is [this](https://gitter.im/red/red?at=59c046ac7b7d98d30d0ff158) (seems like a worthy wish, no?)

dockimbel
03:20@9214 You can open a ticket for the first one. is is meant to work from inside a reactive object. The global context is not reactive. Use react for general reactions definition.
9214
08:16@dockimbel it's the combination of make and : is [proto/] that wreaks hawoc I believe. Not sure what you meant about global context and react though: second example works perfectly fine if I'd skip the first part.
08:20
text
>> what: make reactor! [ever: 'really]
== make object! [
    ever: 'really
]
>> nope: is [what/ever]
== really
>> what/ever: 'yeah
== yeah
>> nope
== yeah
08:56@dockimbel ah, you meant that I can do this instead?
>> r1: make reactor! [x: 1]
== make object! [
    x: 1
]
>> r2: make r1 []
== make object! [
    x: 1
]
>> react [r2/x: r1/x]
== [r2/x: r1/x]
>> r1/x: 100
== 100
>> r2/x
== 100

dockimbel
09:06@9214 Right, yes.

Oldes
08:10Is this by design? In Rebol:
>> parse/all "abc" [#"a" copy x any #"x" to end] x
== none

In Red:
>> parse "abc" [#"a" copy x any #"x" to end] x
== ""
9214
10:23ok
view [
    base transparent 500x500 draw [
        pen red
        circle 250x250 100
    ]
]
10:23[![изображение.png](https://files.gitter.im/red/bugs/f9oh/thumb/___________.png)](https://files.gitter.im/red/bugs/f9oh/___________.png)
10:24not ok?
view [
    base transparent 500x500 draw [
        [pen red]
        circle 250x250 100
    ]
]
10:24[![изображение.png](https://files.gitter.im/red/bugs/HWIA/thumb/___________.png)](https://files.gitter.im/red/bugs/HWIA/___________.png)
10:25per spec
> Inside Draw code, commands can be arbitrarily grouped using blocks. Semantics remain unchanged, this is currently just a syntactic sugar allowing easier group manipulations of commands.
dockimbel
12:02@Oldes Yes, copy in Parse will copy the input if the sub-rule succeeds (any always succeeds) and even if the input does not advance (you get "" then). Same as in Rebol3. This makes copy more predictable.
Oldes
12:03Ok.. thanks... already modified my old R2 code.
dockimbel
12:05@9214 That's a bug, yes. The result should be the same. ^--- @qtxie It seems the matrix is pushed when it shoudn't?
qtxie
13:52Yes. It's a bug. Should be fixed now.

9214
05:16have some algorithmic class today and found this (fib sequence with memoization, yay):
fib: function [n [float!]][
    table: #(0.0 0.0 1.0 1.0)
    either table/:n [
        table/:n
    ][
        extend table reduce [
            n
            add fib n - 1 fib n - 2
        ]
    ]
]

repeat i 100 [fib to float! i]
t: select body-of :fib 'table

probe select t 78.0
probe select t 79.0

results in
8944394323791464.0
1.447233402467622e16

is that expected?
05:19moreover in table/:n n is actually a float! value
PeterWAWood
05:41@9214 Your results look correct. Why did you use a map and not a block?
05:43Here's a version using a block. I've had to adjust for F78 actually being the 79th number in the series as Fibonacci series start at 0. (Clearly Fibonacci would have been a C programmer :-))
fib: function [i [integer!]][
    table: [0.0 1.0]
    either table/:i [
        table/:i
    ][
        append table reduce [add to float! fib i - 1 to float! fib i - 2]
    ]
]

repeat i 100 [fib i]
t: select body-of :fib 'table
probe pick t 78 + 1     ;; adjust for 0 being considered F0
probe pick t 79 + 1
9214
05:44@PeterWAWood I just confused that it suddenly dropped down from very large number to 1.44, floats are tricky :D
PeterWAWood
05:46@9214 The second number is in scientific notation. Did you miss the e16 at the end?
05:46Though I agree binary floats are tricky.
9214
05:47right, thanks!
05:49@PeterWAWood regarding map! vs. block! - I think I want to check if it could be modified inside a function's body (as with block!s without copy)
PeterWAWood
06:05@9214 The one that's gone was wrong. Let me try again:
put table n add fib n - 1 fib n - 2
dockimbel
06:14@9214 I sometimes use that memoization technic (usually with blocks) as local caches in functions. Very useful.
9214
06:30@dockimbel I've wrote down some notes from my Cy D. Fect colleague about Red ;)
dockimbel
06:33@9214 Sounds interesting. ;-)
9214
07:22@dockimbel
* There's no way you're ready to write code, we're still downloading VStudio.
* Is that some new Lisp or what?
* What do you mean by "memoization for free"? What do you mean by "because function can modify itself"... wait, self-modifying code?! You didn't tell me you're *that* experienced.
* I hate this function pointers juggling then it comes to implementing HOFs (he didn't actually know that it's called HOF)... why you're chuckling?
* I think you're cheating - we still can't debug our factorial example.
* Now, implement fib sequence for negative numbers... no mister, you can't just pick [- +] negative? n like that, you should rewrite everything using if/else and... stop chuckling!

07:41perhaps I should've used R/S to be on equal footing
dockimbel
09:02@9214 Hahaha, thanks for sharing. ;-) :+1:
greggirwin
18:29@9214, you are a true Reducer. :^)
9214
18:33:guardsman: yissir

9214
17:32@dockimbel in Draw dialect, [scale](https://doc.red-lang.org/en/draw.html#_scale) accepts two number! arguments, but chokes up on percent!, though
>> number!
== make typeset! [integer! float! percent!]

I bet it's a bug

dockimbel
03:29@9214 Feature not implemented, though I guess that would be nice to support too.
9214
07:50@dockimbel should I make a wish or is it already on your list somewhere?
dockimbel
07:50You can open a ticket for it, though, I'm not sure when it will be implemented.
9214
07:51it's just that documentation is a little bit misleading
07:52should be integer! float! instead
dockimbel
07:52I think the issue arised when we moved percent! into the number! typeset. Though in this case, having support for percents would be nice to have anyway.
9214
07:58number! is used only for scale and matrix, I quickly checked matrix and it seems to support percent!

PeterWAWood
01:52I am getting instances of the Red console "freezing" on macOS when it is built with Needs: View.

Starting the console in the Terminal results in a window-less "View" app appearing in the dock (in addition to the terminal).

If you then hide the Terminal app (CMD+h), the "View" app freezes.

When you force-quit the "View" app, the Red console in the Terminal is terminated:
mbp:red peter$ ./macView
--== Red 0.6.3 ==-- 
Type HELP for starting information. 

>> Terminated: 15

01:54Should a "View" app be launched before View is called or is that a bug?
02:12A window produced with view/no-wait [panel 300x300] responds differently to mouse actions between Windows and macOS. On both systems, it can be dragged around the screen. On Windows, it can be minimised and closed using the window buttons. On macOS, clicking on the minimise and close window buttons resulting in a spinning beach ball.
dockimbel
02:46@PeterWAWood Is that a recent regression (like since a few days), or older behavior?
02:46@qtxie ^---
PeterWAWood
02:53@dockimbel I think the freezing is more than a few days, Bolek mentioned it a while ago. I don't know about the /no-wait difference as I only tried that today.
02:59Also on macOS, a window created with view/no-wait does not respond to unview.
02:59[![Unview Issue.png](https://files.gitter.im/red/bugs/YNdL/thumb/Unview-Issue.png)](https://files.gitter.im/red/bugs/YNdL/Unview-Issue.png)
dockimbel
03:41Worth a ticket.
PeterWAWood
04:20#3057
qtxie
06:26You mean the red console freezing or a red program built with Needs: View freezing ?
rebolek
06:41Red console.
9214
23:14looks like an interesting feature, but my spider sense is tingling
>> [<tag>]
== [<tag>]
>> [< not tag >]
== [< not tag >]
>> type? first [<. not tag? >]
== tag!
>> <. not tag? >
== <. not tag? >
>> < what >
*** Script Error: < operator is missing an argument
*** Where: catch
*** Stack:  

>> <| okay that's interesting |>
== <| okay that's interesting |>

dockimbel
03:11@9214 < followed by a whitespace will parse as a word. If you put anything else, it should parse as a tag (if you provide a closing >).
03:12
lisp
>> < what >
*** Script Error: < operator is missing an argument
*** Where: catch
*** Stack: 
>> [< what >]
== [< what >]
>> length? [< what >]
== 3
>> length? [<this is a tag >]
== 1
9214
08:31@dockimbel thanks, I thought that spaces are not allowed in tags
dockimbel
08:55@9214 They are allowed, just not right after the opening < character.
rebolek
08:58@9214 If spaces were not allowed, this would be impossible:
greggirwin
17:53I just think of tags as a string with different brackets. The leading space being the special condition that applies to them.

9214
04:36
text
also violate! violate!: does [violate!]

*** Runtime Error 1: access violation
*** at: 00460102h
dockimbel
04:58@9214 Crash -> ticket. ;-)
9214
11:27snippet is misleading though, violate! was already defined before also is used (idk why I used it)
12:30?
do also 'violate! violate: does [violate!]
toomasv
13:11Is this a bug? wheel-event and down-event occur in same spot but values are different (Win10):
>> view [base 100x100 on-wheel [probe compose [wheel: (event/offset)]] on-down [probe compose [down: (event/offset)]]]
[wheel: 960x559]
[down: 47x43]
meijeru
15:39Looks like on-wheel gives the offset w.r.t. upper left corner of entire screen (absolute coordinates) while on-down gives the offset w.r.t the window, as it should.
toomasv
15:44@meijeru Looks so indeed! Thanks for explanation!
meijeru
17:28It is still the question, if this is a bug or a feature :worried:
toomasv
19:12@meijeru At least I can proceed now. Actually I am extreemly proud [having solved scaling by wheel problem](https://github.com/toomasv/l-system). :angel:
dander
19:25@toomasv that's really nice! I imagine the same algorithm will be useful in many places :thumbsup:
I did notice that I can drag the image at the start, but after scrolling, the image doesn't refresh after dragging
toomasv
19:26@dander Yes, dealing with that.
9214
19:41@dockimbel
>> make reactor! [probe words-of self]
[on-change*]
== make object! [
]
>> make object! [probe words-of self]
[]
== make object! []

Is that intended?

Also, do I understand correctly that reactor! isn't a separate datatype but a shortcut of some sort?
>> foo: func [x [reactor!]][]
*** Script Error: invalid type specifier: reactor!
*** Where: func
*** Stack:

greggirwin
19:45> Also, do I understand correctly that reactor! isn't a separate datatype but a shortcut of some sort?

Correct. They're just objects with on-change/on-deep-change callback funcs.
19:50The object datatype has special handling for those funcs, when molding an object. Use mold/all to see them.
9214
19:50@greggirwin it's just that I didn't expected to see some hidden stuff in words-of block, because it's, ehm, hidden
greggirwin
19:53That is a good question. We don't have a way to get them, as with mold, because reflector funcs don't (currently) have refinements. If they're hidden via reflection, then there's no way to find them.
9214
20:11@greggirwin I guess dedicated "reveal all" refinement is a good option, because this gave me [a lot of headache](https://github.com/9214/linden/blob/master/src/dol.red#L37) recently
maximvl
21:00is this a bug?
>> parse z: [] [x: (insert x 'a) y: skip]
== true
>> parse z: [] [x: (insert x 'a) y: 'a end]
== false
>> x
== [a]
>> y
== [a]
21:01inserting into the source and then trying to match it fails, while skip works
9214
21:04@maximvl insert continues match *after* the insertion
>> parse z: [] [x: insert 'a]
== true
>> z
== ['a]
maximvl
21:05but i'm not using insert keyword
9214
21:05@maximvl oh, my bad
maximvl
21:05I didn't even know it exists :D
21:07@9214 still
>> parse z: [] [x: insert 'a :x 'a]
== false
9214
21:08@maximvl though a is inserted in z
maximvl
21:08yes, then I backtrack the position and trying to parse it
9214
21:21
text
>> parse z: [] [x: (insert x 'a) :x thru 'a]
== true

dockimbel
07:31@maximvl That's a bug, though it need to retest with latest commit...
07:43Confirmed bug.
08:06I'm opening a ticket for it: https://github.com/red/red/issues/3060
08:26@9214 I should add something about reactor's mold specific behavior in the docs.
toomasv
08:32:point_up: [September 28, 2017 10:25 PM](https://gitter.im/red/bugs?at=59cd4cbfcfeed2eb65610d89) @dander [Corrected](https://github.com/toomasv/l-system/blob/master/l-system.red) Seems to work fine.
PeterWAWood
11:35This behaviour looks inconsistent:
>> t: 1.2.3.4.5.6
== 1.2.3.4.5.6
>> make tuple! [1 2 3 4 5.8 6 7]
== 1.2.3.4.5.6.7
>> t/5: 5.8
== 5.8
>> t
== 1.2.3.4.255.6
9214
11:40
text
>> x: 1.2.3
== 1.2.3
>> x/3: 3.2
== 3.2
>> x
== 1.2.0
>> x/3: 3.3
== 3.3
>> x
== 1.2.255
maximvl
12:11on Wine Red can't do networking:
>> do https://tinyurl.com/y9azl975
*** Access Error: cannot connect: https://tinyurl.com/y9azl975 reason: timeout
*** Where: read
*** Stack: do-file
>> read http://google.com
*** Access Error: cannot connect: http://google.com reason: timeout
*** Where: read
*** Stack:
12:11these are messages from Wine:
fixme:winhttp:winhttp_request_QueryInterface interface {06f29373-5c5a-4b54-b025-6ef1bf8abf0e} not implemented
fixme:ole:CoCreateInstanceEx no instance created for interface {06f29373-5c5a-4b54-b025-6ef1bf8abf0e} of class {2087c2f4-2cef-4953-a8ab-66779b670495}, hres is 0x80004002
fixme:winhttp:winhttp_request_QueryInterface interface {06f29373-5c5a-4b54-b025-6ef1bf8abf0e} not implemented
fixme:ole:CoCreateInstanceEx no instance created for interface {06f29373-5c5a-4b54-b025-6ef1bf8abf0e} of class {2087c2f4-2cef-4953-a8ab-66779b670495}, hres is 0x80004002
fixme:winhttp:winhttp_request_QueryInterface interface {06f29373-5c5a-4b54-b025-6ef1bf8abf0e} not implemented
fixme:ole:CoCreateInstanceEx no instance created for interface {06f29373-5c5a-4b54-b025-6ef1bf8abf0e} of class {2087c2f4-2cef-4953-a8ab-66779b670495}, hres is 0x80004002
9214
19:15can anyone with macOS check this? :point_right: https://gitter.im/red/red/system?at=59ce9b0ab20c642429a2b391
19:16[code to check](https://gitter.im/red/red/system?at=59ce98e5614889d47556300f)

maximvl
08:31and this one as well, it hangs right after spawning a window: do https://tinyurl.com/y9azl975
dockimbel
09:52@qtxie ^---

9214
09:14why op! doesn't allow to pass unevaluated operators?
>> bar: make op! func ['left 'right][]
== make op! [['left 'right]]
>> foo bar baz
*** Script Error: foo has no value
*** Where: bar
*** Stack:
dockimbel
11:05@9214 Not implemented yet, that would requires significant changes in the way infix are processed. Though, it's on my todo-list, just very low priority for now.
9214
11:16@dockimbel I'm curious, will function specs support flags/options like infix postfix prefix?
dockimbel
11:23@9214 Probably not, as it changes the way arguments are fetched and maybe even how the Red internal stack should work, so it would probably be better to use new datatypes instead. But, I don't see a need for such features for now, if you need them, you can write a custom interpreter and make it a dialect.
9214
21:13@dockimbel [The mother of bugs](https://github.com/9214/daruma) just gave birth to another amusing creature :beetle:
I have macro defined on [line 50](https://github.com/9214/daruma/blob/master/src/decoder.red#L50), but then I try to interpret this script:
*** Script Error: make-bge-base64 has no value
*** Where: encoding
*** Stack: context context

But hey, I know the drill - if I wrap all script into do/expand [...] block, it works (in fact it gives another error, but that's expected). Any ideas? I believe it worked roughly 2 weeks ago without a fuss.
23:13and I think this is unexpected
>> parse [set-word:] [quote set-word:]
== true
>> parse [set-word:] [quote set-word]
== true
>> parse [set-word:] [quote :set-word]
== true
>> parse [set-word:] [quote :set-word]
23:36I know that ahead set-word! quote set-word will do, but still
23:46I also encountered 2 more bugs:
* after defining new macro compiled exe is a dead corpse and Wine gives me runtime error
*** Runtime Error err:seh:raise_exception Unhandled exception code c0000005 flags 0 addr 0x4161e6

I'll try to test it on Win10 machine in the daytime and report back.
* again, after defining new macro attempt on script compilation results in a massive text wall of Red compiler internal error, which boils down to the fact that macro is pattern-matching and uses ahead, and boom:
*** Red Compiler Internal Error: Script Error : ahead has no value 
*** Where: expand 
*** Near:  [parse code rule: [

greggirwin
03:15@9214, you have to be pushing macros harder than anyone. :^)
dockimbel
03:34@9214 Remember that compiler's macros run on Rebol2, which does not have ahead in his Parse dialect.
03:35For the loose matching of any-words in Parse, it's a side-effect of fixing a bug in Parse a few days ago. I will see if this can be improved.
9214
06:57@dockimbel thanks, figured out ahead already, no clue regarding make-bge-base64 and bugged executable is dead, just checked on Win10
06:59should I fill a ticket addressing loose matching or is it already on your list?
07:17@dockimbel could you also share your vision of macro system and how it can be improved? Two things come to mind:
* Named macro and functions in execution context are just like any other function and should be first-class citizens. Say, if I have inc: func [x][x + 1] and I want to build macro from that function or make it usable from macro, I should copypaste it either inside #do [...] or in #macro inc: ... directive, but it would be nice if I could just set some flag in *that* function (e.g. inc: func [[macro] x][x + 1] instead of copypasting everything by hand. I have no idea how Red could distinguish between between macro call and function call though :D Also, I whish I could separate my macros (and execution context) in dedicated file(s) and just #include it anythere I need them instead of copypasting their definitions (and #do [...] context).
* Dependency of compiler's macros on R2 is something to be constantly aware of, otherwise you'll get your post-compiling bugs and sleepless mumbo-jumbo with debugging and stuff. And while it's possible to hack your way around with named macro, pattern matching macro are limited with R2 parse implementation.
07:20@greggirwin call me [3 #](http://wiki.c2.com/?ThreeStarProgrammer) programmer :^)
dockimbel
07:55@9214
> should I fill a ticket addressing loose matching or is it already on your list?

No need.
greggirwin
17:39@9214 :^) How about "all-star" programer?

9214
15:37@dockimbel and R2 parse doesn't havecollect/keep keywords either? This could explain why compiled exe is dead, though, why it didn't spit compiler internal error as with ahead in this case?

dockimbel
07:26@9214 Rebol's Parse does not have collect/keep support, yes. If you can make a short version that reproduces the crash, you can put it in a new ticket for investigation.
9214
11:37@dockimbel done https://github.com/red/red/issues/3069
12:04
text
Red []

#macro answer: func [][42]
a: answer

>> do %scratchpad.red
*** Script Error: answer has no value
*** Where: a
*** Stack:
12:07
text
Red []

do/expand [
    #macro answer: func [][42]
    c: answer
]

>> do %scratchpad.red
== 42

Again, I'm pretty confident that 2 weeks ago it just worked without do/expand wrapping
dockimbel
12:18@9214 If you can find the commit which is causing the regression, that would be helpful.
9214
12:19@dockimbel will do whatever I can :baby:
12:32On a first sight, the only commit somehow related to preprocessor is [this](https://github.com/red/red/commit/5d11266de100b9b6a9d37c2f5b967dc6d4179994), 22 days ago.
12:44though, compiling toolchain with this changes reverted ain't do the trick
12:46the thing is - this issue somehow magically disappeared when I reported #3069, I was able to interpret script with F6 hotkey from VSCode, but not to compile
12:49Uh-uh..?
>> do %scratchpad.red
*** Script Error: answer has no value
*** Where: a
*** Stack: do-file  

>> do load %scratchpad.red
== 42
>> do %scratchpad.red
== 42
dockimbel
12:51The last one is not significative as the macro is already loaded.
12:52do on file! will call internally [this high-level function](https://github.com/red/red/blob/master/environment/functions.red#L835). As you can see on line 840, it calls expand-directives on the loaded file.
9214
12:58
text
>> do expand-directives load {#macro answer: func [][42] a: answer}
*** Script Error: answer has no value
*** Where: answer
*** Stack:
13:01
text
>> do/expand load {#macro answer: func [][42] a: answer}
== 42
dockimbel
13:04@9214 Looks like something is broken in expand-directives.
9214
13:05@dockimbel uses [expand](https://github.com/red/red/blob/master/utils/preprocessor.r#L271)
13:11since macro directive is successfully [removed](https://github.com/red/red/blob/master/utils/preprocessor.r#L354) from loaded source, I suspect that [register-macro](https://github.com/red/red/blob/master/utils/preprocessor.r#L353) goes nuts and doesn't register answer as a macro?
dockimbel
13:23@9214 The macro is present, just not applied:
>> preprocessor/macros
== ['answer 
    (change/part s do-macro 'answer s 0 1) :s
]
9214
13:30so do-macro is guilty?
13:30@9214 how deep the rabbit hole goes? :rabbit:
13:53or perhaps it has something to do with loose parse matching of any-words?
dockimbel
16:14@9214 Pinpointing the exact cause will take some time, as the preprocessor's code is using many different features with some hairy code. I will dig into it tomorrow.
9214
16:19@dockimbel :+1:
dander
18:33I don't know if this is really considered a bug, but I think it's a bit confusing that about displays the build date of the cached console executable, rather than the date that red.exe was built. Is there a rationale for doing that? For example, from different runs of Red.exe located in my Downloads folder after clearing the cache:
>> about
Red for Windows version 0.6.3 built 29-Sep-2017/13:51:12-07:00
>> system/options/boot
== "C:\ProgramData\Red\gui-console-2017-8-3-49893.exe"

>> about
Red for Windows version 0.6.3 built 4-Oct-2017/11:24:09-07:00
>> system/options/boot
== "C:\ProgramData\Red\gui-console-2017-8-3-49893.exe"

dockimbel
01:17@dander Agreed, that needs to be improved to include the toolchain build date too. I would also like to have the commit hash included, though I'm not sure if there is a simple way to extract it from the git repo.
dander
03:27@dockimbel here are some potential options if you want to call git directly. Or would it be better to mine it out of one of the git text files? I'm willing to dig deeper if you want to be more specific.
>git log -n 1
commit 87e85d10a78c4aeb1e2bdc77de4c4c402a02f7c7
Author: Nenad Rakocevic <nr@red-lang.org>
Date:   Wed Oct 4 21:20:58 2017 +0800

    FIX: minor fix in the compilation output display.

>git describe
v0.6.3-235-g87e85d1

>git log -n 1 --pretty=format:%h
87e85d1
9214
03:30> simple way to extract it from the git repo

[this](https://github.com/rebolek/red-tools/blob/master/github-v3.red) and [that](http://www.red-lang.org/2013/11/041-introducing-parse.html)? :grimacing:
dander
03:40@9214 ooh, nice!
also this?
>> call/output "git log -n 1 --pretty=format:^"[short: {%h} long: {%H} date: %aI]^"" :out commit: load out
== [short: "87e85d1" long: "87e85d10a78c4aeb1e2bdc77de4c4c402a02f7c7" date: 4-Oct-2017/21:20:58+08:00]
dockimbel
05:14@9214 @dander Thanks! Extracting the information the git text files would be a simpler option, and as a fallback, scraping it from github website or API.
dander
08:16@dockimbel I think this should work
git-commit?: function [
    "Gets the latest (HEAD) commit hash from the current git repo"
][
    path: system/options/path
    ; look for the root of the git repo
    while [not exists? dirize path/.git][
        path: clean-path path/..
        if not exists? path [cause-error 'user 'message ["Could not find .git directory; this does not appear to be a Git repository"]]
    ]
    ; HEAD will either contain the hash of the latest commit (detached head) or a reference to the current branch file which contains it.
    ; i.e: "ref: refs/heads/master" which indicates the hash is in .git/refs/heads/master
    head: read path/.git/HEAD
    if find head "ref:" [
        ref: load head
        head: read path/.git/(ref/ref)
    ]
    trim/lines head
]
dockimbel
08:19@dander :+1: I will give it a try later today.
09:04@9214 It seems my fix for #3029 is the cause of the preprocessor's parsing going mad.
09:39Nope, finally the culprit was #3060.
9214
11:58@dockimbel thanks! will check later
12:13indeed, the mother of bugs is pleased with your offering :beetle: :womans_hat:
dockimbel
12:14@9214 I wouldn't dare to displease her. ;-)

PeterWAWood
08:57@dockimbel context processes a call to return in the spec block. It returns the argument value of the called return instead of the object.

>> o: context [x: 5 return 2 + x]
== 7
>> probe o
7
== 7

Rebol2 silently ignores the call to return:
>> o: context [x: 5 return 2 + x]
>> context [x: 5 return 2 + x]                                
>> probe o
make object! [
    x: 5
]


This looks like a bug to me.
9214
08:58but I considered that as a feature :confused:
dockimbel
10:17@PeterWAWood See my reply in red/red. R2 does not ignore it, it just catches the exception in make object! (all code after return 2 + x is not evaluated). R3 behaves the same as Red.

meijeru
11:08It would be different if context were a macro instead of a function, I supppose...

maximvl
07:46hi guys
07:46I tried to run Red under strace:
max@max-virtualbox ~/projects/typed $ strace red
execve("/home/max/bin/red", ["red"], [/* 62 vars */]) = 0
strace: [ Process PID=588 runs in 32 bit mode. ]
brk(NULL)                               = 0x9a4e000
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xf7781000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=141957, ...}) = 0
mmap2(NULL, 141957, PROT_READ, MAP_PRIVATE, 3, 0) = 0xf775e000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
open("/lib/i386-linux-gnu/libm.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\3\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\220E\0\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=341948, ...}) = 0
mmap2(NULL, 344144, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xf7709000
mmap2(0xf775c000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x52000) = 0xf775c000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
open("/lib/i386-linux-gnu/libdl.so.2", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0000\n\0\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=13828, ...}) = 0
mmap2(NULL, 16488, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xf7704000
mmap2(0xf7707000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2000) = 0xf7707000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
open("/lib/i386-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\3\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\320\207\1\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1786484, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xf77a8000
mmap2(NULL, 1792540, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xf754e000
mprotect(0xf76fd000, 4096, PROT_NONE)   = 0
mmap2(0xf76fe000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1af000) = 0xf76fe000
mmap2(0xf7701000, 10780, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xf7701000
close(3)                                = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xf754d000
set_thread_area({entry_number:-1, base_addr:0xf754d700, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0 (entry_number:12)
mprotect(0xf76fe000, 8192, PROT_READ)   = 0
mprotect(0xf7707000, 4096, PROT_READ)   = 0
mprotect(0xf775c000, 4096, PROT_READ)   = 0
mprotect(0xf77a9000, 4096, PROT_READ)   = 0
munmap(0xf775e000, 141957)              = 0
rt_sigaction(SIGCONT, {0x80a2cb0, [CONT], SA_RESTART}, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGTSTP, {0x80a3150, [TSTP], SA_RESTART}, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGINT, {0x80a4ad0, [INT], SA_RESTART}, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGTERM, {0x80a4ad0, [TERM], SA_RESTART}, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGHUP, {0x80a4ad0, [HUP], SA_RESTART}, {SIG_DFL, [], 0}, 8) = 0
brk(NULL)                               = 0x9a4e000
brk(0x9a71000)                          = 0x9a71000
mmap2(NULL, 528384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xf74cc000
mmap2(NULL, 528384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xf744b000
brk(0x9a94000)                          = 0x9a94000
brk(0x9ab5000)                          = 0x9ab5000
brk(0x9ad6000)                          = 0x9ad6000
gettimeofday({2787310729019563, -35154101159329788}, NULL) = 0
open("/etc/localtime", O_RDONLY|O_CLOEXEC) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=2943, ...}) = 0
fstat64(3, {st_mode=S_IFREG|0644, st_size=2943, ...}) = 0
read(3, "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\16\0\0\0\16\0\0\0\0"..., 4096) = 2943
_llseek(3, -28, [2915], SEEK_CUR)       = 0
read(3, "\nCET-1CEST,M3.5.0,M10.5.0/3\n", 4096) = 28
close(3)                                = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2943, ...}) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2943, ...}) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2943, ...}) = 0
brk(0x9af7000)                          = 0x9af7000
getcwd("/home/max/projects/typed", 50)  = 25
brk(0x9b1a000)                          = 0x9b1a000
brk(0x9b17000)                          = 0x9b17000
brk(0x9b16000)                          = 0x9b16000
gettimeofday({2815661808140459, -35152997360919260}, NULL) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2943, ...}) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2943, ...}) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2943, ...}) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2943, ...}) = 0
stat64("/home/max/projects/typed/none", 0xff831050) = -1 ENOENT (No such file or directory)
stat64("/usr/local/bin/netscape", 0xff831050) = -1 ENOENT (No such file or directory)
stat64("/usr/bin/netscape", 0xff831050) = -1 ENOENT (No such file or directory)
gettimeofday({2822280352743595, -35152997360919260}, NULL) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2943, ...}) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2943, ...}) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2943, ...}) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2943, ...}) = 0
gettimeofday({2825402793967787, -35152997360919260}, NULL) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2943, ...}) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2943, ...}) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2943, ...}) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2943, ...}) = 0
gettimeofday({2828649789243563, -35152997360919260}, NULL) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2943, ...}) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2943, ...}) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2943, ...}) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2943, ...}) = 0
gettimeofday({2832712828305579, -35152997360919260}, NULL) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2943, ...}) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2943, ...}) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2943, ...}) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2943, ...}) = 0
gettimeofday({2844412319219883, -35152997360919260}, NULL) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2943, ...}) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2943, ...}) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2943, ...}) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2943, ...}) = 0
gettimeofday({2848578437497003, -35152997360919260}, NULL) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2943, ...}) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2943, ...}) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2943, ...}) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2943, ...}) = 0
gettimeofday({2851151122907307, -35152997360919260}, NULL) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2943, ...}) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2943, ...}) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2943, ...}) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2943, ...}) = 0
gettimeofday({2853530534789291, -35152997360919260}, NULL) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2943, ...}) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2943, ...}) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2943, ...}) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2943, ...}) = 0
gettimeofday({2855343010988203, -35152997360919260}, NULL) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2943, ...}) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2943, ...}) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2943, ...}) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2943, ...}) = 0
gettimeofday({2858534171689131, -35152997360919260}, NULL) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2943, ...}) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2943, ...}) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2943, ...}) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2943, ...}) = 0
getpeername(0, 0xff831d74, 0xff831d70)  = -1 ENOTSOCK (Socket operation on non-socket)
open("/home/max/license.key", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/max/projects/typed/license.key", O_RDONLY) = -1 ENOENT (No such file or directory)
mmap2(NULL, 790528, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xf738a000
open("/usr/bin/strace", O_RDONLY)       = 3
lseek(3, 464260, SEEK_SET)              = 464260
read(3, "H\211\373\350\24\357\376\377H\213s H\211\337\350\30\375\377\377H\215=u\306\0\0\350lr\377\377"..., 116) = 116
read(3, "\30\306\0\0\350\17r\377\377H\213s0H\215\25\226O\0\0H\215=\315\303\"\0\350(\346\377\377"..., 66) = 66
read(3, "d$\1dH\213\4%(\0\0\0H\211D$\0301\300\350\276q\377\377\17\266\34$L\215l$"..., 785638) = 402038
close(3)                                = 0
mmap2(NULL, 1032675328, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb9ab4000
write(1, "** Script Error: ", 17** Script Error: )       = 17
write(1, "Invalid compressed data - proble"..., 37Invalid compressed data - problem: -3) = 37
write(1, "\n", 1
)                       = 1
write(1, "** Near: ", 9** Near: )                = 9
write(1, "script: decapsulate \nif none? sc"..., 36script: decapsulate 
if none? script) = 36
write(1, "\n", 1
)                       = 1
exit_group(0)                           = ?
+++ exited with 0 +++
07:48so the first thing is it crashes
07:48the second one - what are the license keys it tries to read?
open("/home/max/license.key", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/max/projects/typed/license.key", O_RDONLY) = -1 ENOENT (No such file or directory)
9214
07:48Rebol SDK license?
maximvl
07:49idk but is Rebol still embedded into the Red binary?
07:49I thought whole compiled binary is generated by Red compiler and Rebol is only needed to run the compiler, not to be included into the result
PeterWAWood
08:12The Red binary that is distributed is built with the Rebol encapper (part of the Rebol SDK). Rebol is embedded in the resultant binary.
08:14The Red binary is not compiled.
08:14A Red program, such as the console, is compiled and does not require Rebol to run.
maximvl
08:14I see, thanks
dockimbel
09:22> I tried to run Red under strace

Actually no, you are running a Rebol executable under strace. ;-) The Red toolchain is written in Rebol.
maximvl
11:55I broke Red:
>> typed [x z: x]

*** Runtime Error 1: access violation
*** at: 0806D8DBh
max@max-virtualbox ~/projects/typed $
11:56and it's reproducible, do you need a script?
dockimbel
12:22@maximvl A script, yes please, and a new ticket.
maximvl
12:59done, I added prints to the code around crashing point

9214
09:12am I dumb or this thing refuses to work?
probe expand-directives [
#macro [ahead set-word! quote lookup-table block!] func [[manual] s e][
    s/2: reverse s/2
    e
]
lookup-table: [<1> 2 3 <4> 5 6]
]

[
    lookup-table: [<1> 2 3 <4> 5 6]
]

I expected [6 5 <4> 3 2 <1>]
09:13
text
probe expand-directives [
#macro [ahead set-word! quote lookup-table block!] func [[manual] s e][
    s/2: reduce [reverse s/2]
    e
]
lookup-table: [<1> 2 3 <4> 5 6]
]

[
    lookup-table: [[[6 5 <4> 3 2 <1>]]]
]
09:37looks like macro matches twice and reverses series back to normal?
09:39ah, expand-directives causes block to be preprocessed second time
09:49@dockimbel I don't see any info about -e flag on --help screen
09:50and it doesn't seems to work at all, I still get compiler internal error about ahead having no value :(
dockimbel
09:53@9214 Your macro does not work when compiled? (Seems ok from the console). Yes, expand-directives invokes the preprocessor.
9214
09:54@dockimbel It won't work if I compile with -c, because of R2 limitations, and -e aint do the trick
09:54or I'm doing something wrong
dockimbel
09:56-e is experimental and may be replaced by a different command-line syntax. Actually, the compiler's preprocessor will still be invoked on the source code, even in that encapped mode. Such behavior could be blocked, but it then defeats the purpose of macros in Red, which are a compile-time optimisation. Using macros in interpreted code is useless, as you can do the preprocessing in the code itself without any external framework. The only reason macros are resolved in the interpreter is for compatibility with compiled code. You really don't need them otherwise. That's why they never made it in Rebol after two decades of usage, it's just useless for an interpreted homoiconic language.
9214
10:08so far I've used macros to pre-process and pre-compute some data before actual script is compiled/interpreted
10:11and right now I created another such preprocessing transformation on data table, which works fine interpreted but which underlying R2 can't process, so I thought that -e is my savior
dockimbel
10:12You need to stick to R2-compatible code when writing macros. Unless you really benefit from using the preprocessor and the macros system it provides, you might be better with just preprocessing your code in a custom way at run-time. In such case, you can just use Red code and forget about R2.
9214
10:12@dockimbel yeah, believe me I got that already :smile:
17:09@dockimbel you mentioned "custom way of preprocessing at run-time", you mean create another script which will preprocess all stuff in another script? Again, I want this data transformation to happen exactly once before code is evaluated (or compiled), without any overhead at runtime, and I thought that this is what macros do.

dockimbel
03:58@9214 No need for another script, just inline it in your main script. Yes, no overhead at run-time is what compiled macros give you. But if you can't notice the run-time overhead in the first place, then it's not really worth the trouble of using macros. Just use regular code transformations (macros are just a very thin syntactic sugar for that anyway, at least for now).

dsunanda
08:52Red-0.6.3 under Win 10
console crash with
difference [] [none]
dockimbel
09:02@dsunanda Good catch! Please open a ticket for it if you have a github account.
dsunanda
09:07Thanks - done #3081
09:11Red-0.6.3 under Win10
Weirdness with APPEND/DUP:
append/dup [] "x" 3.2 ;; <--- non-interger dup count
r3 === ["x" "x" "x"] ;; R3 treats /DUP float as an INTEGER
Red === [] ;; Red treats /DUP float as zero
append/dup [] "x" 3.3
r3 === ["x" "x" "x"]
Red === [] ;; Internal Error: not enough memory
Weirder still:
append/dup [] "x" 3.2999
Red === []
append/dup [] "x" 3.29999
Red === *** Internal Error: not enough memory
dockimbel
09:13@dsunanda I think that feature is just not implemented in the code.

PeterWAWood
11:21When compiled the following code raises a runtime script error:
Red [] 
list-dir %./
11:23
text
./test
*** Script Error: path none is not valid for none! type
*** Where: eval-path
*** Stack:

Is this because it is not designed to run in a complied program?
dockimbel
15:00@PeterWAWood list-dir purpose's is to print a list of files inside the console. Therefore, it relies on system/console/size for that, but the console is not there when you compile the script. What is the use-case for using list-dir in a compiled script?
greggirwin
15:38I don't think Peter has a use case, just that a newer user writing tests hit this behavior.
15:40Help also uses the system console size. Maybe we could standardize on a default if that isn't there.
PeterWAWood
23:18@dockimbel The question on list-dir came about when writing tests for environment/functions.redin which it is defined. If it is a console only function, wouldn't it be better in a file under in environment/console/?

dockimbel
04:48@PeterWAWood Yes, I think so. Done.
meijeru
09:00:+1: I note that the (near-)synonyms of list-dir, namely ls dir and ll were already in console/engine.red.

dander
08:40There seems to be an issue with sort/all and args passed to a custom compare function with /all. After making the block longer, it doesn't pass both params...
>> comp: func [a b][probe reduce [a b] probe either a/2 = b/2 [a/1 < b/1] [a/2 > b/2]]
== func [a b][probe reduce [a b] probe either a/2 = b/2 [a/1 < b/1] [a/2 > b/2]]
>> sort/all/skip/compare [#"b" 1 #"a" 1  #"d" 1 #"e" 2 #"c" 2 #"f" 2 #"g" 2] 2 :comp
[[#"a" 1] [#"b" 1]]
true
[[#"d" 1] [#"b" 1]]
false
[[#"e" 2] [#"d" 1]]
true
(snip)
== [#"c" 2 #"e" 2 #"f" 2 #"g" 2 #"a" 1 #"b" 1 #"d" 1]

>> sort/all/skip/compare [#"b" 1 #"a" 1  #"d" 1 #"e" 2 #"c" 2 #"f" 2 #"g" 2 #"h" 1] 2 :comp
[#"c" #"b"]
*** Script Error: path a/2 is not valid for char! type
*** Where: =
*** Stack: probe
dockimbel
10:20@qtxie ^----
qtxie
10:46@dander It's a bug. Please open a ticket for it.
dander
16:14@qtxie #3086 opened

PeterWAWood
04:59This code compiles but raises an access violation when run under macOS:
Red [] 
#system [
	#call [probe 1]
]

*** Runtime Error 1: access violation
*** at: A1742F52h
05:14I get the same crash on Ubuntu 32.
dockimbel
07:23@PeterWAWood #call does not do any boxing/unboxing of the argument values. In the above code, you are passing a red-value! pointer of value 1, causing the crash. You need to provide valid Red values (pointers to red-! structs).
PeterWAWood
07:27@dockimbel Thanks. Should I update the Red/System spec as it says:

"The arguments should be passed as pointers to Red values of the expected type, except for integer! and logic! datatypes, that can be passed inlined, without requiring any boxing. When required, for pointer arguments, a simple type casting is allowed." in [#call](http://static.red-lang.org/red-system-specs.html#section-16.8).
dockimbel
07:38@PeterWAWood Let me recheck that in the compiler's code first.
greggirwin
18:23:point_up: [October 22, 2017 10:14 AM](https://gitter.im/red/bugs?at=59ecc3d0614889d475e787fa) I poked a bit and added comments to #3086.

PeterWAWood
02:23Here is a screenshot showing a couple of Red console zombies. I suspect this is related to the issue that @rebolek and I have mentioned before.
02:23[![macOS Red Console Zombies.png](https://files.gitter.im/red/bugs/lQMA/thumb/macOS-Red-Console-Zombies.png)](https://files.gitter.im/red/bugs/lQMA/macOS-Red-Console-Zombies.png)
02:35I was using a console built against the latest master.

toomasv
07:40I use same laptop (Thinkpad) on workplace with big display and at home without it. Red console opened at home and at work scale differently. Console can be just reopened to set it stright, but View windows texts do not adapt. Some confusion with metrics. Is it possible to adjust this behaviour or do I have just to restart computer to get correct metrics?
![scaling-problem](http://toomas.vooglaid.ee/red/scale-problem.png)
qtxie
09:02@toomasv Do you use latest red binary or 0.6.3?
toomasv
09:04@qtxie
>> system/build
== make object! [
    date: 17-Oct-2017/17:00:48+03:00
qtxie
09:16Does reboot work? The view engine doesn't handle dynamically DPI changing for now.
toomasv
09:48@qtxie Yes, reboot works.

9214
08:31with anything but text in the first line it works, but with text there's no, well, text
>> text: "test"
== "test"
>> view [panel [text with [text: text]]]
greggirwin
17:52It's not referencing your global text in that example. That is, it works without defining text, because text is in the working context already.
>> view [panel [text with [text: probe text]]]
none
9214
17:53@greggirwin right, thanks Gregg, you reminded me that with block is binded to current face

toomasv
20:55Is this a bug?
>> blk: [23 #"g" 56 11 #"8"]
== [23 #"g" 56 11 #"8"]
>> find blk #"8"
== [56 11 #"8"]

It seems #"8" is implicitly cast to integer in find:
>> to-integer #"8"
== 56
rebolek
20:57@toomasv I vote for bug, Rebol returns [#"8"]
toomasv
20:59@rebolek It seems so indeed:
>> find blk #"g"
== [#"g" 56 11 #"8"]
>> to-integer #"g"
== 103
>> insert blk 103
== [23 #"g" 56 11 #"8"]
>> find blk #"g"
== [103 23 #"g" 56 11 #"8"]
Oldes
21:16@toomasv You can use find/case, but I think it is more bug than feature.
21:17
>> find/case [b 103 a] #"g"
== none
>> find/case [b 103 a] 103
== [103 a]

toomasv
04:22@Oldes OK, thanks!

9214
17:40any [bug? not intended? I'm-doing-something-wrong?]
>> ? bind
USAGE:
     BIND word context

DESCRIPTION: 
     BIND is a native! value.

ARGUMENTS:
     word         [block! any-word!] 
     context      [any-word! any-object! function!] 

REFINEMENTS:
     /copy        => 

RETURNS:
     [block! any-word!]

>> do bind [x] has [x][x: 1]
*** Script Error: x is not in the specified context
*** Where: do
*** Stack:
greggirwin
18:30I *think* not by design, but @dockimbel would have to say.
>> fn: has [x][x: 1]
== func [/local x][x: 1]
>> context? first bind [x] :fn
== func [/local x][x: 1]
>> same? :fn context? first bind [x] :fn
== true

dockimbel
09:35@greggirwin @9214 Function contexts only exist when the function is under evaluation (same as in Rebol3), so the error there is legitimate, as the function is not running when [x] is evaluated. But the error message is not very accurate (it was copied from Rebol3), so it probably needs to be changed to something like "context for x is not available".
9214
13:46@dockimbel so [x] is bounded, but its context is missing? That's interesting, and how one can evaluate [x] "in parallel" with function evaluation?
dockimbel
15:31@9214 Function's context are allocated on the stack (objects and closures ones are on the heap), so you need to have the function called to have its context available. Though the function does not need to be the currently called one, just somewhere in the call chain. When the context is available, then any word bound to that function's context can be evaluated. When the function is not in the call stack anymore, its context becomes unavailable. Closures will not have this limitation, but they will have a memory and performance overhead. For the record, Rebol2 puts function contexts on the heap, while Rebol3 puts them on the stack (like Red).
greggirwin
17:51Great explanation. Thanks @dockimbel. Added to https://github.com/red/red/wiki/Guru-Meditations

9214
02:30@dockimbel @greggirwin
>> foo: has [x][x: 'cool bar]
== func [/local x][x: 'cool bar]
>> bar: does [do bind [x] :foo]
== func [][do bind [x] :foo]
>> foo
== cool
02:40
text
>> foo: has [x /bar][if bar [return do bind [x] :foo] x: 'cool foo/bar]
== func [/local x /bar][if bar [return do bind [x] :foo] x: 'cool foo/bar]
>> foo
== cool
02:41now I wonder what are the use cases :mortar_board:
02:45I think it would be rather interesting to check out after parallelism and concurrency are implemented
02:55more representative example
>> foo: has [x /bar][if bar [return do block] x: 'cool foo/bar]
== func [/local x /bar][if bar [return do block] x: 'cool foo/bar]
>> block: [do bind [x] :foo]
== [do bind [x] :foo]
>> do block
*** Script Error: x is not in the specified context
*** Where: do
*** Stack:  

>> foo
== cool
>> do block
*** Script Error: x is not in the specified context
*** Where: do
*** Stack:
greggirwin
17:53One thought is something like aspect oriented programming, or tracing, but may need more thought on function reflection and such. You could certainly build your own conventions, but I still want to think about how we can instrument all our Red apps with something like a DTrace system.

PeterWAWood
01:07@dockimbel The help text for length? species that the argument must a series. However, length? currently accepts a map! and returns the number of entries as its length. length? does not accept an object!.

Is it intended for length? to work on map!s?

Given that determining the number of "entries" in both map!s and object!s is trivial with length? words-of, is it necessary for length? to work directly on map!s?

dockimbel
05:21@PeterWAWood Good point. Yes, it could work with words-of, though that is more much resource-consuming, but also you rarely need it, that might not really matter in practice. As map! is more object-like than series-like, it would make sense to support objects too then if we keep it for maps. So I'm undecided on that.
greggirwin
05:46The question for me is how it would be used. That is, without using words-of/values-of in conjunction with it, what do you use it for? Perhaps useful when you only need to know the length ("There are 19 items in X"), but you can't iterate or pick with it.
9214
08:33
text
partition: function [elems [block!] group [integer!]][
    parse elems [
        collect some [keep group skip | [collect keep to end]]
    ]
]

probe partition [1 2 3 4 5 6 7 8 9] 2

*** Runtime Error 1: access violation
*** at: 0805B384h

The cause is to keyword which seems to throw parse into an infinite loop.
dockimbel
08:34@9214 Confirmed, please log it in a ticket.
9214
08:34sir yes sir :guardsman:
08:50@dockimbel though, I'm not really sure what the cause is: using various @greggirwin's profile setups (see [here](https://gitter.im/red/help?at=5a0aad6aba39a53f1a9953a0)):
profile/show/count collect [
    repeat i samples [
        keep/only compose [
            partition (to word! rejoin ['elems i]) group]
    ]
] 100

*** Math Error: math or number overflow
*** Where: -
*** Stack: profile collect

and with count increased up to 1000
*** Runtime Error 1: access violation
*** at: F76C5D60h
greggirwin
19:07I commented on the ticket @9214. I think it's just running out of memory.

9214
02:04@greggirwin thanks!

xqlab
10:28
take/part [1] -1

with negative length causes closing of the console without an error
meijeru
10:37Confirmed. Worth a ticket (issue).
dockimbel
10:46Good catch!

endo64
01:34@qtxie Can you check below crashing code:
Red [
	Needs:	View
]
;system/view/auto-sync?: false

a: make face! [type: 'base color: red   offset: 120x120 size: 50x50]
b: make face! [type: 'base size: 50x50]

win: make face! [
	type:	'window
	size:	400x400
	pane: reduce [a]
	actors: object [
		on-down: function [face event] [
			append face/pane make b [color: random white offset: random 150x150]
			move find/same win/pane a tail win/pane
			show win	; <<< crashes if auto-sync is OFF!
		]
	]
]
view win
01:36This one doesn't crash with auto-sync ON or OFF:
on-down: function [face event] [
			append face/pane make b [color: random white offset: random 150x150]
			show win  ; this prevents the crash
			move find/same win/pane a tail win/pane
			show win
		]

rebolek
07:38 I know it's because floating point numbers, but seems strange anyway:
>> x: 1% while [x < 10%][x: x + 1%]
>> x
== 11%
qtxie
08:30@endo64 I can reproduce it with the latest Red. But no crashes in 0.6.4 branch.

9214
08:52Is that by design? It's surprising that do can automatically load string! value, I expected it to return "foo".
>> foo: 'bar
== bar
>> do "foo"
== bar
rebolek
09:02@9214 Yes, that's by design. See these examples:
>> do "1 + 2"
== 3
>> do "{foo}"
== "foo"
9214
09:11@rebolek I'll put this ace in my sleeve then... :black_joker:
>> do "11 + 2"
== 13
>> do next "11 + 2"
== 3
rebolek
09:15:thumbsup:
9214
10:32is it okay that I can't use set-word! syntax on everything that starts with <?
>> <: 1
*** Syntax Error: invalid tag! at "<: 1"
*** Where: do
*** Stack: load
toomasv
17:28Bug?
>> to-date to-integer 1-Jan-1970/0:00:01
== 1-Jan-1970/0:00:01
>> to-date to-integer 11-9-1561/4:35:13
== 1-Jan-1970/0:00:01

endo64
18:27I think its 32 bit integer boundary.
greggirwin
19:49@9214, yes, there are limitations in lexing.
19:49Also, while we *can* do strings, it's one of those things we want to be careful of.
19:50Just like doing untrusted blocks.
20:05@toomasv @endo64 combination of limits at work I imagine
- https://doc.red-lang.org/en/date.html#_abstract
- https://doc.red-lang.org/en/date.html#_conversions

i.e. casting to epoch time limits what makes sense, and 1561 doesn't. Seems to be windowed at 1901.

greggirwin
01:16Can someone confirm that I'm losing my mind?
>> m: #(a: 1 b: [2])
== #(
    a: 1
    b: [2]
)
>> mm: copy m
== #(
    a: 1
    b: [2]
)
>> mmm: copy/deep m
== #(
    a: 1
    b: [2]
)
>> same? m/b mm/b
== false    ; should be true
>> same? m/b mmm/b
== false
>> same? mm/b mmm/b
== true     ; should be false
PeterWAWood
02:06@greggirwin It looks looks like a bug in copy to me:
>> m: #(a: 1 b: [2])
== #(
    a: 1
    b: [2]
)
>> mm: copy m
== #(
    a: 1
    b: [2]
)
>> same? mm/b m/b
== true
>> mmm: copy/deep m
== #(
    a: 1
    b: [2]
)
>> same? mm/b m/b
== false
>> same? mm/b mmm/b
== true
03:27It seems only to affect map!. I tried with block! and object! and they are not affected.
greggirwin
03:42I tested those as well, to be sure I wasn't too off base. I'll report it tomorrow if nobody else beats me to it.
PeterWAWood
03:47I'll do it.
04:03#3118
greggirwin
17:10Thanks Peter.
endo64
21:19@qtxie I think the latest build of Red has some issues, below code was working before:
test: make face! [
	type: 'base
	myfunc:	does [ 'nothing ]
]
*** Script Error: old has no value
*** Where: series?
*** Stack: series?
greggirwin
22:26Error trying to add any new word when making a face it seems?

qtxie
02:36@endo64 Thanks. I can reproduce the error.
06:48Open a ticket for it: #3122

toomasv
15:42I am playing with a tree structure. Something strange happens when trying to get ancestors or descendants of a node. Seems to be some reference issue. See below.
make object! [
	label: none
	parent: none
	root: does [
		either self/root? [self][
			first self/ancestors
		]
	]
	children: copy []
	siblings: does [
		exclude parent/children reduce [self]
	]
	; NB! needs to be copied as `descendants-list: copy node/descendants` 
	; otherwise crashes
	descendants: func [/into list][
		list: any [list copy []]
		if not empty? children [
			append list copy children
			foreach child children [
				child/descendants/into list 
			]
		] copy list
	] 
	; NB! needs to be copied `ancestors-list: copy node/ancestors` 
	; otherwise crashes
	ancestors: has [list ancestor][
		list: copy []
		ancestor: parent
		while [ancestor][
			insert list ancestor
			ancestor: ancestor/parent
		] copy list
	] 
	root?: does [not to-logic parent]
	leaf?: does [empty? children]
	branch?: does [not leaf?]
	external?: does [leaf?]
	internal?: does [branch?]
	; e.g. node/count/condition node/children 'internal?
	count: func [what /condition cond /local n][
		either condition [
			n: 0
			forall what [if what/1/:cond [n: n + 1]]
			n
		][
			length? what
		]
	]
	degree: does [length? children]
	depth: does [length? ancestors]
	level: does [depth + 1]
	set 'node func [label parent /local me my][
		me: my: make object! self
		my/label: copy label
		if parent [
			my/parent: parent
			append parent/children me
		]
		me
	]
]

n1: node "1" none
n2: node "2" n1
n3: node "3" n2
n4: node "4" n2
n5: node "5" n3
n6: node "6" n4
n7: node "7" n4
n8: node "8" n7

So far so good.
>> length? n1/descendants
== 7
>> length? n8/ancestors
== 4
>> foreach d copy n1/descendants [probe d/label]
"2"
"3"
"4"
"5"
"6"
"7"
"8"
== "8"
>> length? n7/ancestors
== 3
>> foreach d copy n7/ancestors [probe d/label]
"1"
"2"
"4"
== "4"

But why do I need copy here? Te result is copied already:
descendants: func [/into list][
	list: any [list copy []]
	if not empty? children [
		append list copy children
		foreach child children [
			child/descendants/into list 
		]
	] copy list
] 
ancestors: has [list ancestor][
	list: copy []
	ancestor: parent
	while [ancestor][
		insert list ancestor
		ancestor: ancestor/parent
	] copy list
]

Looping without copy results in Error:
>> foreach d n1/descendants [probe d/label]
*** Script Error: invalid argument: make object! [label: "2" parent: make object! [label: "1" ...

And even worse, setting without copy (d: n1/descendants) crashes the console, while d: copy n1/descendants works well.

Any thoughts?
greggirwin
19:04Something about foreach accessing the underlying the func rather than the result?
>> n1/descendants/1
*** Script Error: descendants has no refinement called 1
*** Where: descendants
*** Stack:

>> d: copy n1/descendants 
== [make object! [
    label: "2"
    parent: make object! [
        label: "1"
        parent: none
        root: fu...
>> d/1
== make object! [
    label: "2"
    parent: make object! [
        label: "1"
        parent: none
        root: fun...
19:09i.e. something in the stack handling getting confused? This works: foreach d probe n1/descendants [d/label] Shoot. Console just vanished while experimenting.
19:11Just doing des: n1/descendants dupes it.
19:12I'll have to come back to this later.
toomasv
20:16@greggirwin Yep, setting without copyconsistently crashes the console.
greggirwin
20:21And foreach sets a word each time, so they may have a related issue.
20:22Need to come up with a minimal test case that shows the problem.
20:32Deep cloning at me: my: make object! self doesn't fix it.
20:34Back later for more.

toomasv
08:00Interesting:
a: copy []
same? copy a a
;== false
;But:
same? copy n1/descendants n1/descendants
;== true
same? copy n2/ancestors n2/ancestors
;== true
;But also:
same? a copy a
;== false
;And:
same? n1/descendants copy n1/descendants
;== false
same? n2/ancestors copy n2/ancestors
;== false
09:53This is as minimal, as I can make it:
n: object [l: none x: none asc: has [a l][l: copy [] a: x while [a][insert l a a: a/x] copy l]]
n1: make n [l: "1" x: none]
n2: make n [l: "2" x: n1]
foreach y n2/asc [probe y/l]
*** Script Error: invalid argument: make object! [l: "1" x: none asc: func [/local a l][l: copy [] a: x while [a] [insert l a a: a/x] copy l]]
*** Where: foreach
*** Stack:  
>> type? n2/asc
== block!
>> length? n2/asc
== 1

But:
>> foreach y copy n2/asc [probe y/l]
"1"
== "1"
>> foreach y to-block n2/asc [probe y/l]
"1"
== "1"
12:23And this seems to concern funcs operating from within objects. With global funcs it works well:
n: object [l: none x: none]
asc: func [n /local a l][l: copy [] a: n/x while [a][insert l a a: a/x] copy l]
n1: make n [l: "1" x: none]
n2: make n [l: "2" x: n1]
>> foreach y asc n2 [probe y/l]
"1"
== "1"

But not from inside object:
>> m: object [asc: func [n /local a l][l: copy [] a: n/x while [a][insert l a a: a/x] copy l]]
== make object! [
    asc: func [n /local a l][l: copy [] a: n/x while [a] [insert l a a: a/x] copy l]
]
>> foreach y m/asc n2 [probe y/l]
*** Script Error: invalid argument: make object! [l: "1" x: none]
*** Where: foreach
*** Stack:
greggirwin
19:51Reproduced here. If you do bang: n2/asc it kills the process. Please file a ticket.
toomasv
20:47#3128
greggirwin
21:06Thanks @toomasv
endo64
22:08@qtxie #3122 is fixed by @dockimbel , but below code was working before but not anymore:
view make face! [
	type: 'window
	color: red
	size: 100x100
	f1: does [f2]
	f2: does [print "ok"]
]
; *** Script Error: f2 has no value
22:09even f1 is not executed it requires f2 to be defined before f1.
22:11Another question: Why ok printed 3 times for below code:
view make face! [
	type: 'window
	color: red
	size: 100x100
	f1: does [print "ok"]
	f1
]
;ok
;ok
;ok
22:18Inner functions are called multiple times during creation, even without calling it:
make face! [
	type: 'base
	size: 100x100
	f1: does [print "ok"]
]
;ok
;ok
greggirwin
23:12Please open a new ticket, and reference #3122. Good catch.

endo64
06:46Done, #3131
07:40@dockimbel I've fixed #3131.
In the same commit I also fixed #3122 *** Script Error: old has no value issue if system/view/debug? true
07:44That commit goes with my previous PR #3073 , is that ok or should I make it on a different branch and another PR?

endo64
18:34@dockimbel I've fixed issue #3132 and added a PR #3134

9214
09:01script:
forever [[][reduce []]

Note the absence of Red header. I would expect get "Red header not found!" error, but instead:
*** Syntax Error: invalid value at "]"
*** Where: do
*** Stack: load
13:06
text
>> x: [1 2 3]
== [1 2 3]
>> move/part x next x 3

crashes the console
toomasv
13:15Confirmed here.
9214
13:16One way ticket, [one way ticket](https://www.youtube.com/watch?v=g_jUtiKSf1Y) to the :bug:-tracker
greggirwin
19:12Nice track. :^)

9214
08:19
text
>> parse ["1" "2"][some [copy match string!]]
== true
>> match
== ["2"]

I expect match to be just "2"
rebolek
08:21@9214 Use set then.
9214
08:21@rebolek right, figured out already, thanks!

endo64
21:05break doesn't reset series internal pointer to head when used in forall, is this behavior by design?
>> s: "12345" forall s [all [s/1 = #"3" break]] s
== "345"

greggirwin
21:54I believe that's by design. If it didn't, you'd have to track that yourself when breaking.

endo64
07:31I see, so this pattern can be used when necessary. Thanks!
>> s: "12345" forall s [all [s/1 = #"3" also s: head s break]] s
== "12345"
maximvl
11:18this is clearly a bug:
>> to-float "1e-18"
== 0.0
>> zero? to-float "1e-18"
== false
>> 5 * to-float "1e-18"
== 0.0
11:18either on printing or in logic
rebolek
11:18in printing IMO. Mold does this to prevent things like 1 + 2 = 3.0000000000000000000001
maximvl
11:19
>> 100000000000 * to-float "1e-18"
== 1.0e-7
11:19@rebolek looks like printing
11:20
>> to-float "1e-17"
== 0.0
>> to-float "1e-16"
== 0.0
>> to-float "1e-15"
== 1.0e-15
dockimbel
13:21@maximvl Good catch. Floats are really a never-ending source of troubles. ;-) Hopefully, we can have a decent BCD implementation next year, and finalize our dtoa() port in R/S.
9214
17:56poked around parse.reds and thought that case is some undocumented keyword (if so, what is it for?), but
parse [][case]

crashes the console
*** Runtime Error 1: access violation
*** at: F76D1FFCh
greggirwin
20:32Case sensitive string parsing:
>> parse "aaA" [some #"a"]
== true
>> parse/case "aaA" [some #"a"]
== false
20:34The crash is probably worth reporting though. I'm guessing it's a regression.

9214
07:07@greggirwin I know about /case refinement, but [this one](https://github.com/red/red/blob/master/runtime/parse.reds#L139) seems to be actual rule
dockimbel
08:48@9214 See "Parse dialect" section in latest blog [entry](http://www.red-lang.org/2017/07/063-macos-gui-backend.html).
9214
09:17@dockimbel :+1:
09:26s/rule/keyword
greggirwin
20:05My confusion @9214.

9214
12:36there's some trouble with menus on MacOS :point_right: [here](https://gitter.im/red/red?at=5a4162c4ffa3e379197c6b34)
qtxie
12:44@9214 Would you please open a ticket for it? I'll check it later.
9214
12:46@qtxie sure
qtxie
12:47@9214 Thanks. :smile:
9214
18:29:confused:
>> foo: func ['a [any-type!] 'b [any-type!]][probe :a probe :b]
== func ['a [any-type!] 'b [any-type!]][probe :a probe :b]
>> foo
unset
unset
>> foo 1
1
unset
>> foo 1 2
1
2
== 2
19:42:point_up: is this a bug or a feature? I don't get from where unset pops up, and it won't work if arguments aren't quoted and unset! is not listed in typeset (here its any-type!, so unset values are allowed)
rebolek
20:37@9214 This is feature to support i.e. both ? and ? something in console.
20:46With bit effort, you can use it to fake variadic functions, but then you need to enclose each function call in do [] block.
20:46It's not worth it ;)
9214
20:49@rebolek yes, now I remembered that @greggirwin showed that trick with variadic function long time ago
rebolek
20:53IMO something like f [random number of args] is much easier.
9214
20:53https://github.com/red/red/wiki/Guru-Meditations#variadic-function
rebolek
21:01Cool.

maximvl
11:00there are some shenanigans going on with append to a list
11:00I have this code executed in a loop
append prefixes probe to-word name
probe length? prefixes
11:00and this is a piece of output:
56
n
57
p
58
f
59
a
60
z
61
y
62
US
2
survey
3
geodetic
4
Zena
3
Duna
4
11:01so suddenly when list reaches 62 items it gets reduced to 2..
rebolek
11:03Interesting, but without seeing more of the code, it's hard to tell what is going on.
9214
11:04looks like some kind of overflow
maximvl
11:04yeah, I'm trying to make a small example
11:04because I have this in a hundred lines of other code
11:18it happens inside parse inside attempt, when I call length on a word! value
12:44the problem was in exception thrown with forall while iterating over a series which is a part of context
12:44so it left index at the element where error happened
12:45and then all other code was using same series
12:53https://github.com/red/red/issues/3170
9214
12:54@maximvl I think this behavior was discussed recently (with @endo64 I believe) and it's by design
maximvl
12:54I replaced forall with foreach in my code so it works now
12:54@9214 you have a link?
9214
12:57@maximvl gitter search is a mess, bu I'll try to dig up something
maximvl
12:57anyway
12:57I think a refinement can be a good thing to add
9214
12:57I agree with that
maximvl
12:58or at least a doc string that it modifies the index
9214
12:58https://gitter.im/red/red?at=57335717bce0284832d994ea
maximvl
13:01I see a question but don't see any replies
9214
13:01@maximvl look at the date :D
13:01it's not that recent
maximvl
13:02I just scroll down the chat
13:02but anyway, let's see what will happen in the ticket
16:29does somebody see inconsistency here?
>> #"a" = "a"
== false
>> 1.0 = 1
== true
9214
17:13I don't get why this doesn't work
>> insert body-of :?? [print "!!!"]
== [
    prin mold :value 
    prin ": " 
    print either value? :value [mold get/any :value] ["unset!"]
]
>> ?? a
a: unset!
>> ?? b
b: unset!
>> ?? ??
??: func [
    "Prints a word and the value it refers to (molded)" 
    'value [word! path!]
][print "!!!" 
    prin mold :value 
    prin ": " 
    print either value? :value [mold get/any :value] ["unset!"]
]

body of ?? is updated but it ignores inserted commands
maximvl
17:15my assumption is that a function object made from this body exists separately
9214
17:15but this trick works with user-defined functions as far as I checked
maximvl
17:16precompiled functions may behave differently
9214
17:17
text
>> append body-of :rejoin [print "all rejoined, yay!"]
== [
    if empty? block: reduce block [return block] 
    append either series? first block [copy first block] [...
>> rejoin [1 2 3]
== "1 2 3"
maximvl
17:19I have a super weird bug with blocks:
probe res
         probe next res
         probe type? res
         probe length? res
         res: next res
         probe res
         probe type? res
         forall res [

this code produces this result:
[kg]
none
block!
1
none
none!
*** Script Error: forall does not allow none! for its 'word argument
*** Where: forall
*** Stack:
17:19so next returns none instead of an empty block
17:19while it works if I just try it separately
9214
17:21@maximvl maybe you've redefined next somewhere?
maximvl
17:21lol, true
17:21@9214 thanks :D
9214
x8x
18:40Bug?
rebol:
replace t: %a.b find/last t %. %.c
;   %a.c

red:
replace t: %a.b find/last t %. %.c 
;   %a.c.b
rebolek
18:43I think you should report it.
x8x
18:44Will do, thx! :-)

greggirwin
06:33I commented on https://github.com/red/red/issues/3170.
06:35@maximvl, no inconsistency on char/string and float/integer comparisons either. So you'll like this:
>> #"a" = 97
== true
06:37:point_up: [December 27, 2017 10:17 AM](https://gitter.im/red/bugs?at=5a43d591ba39a53f1aaa434d) @9214 see: https://github.com/red/red/wiki/Guru-Meditations#compiled-versus-interpreted-behaviors
9214
07:15@greggirwin aha, that explains why reconstruction with body-of and spec-of works, thanks!
maximvl
14:13
>> "s" = "S"
== true
14:13@greggirwin is this intended as well?
rebolek
14:13Red is case insensitive by default
maximvl
14:13how do I fix it?
rebolek
14:14
>> "S" == "s"
== false

or strictly-equal?
maximvl
14:14thanks!
rebolek
14:14you're welcome
9214
14:14
text
>> ? ==
USAGE:
     value1 == value2

DESCRIPTION: 
     Returns TRUE if two values are equal, and also the same datatype. 
     == is an op! value.

ARGUMENTS:
     value1       [any-type!] 
     value2       [any-type!]
14:15no mention of case though
rebolek
14:15Probably to keep help string reasonably long.
maximvl
14:16
>> m: to-map [ "a" 1 ]
== #(
    "a" 1
)
>> select m "a"
== 1
>> select m "A"
== 1
14:16@greggirwin how do I apply this for hashes?
14:16select/case I see :)
rebolek
maximvl
14:34what about refinement on read/lines to correctly process newline escapes like this:
abc\
bca
14:34so it would read this as a single line
14:34abcbca ?
rebolek
14:35It's not native Red escape, unlike ^, so I doubt it would be accepted.
maximvl
14:36what about read/lines/escape %file #"\" ?
14:36so that you can specify the character
15:38ok, am I stupid again here?
>> 604800.0 / 86400.0
== 7.0
>> units/graph/week/base-unit-value / units/graph/day/base-unit-value
== 1.0
>> units/graph/week/base-unit-value
== 604800.0
>> units/graph/day/base-unit-value
== 86400.0
>> units/graph/week/base-unit-value / units/graph/day/base-unit-value
== 1.0
15:38why 1.0?
rebolek
15:40interesting, maybe a bug?
maximvl
15:40the base-unit-value is a function
15:40
base-unit-value: does [
      if base-unit [ select/case conversions base-unit ]
   ]
15:41this is a full definition with context:
unit: object [
   ; value: 1
   type: 'unit
   conversions: none
   base-unit: none
   init: does [
      conversions: make map! []
   ]
   base-unit-value: does [
      if base-unit [ select/case conversions base-unit ]
   ]
   can-convert: func [_to] [ find conversions _to ]
   convert: func [amount _to /local formula] [
      formula: select/case conversions _to
      if formula [
         run-formula formula amount
      ]
   ]
]
rebolek
15:47@maximvl I've tried this code:
units: context [
	graph: context [
		week: make unit [base-unit: "s" conversions: ["s" 604800.0]]
		day: make unit [base-unit: "s" conversions: ["s" 86400.0]]
	]
]

but then I get 7.0 when dividing
maximvl
15:48so I have this now
unit: object [
   type: 'unit
   conversions: none
   base-unit: none
   init: does [
      conversions: make map! []
   ]
   base-unit-value: does [
      probe select/case conversions base-unit
      if base-unit [ select/case conversions base-unit ]
   ]
]

>> units/graph/week/base-unit-value / units/graph/day/base-unit-value
604800.0
86400.0
== 1.0
15:49I really don't want to say this, but
15:49probably we have a bug
rebolek
15:50You can try do reduce [units/graph/week/base-unit-value '/ units/graph/day/base-unit-value]
maximvl
15:50@rebolek try this
15:51
>> week: make object! [
        type: 'unit
        conversions: #(
            s: 604800.0
        )
        base-unit: 's
        init: func [][
            conversions: make map! []
        ]
        base-unit-value: func [][
            probe select/case conversions base-unit 
            if base-unit [select/case conversions base-unit]
        ]
    ]
>> day: make object! [
        type: 'unit
        conversions: #(
            s: 86400.0
        )
        base-unit: 's
        init: func [][
            conversions: make map! []
        ]
        base-unit-value: func [][
            probe select/case conversions base-unit 
            if base-unit [select/case conversions base-unit]
        ]
    ]
>> week/base-unit-value / day/base-unit-value
604800.0
86400.0
== 1.0
>>
rebolek
15:52I get 7.0
15:52Let me try with different build.
maximvl
15:52
>> system/build/date
== 27-Dec-2017/13:48:35+01:00
rebolek
15:53I have older build.
15:53I suspect it is related to bug I reported recently.
maximvl
15:53this really worries me that we are getting such obscure bugs
15:54imagine self hosting with such bugs
rebolek
15:55See this bug https://github.com/red/red/issues/3156 there is also reference to commit that introduced this bug, you can try building older console to see if it's related.
16:01@maximvl There's a reason why Red is still in alpha.
maximvl
16:02@rebolek probably it's related:
>> units/convert2 1 'week 'day
604800.0

*** Runtime Error 1: access violation
*** at: 08074D8Fh
16:03this is when I rewrote to
a: from-unit/base-unit-value
b: to-unit/base-unit-value
(n * a) / b
16:04I added a comment in your ticket
16:07@rebolek do you know any workaround?
rebolek
16:09@maximvl I use older build. This is pretty serious bug and prevents lot of stuff.
maximvl
16:10yeah, I don't get what's the cause though
rebolek
16:13Looking at the commits it seems that Nenad changed some stack behaviour when fixing some reactive bug and this change introduced this regression.
maximvl
16:13ok, hopefully we will get a fix some day :D
rebolek
16:14Hopefully before Red/C3 ;)
maximvl
16:14meanwhile I made my stuff work:
>> units/convert2 1 'week 'day
== 7.0
>> units/convert2 1 'week 'hour
== 168.0
>> units/convert2 1 'uranusyear 'hour
== 736491.672036
>> units/convert2 1 'uranusyear 'day
== 30687.1530015
16:15will finish the library an a weekend
16:15Red is getting a universal converter
16:15(actually I just steal everything from units unix utility :))
16:19
>> units/convert 1 'earthmass 'moonmass
== 81.30058827479664
16:19nice
rebolek
16:23Nice!
16:23is there a way to get list of supported units?
maximvl
16:23there is :D
16:23
>> probe keys-of units/graph
[kg kilogram s second m meter A ampere amp cd candela mol mole K kelvin radian sr steradian US bit cm LENGTH AREA VOLUME MASS CURRENT AMOUNT ANGLE SOLID_ANGLE MONEY tonne t metricton quintal cc are a liter L l galvat angstrom xunit_cu xunit_mo angstromstar fermi barn shed svedberg spat sec minute min hour hr day d da week wk sennight fortnight blink ce watch bell decimalhour decimalminute decimalsecond beat circle degree deg arcdeg arcmin arcminute arcsec arcsecond rightangle quadrant quintant sextant sign turn revolution rev gon grade centesimalminute centesimalsecond milangle pointangle centrad sphere squaredegree squareminute squaresecond squarearcmin squarearcsec sphericalrightangle octant TEMPERATURE TEMPERATURE_DIFFERENCE degcelsius degC degfahrenheit degF degreesrankine degrankine degreerankine degR tempR temprankine degreaumur degK tempK atomicmassunit u amu amu_chem amu_phys dalton standardtemp stdtemp Rinfinity R_H bohrradius planckmass m_P deuteronchargeradius protonchargeradius electronmass m_e protonmass m_p neutronmass m_n muonmass m_mu deuteronmass m_d alphaparticlemass m_alpha taumass m_tau tritonmass m_t helionmass m_h kayser balmer abampere abamp aA biot Bi intampere intamp LUMINOUS_INTENSITY candle hefnerunit hefnercandle violle TIME anomalisticyear siderealyear tropicalyear eclipseyear siderealday siderealhour siderealminute siderealsecond anomalisticmonth nodicalmonth draconicmonth draconiticmonth siderealmonth year yr month mo lustrum decade century millennium millennia solaryear calendaryear commonyear leapyear julianyear gregorianyear islamicyear islamicleapyear islamicmonth mercuryday venusday earthday marsday jupiterday saturnday uranusday neptuneday plutoday mercuryyear venusyear earthyear marsyear jupiteryear saturnyear uranusyear neptuneyear plutoyear earthradius_equatorial sunradius astronomicalunit au solarmass sunmass sundist moondist sundist_near sundist_far mercurymass venusmass earthmoonmass marsmass jupitermass saturnmass uranusmass neptunemass plutomass earthmass moonmass oldmercurymass oldvenusmass oldmarsmass oldjupitermass oldsaturnmass olduranusmass oldneptunemass oldplutomass atomicmass atomiclength thermalvolt inch in foot feet ft yard yd mile line rod perch furlong statutemile league chain link ch intacre acre section township homestead engineerschain engineerslink ramsdenschain ramsdenslink gurleychain gurleylink wingchain winglink internationalyard fathom nauticalmile cable intcable cablelength marineleague pound lb grain ounce oz dram dr ushundredweight shorthundredweight shortton shortquarterweight shortquarter troypound troyounce ozt pennyweight dwt fineounce silversmithpoint appound apounce apdram apscruple usgallon usquart uspint usgill usfluidounce usfloz liquidbarrel beerkeg ponykeg winekeg petroleumbarrel barrel bbl ushogshead usfirkin usbushel uspeck drygallon dryquart drypint drybarrel cranberrybarrel heapedbushel wheatbushel soybeanbushel cornbushel ryebushel barleybushel oatbushel ricebushel canada_oatbushel ponyvolume jigger shot fifth wineglass magnum metricquart jeroboam rehoboam methuselah salmanazar balthazar nebuchadnezzar shoeiron shoeounce shoesize_delta shoe_men0 shoe_women0 shoe_boys0 shoe_girls0 europeshoesize buck fin sawbuck usgrand greenback key lid usfootballfield canadafootballfield brnauticalmile brcable admiraltymile admiraltycable seamile shackle clove stone tod brhundredweight longhundredweight longton brton brgallon brbarrel brbushel brheapedbushel brquarter brchaldron bag bucket last pottle pin puncheon seam coomb boll firlot brfirkin cran brwinehogshead brhogshead brbeerhogshead brbeerbutt registerton shippington brshippington freightton displacementton waterton strike amber imperialgallon imperialbarrel imperialbushel imperialheapedbushel imperialquarter imperialchaldron imperialwinehogshead imperialhogshead imperialbeerhogshead imperialbeerbutt imperialfirkin hide virgate nook englishcarat mancus mast nailkeg basebox metre litre geometricpace pace USmilitarypace USdoubletimepace fingerbreadth fingerleng
rebolek
16:24That's a long list :)
maximvl
16:24yeah, well, many of them are synonyms
rebolek
16:24can I convert ampers to I don't know, seconds? ;)
maximvl
16:25
>> units/convert 10 'ampere 's
*** Throw Error: no catch for throw: cant-convert
*** Where: throw
*** Stack:
16:26there is still a bunch of those which are quite hard to parse and handle
16:26(at least for me)
16:27for example
thermalhenry            J K^2/W^2  # thermal inductance
osi                     ounce force / inch^2   # used in aviation
europeanUvalue          watt / m^2 K
greggirwin
19:42@maximvl, the units stuff is very cool. I want an homage to Frink in Red. Also, I commented on your comment on the bug ticket.
x8x
22:05shouldn't these both return same result:
>> change "test" ""
== "test"
>> change/part "test" "" 1
== "est"
rebolek
22:09No, change gets length from value. In first case, that length is zero.
>> head change "test" ""
== "test"
>> head change "test" "_"
== "_est"
>> head change "test" "__"
== "__st"
>> head change "test" "___"
== "___t"
x8x
23:07@rebolek I guess you mean that without /part refinement, /part is equal to the length of the value so that:
change "test" ""

correspond to:
change/part "test" "" 0

I think I got mislead by or position in the description:
/part => Limits the amount to change to a given length or position
rebolek
23:28>> I guess you mean that without /part refinement, /part is equal to the length of the value

Exactly. Sorry for not being clear.

x8x
00:30@rebolek Very Thanks! :-)
toomasv
04:21@x8x The position part accounts for this:
>> change/part t: "test" "b" at t 2 t
== "best"
>> change/part t: "test" "b" at t 4 t
== "bt"
rebolek
15:27Issues can't be keys in maps? This is outrageous!
meijeru
17:28Neither can refinements; these two "word-like" value type are treated differently from the rest.
rebolek
18:07Interesting. I don't see why. issue! especially is such a great key.

greggirwin
02:37I imagine it's because of the path syntax for accessing them being a problem. Think of them more like objects than blocks?
02:38Also, if they are converted to plain words, you lose information.