red/red

Red Programming Language main room

Maciej Łoziński

@loziniak

@9214 great info, thanks! Apparently not a new case.

JacobGood1

@JacobGood1

Debugging experiences to emulate: https://malisper.me/category/debugging-common-lisp/
and from Pharo: https://twitter.com/Richo1066/status/1131788453451096068

I have probably linked these before, but I am just refreshing everyone's memory in case these examples, the ones from Pharo and Common Lisp, are forgotten.

lucindamichele

@lucindamichele

Thank you, @JacobGood1!

dsunanda

@dsunanda

@9214

I appreciate that error reporting is not trivial, but what we have at the moment is not fit for purpose. It may be more-or-less adequate when debugging the latest dozen lines of code writte while developing (9/10 times the problem is in those lines). But it seems to fundamentally put a limit on the size of Red systems - and/or the ability to easily integrate two separate code bases.

User example - a couple of weeks ago, I experimentally tried to convert a Rebol/Core system (60 scripts, 25,000 lines of code) to Red. I did not expect it to be easy or fun. But I was not expecting to be so misled by errors messages.

Take this one - it took a couple of hours of my life to resolve:

 type: 'script  id: 'invalid-type  arg1: word!  near: none  where: 'set-path

There is not a single instance of SET-PATH in the 60 scripts / 25,000 lines of code. So basically, not a single clue in the message where to start looking.

(If you are interested, the bug fix was to make the 'word in a FOREACH local to its function). I got a log of around 20 other errors which might as well have just said "Shrug. Magic bad".

So attacking the non-trivial problem with some priority could well be a unique selling point for Red.

Vladimir Vasilyev

@9214

There is not a single instance of SET-PATH

Error doesn't tell you that there's a problem with set-path! value, it prints out stack trace, in which set-path was the last called action. Not very informative, true, but hardly misleading.

dirtbagger

@dirtbagger

I am not a programmer, but from time to time I have a data-manipulation problem that I can't handle using off-the-shelf software. In cases like that I write the program I need. For the latest such project I set out wanting to try to write the program in Red, but when I found that I would have to learn using the Rebol documentation I decided to write in Rebol, with the aim of eventually converting to Red.

dirtbagger

@dirtbagger

Hmm, just learned not to hit return if I'm not finished a message. I'm new to this sort of message board. Anyway, to carry on, I now have a working program in Rebol. I started looking at what I'd have to do to convert it to Red. One problem I've found is that in Rebol I made extensive use of ports for file I/O. In other words, I used "open" and "close" a lot. These instructions don't seem to exist in Red. Am I missing something. Does Red not have a facility like ports for file I/O?

GiuseppeChillemi

@GiuseppeChillemi

@dirtbagger ports are being implemented, soon you will see them. Be patient, they are doing lot of work behind the scenes.

Vladimir Vasilyev

@9214

@dirtbagger ports are scheduled for 0.7.0 release. In the meantime, depending on your actual task, you can substitute them with read.

dsunanda

@dsunanda

@9214 Thanks. Actually, completely uniformative, as the last action called is irrelevant to the failure....If a SET-PATH was called, it was not (directly) from the user-level code. It might have well have said "Failure in something defined somewhere in SYSTEM. You're on your own". Red can do better than that - Rebol does (somewhat).

packetrhino

@packetrhino

@greggirwin there are many ports of "expect" like behavior to examine, such as Perl's Expect.pm , Python's pexpect or pyexpect, even Windows PowerShell has an "expect" like package.

Rudolf Meijer

@meijeru

@x8x basically it is all of the branches of the red/red repository that have new commits - you have shown thenegative-zero and the GTK branch last week, but this week there is activity in refactor-lexer and it does not show up. The links are like https://github.com/red/red/tree/refactor-lexer and similar for all branches.

FLuX

@x8x

@meijeru Thank you! I'll have a look and let you know.

FLuX

@x8x

@meijeru Should be fine now, please let me know if you spot issues again!

Rudolf Meijer

@meijeru

@x8x :+1:

Rudolf Meijer

@meijeru

I have just published a small program to check if you have the latest Red version. It is in my Gist

I have a suggestion: incorporate this in the current GUI console as a second option in the Help menu (after About).

Maciej Łoziński

@loziniak

User would probably never see "you are up-to-date" message with current speed of generating commits by the team! :-)

Rudolf Meijer

@meijeru

BTW in the red/gui-branch room I show how I added this facility myself to the console, by modifying the menu and the on-menu actor.

lucindamichele

@lucindamichele

I have just published a small program to check if you have the latest Red version. It is in my Gist
Very cool @meijeru !

Gregg Irwin

@greggirwin

@packetrhino thanks!

dirtbagger

@dirtbagger

Thanks to @GiuseppeChillemi and @9214 for the responses to my question about ports. On a more general question, does anyone have advice to offer on converting Rebol code to Red? My perhaps rather naive approach would be to just try running the Rebol code from the Red console and see what doesn't work. If there's a more efficient or systematic approach to use I'd be pleased to learn of it.

Vladimir Vasilyev

@9214

@dirtbagger Rebol2 and Red are highly compatible, I suggest to gradually copypaste Rebol bits, bottom-up, and check if they work as expected. In case something breaks - the best way to figure out what went wrong is to ask for help in our chat room.

Dave Andersen

@dander

@dirtbagger It would probably be helpful to look over this reference for differences before you start. And would be very helpful if you record any new things you find there as well!

Gregg Irwin

@greggirwin

Thanks @dander, yes, more info is always good.

Gregg Irwin

@greggirwin

@JacobGood1, thanks for those links. We have various elements of debugging to address: language (errors), instrumentation/tracing (runtime), and environment (tooling). @maximvl did some CL-like experiments, which were pretty cool, showing how Red can be adapted at the user level for some things. Tooling is probably the easiest thing to address, because we can build them as needs arise, and use the future plugin system in the console and full IDEs. e.g. a 5-minute object inspector:

debug-obj: function ['obj [word!] "Ref to object"][
    o: get obj
    spec: copy [across]
    repend spec ['h3 rejoin ["Editing: " obj] 'return]
    foreach word words-of o [
        repend spec [
            'text form word
            to set-word! rejoin ['f- word] 'field 'data o/:word compose [
                (to set-path! reduce [obj word]) face/data
                probe o
            ]
            'return
        ]
    ]
    probe spec
    view spec
]
o: object [x: y: 0]
debug-obj o
o2: object [x: y: z: 1]
debug-obj o2

Instrumentation is an interesting area I'm keen on (think DTrace), and Red's dynamism is great and terrible for some of these issues. e.g., it's not just a compiler optimization switch we can flip. We also constantly push and pull, on the design side, about what needs to be in R/S for performance, and what can be built at the user/mezz level. Also figuring out what hooks are necessary in order to facilitate probing and AOC type features, without going full MOP on people. I'm not saying MOP is bad, not at all, just that it's not part of Red's design today.

It all raises questions about debugging in general, and that one size does not fit all. Sometimes you're debugging a function, working in the REPL, sometimes an application, other times a complete system.

JacobGood1

@JacobGood1

You should always be working in a repl =P

luce80

@luce80

@JacobGood1 So much true...I hope to see an editor that let's you debug a selection of code and/or that let's you isolate all but a new function (or even a line) you are creating, and let's you debug only that. Or does it exist already?
P.S. have you seen this ;) ?

Rudolf Meijer

@meijeru

@greggirwin debug-obj is a nice quickie, but when I called it with an expression evaluating to an object, rather than with a word referring to an object (which admittedly I should not have done), it showed a confusing error message. I will report on this in red/bugs.

Jose Luis

@planetsizecpu

Why not a switch? I used a very effective debugger for many years, you selected the point where you wanted to start
debugging with the debug-on keyword and the point where you should end the debugger withdebug-off.
Then you compiled the program in debug mode, so when it was executed it worked normally, and, when program arrived at
the debug point, a window opened where you could see the source code and the debuger awaited confirmation to execute
each instruction, step by step, also check the status of the variables or continue the normal process by closing the
debuger. I saved many hours looking for hidden faults, but it is just a idea.

Vladimir Vasilyev

@9214

selected the point where you wanted to start debugging

I hope you realize that in Red this "point" cannot even exist in a textual program at the time of debugging (e.g. code generation). Traditional breakpoints are extremely limited, and cover only a naive, static subset of the language.

Jose Luis

@planetsizecpu

I know, and there maybe also events code running ... bigger challenge, just a idea, as I said.

Vladimir Vasilyev

@9214

Not to mention dialects, for which debugging and error messages should be, ideally, domain-specific. Which means that Red should provide some "debugging framework" to build on top of.

JLCyclo

@JLCyclo

@luce80 For debugging a script step by step, try https://github.com/red/community/blob/master/tools/rdbstep.red

I will update this script to manage breakpoints in a way not to simulate automatic step commands until a breakpoint.

Gregg Irwin

@greggirwin

@meijeru, yes, lit-word args deserve a good article written about them, their exceptional flexibility, and the pitfalls that come with it.

@JLCyclo thanks for the reminder about that. I get an error just putting it in the console. Need to read up.

Type help or h or ? for help at the prompt (rdbstep)
*** Script Error: stepnext does not allow string! for its redsrc argument
*** Where: stepnext
*** Stack:

Will try to make time to check it out in the near future.

JLCyclo

@JLCyclo

In the header of rdbstep.red, there is some help

Usage: "From REPL : do/args %rdbstep.red <Red Script>"

How do you run the script rdb.red ?

Gregg Irwin

@greggirwin

I copied the source to the clipboard and did do read-clipboard in the console. Standard practice for me, when playing around. Will download and run standalone in the future.

Gregg Irwin

@greggirwin

@packetrhino if you'd like to be in the loop on any Expect related chat, let me know. I've done some reading today, and remembered a couple related projects I've done. One is send-keys, which is a Windows-only GUI lib for keystroke pumping. Another was an old Install Helper app that launched apps, watched for dialogs and interacted with them, etc.

packetrhino

@packetrhino

@greggirwin yes please do keep me in the loop

JacobGood1

@JacobGood1

@9214 and an easily extensible ide for those dialects

Rudolf Meijer

@meijeru

I have downloaded the latest red.exe for Windows (22-Sep-2019, sha: 7daa2dd5) and compiled the console (yielding gui-console-2019-9-22-34786.exe) but, strangely, when I ask for about, it gives me Red 0.6.4 for Windows built 20-Sep-2019/18:03:51+02:00 commit #04daa5e, which is a much older version. What am I doing wrong? Also, I can't see a commit with sha: 7daa2dd5 anywhere.

So far, one explanation seems to be that red-latest-exe has not been updated.

Gregg Irwin

@greggirwin

What OS? I don't see a 7daa2dd5 for any of the SHAs on the download page.

04daa5e is from 20-sep.

Where communities thrive

People

Repo info

Activity