Feedback wanted: conditional GCode without indentation
-
@fcwilt said in Feedback wanted: conditional GCode without indentation:
'}' symbols are evil incarnate.
The Duet's firmware is full of them, don't bring it into your home.
https://github.com/Duet3D/RepRapFirmware/blob/dev/src/Movement/DriveMovement.cpp
-
end
is fine- I would pick just 1 way to do it, even if that way breaks existing code. Now is the time to make breaking changes. I don't want to imagine a) what tricky things users will think up to fool themselves b) what implementation bugs will arise due to the complexity of having 2 ways to do it.
- As a software engineer, this question makes my skin crawl. I really wouldn't do anything for whole files, just blocks. But if you really want to mix both styles, I would do this: require unintended blocks to have a
begin
andend
keywords, on their own lines, to delimit the block. That waybegin
/end
can be used with all of the existing block types without renaming them (the names are perfectly good as-is).
if foo == bar begin ; begin unruly slicer generated gcode G10 G1 X50 Y50 F5000 ; and so on ... end
This is basically a friendlier versions of parens
{<block>}
. You could also postfix theif
statement with python's:
to indicate an unintended block start but this is so subtle and easy to miss that I think it is visiting an evil on the intended audience.Visual Basic has "OrElse" and "AndAlso", because they refused to re-define the meaning of "or" and "and". Don't be Visual Basic.
-
@zapta said in Feedback wanted: conditional GCode without indentation:
The Duet's firmware is full of them, don't bring it into your home.
That's why I perform a ritual "cleansing" of the boards before I use them in a printer.
Better safe than sorry.
Frederick
-
@theruttmeister said in Feedback wanted: conditional GCode without indentation:
That could be simplified down to a gcode command that executed a specific .gcode file multiple times:
Mxxx thisprintjob.gcode S10That would still require editing the slicer generated file to separate out the pre-print/post-print code from the main body of the code.
With a While and End you add two lines to the file and your done.
Frederick
-
Should the keywork be 'end', or something else?
I think I would useif condition then if given condition true execute all commands up to else statement or to fi if there is no else statement else if given condition false execute all commands up to fi fi
and
while condition do command1 command2 command3 done
Should it be permitted to mix keywork-delimiting and indentation-delimiting in the same file? If so, what problems might arise, and what restrictions should be enforced?
IMO indentations should be allowed just to keep it more readable, but ignored in processing code
How should the user indicate to the firmware that a loop or conditional is to be delimited by a keyword instead of by indentation? One option is to have a new command keyword (e.g. 'noblockindent') that means that for the remainder of the file, keywork-delimiting will be used. Using that keyword when already inside a block would probably have to be banned. Another option is to use different variations of 'if' and 'while' (e.g. a different keyword or some extra character) to indicate keywork delimiting for that command.
I would drop indentations for indicating clode blocks
-
-
The coding language that I use most of the time (Livecode) uses "end repeat" to end a repeat loop, "end if" to end a conditional et cetera. It is very nice in that it does not depend on indents and it is entirely unambiguous. I commend it as a model to follow.
-
No. Do not allow mixtures. They will be confusing.
-
Ideally you would make the delimiting by keyword and do not support indentation. However, I'm guessing that indentation is already in use, and in that case your idea of something like 'noblockindent' would work rather like M82 and M83 (absolute and relative extruder). Perhaps it should have two keywords 'blockindent' and 'blockwords'.
-
-
@fcwilt +1 from me but at the moment {} brackets are used for putting variables from object model into gcode commands.
Anyway i think that more similiar the conditional code is to c++ and less to python is for me a big yes....i have no problem with this type of language but i hate having indentation to determine the loop/function start/end.
I would give a function its proper "ender" so for example "loop" for while loop and so on.
-
Having come from a Delphi programming background (based on pascal) I'd be inclined to lean towards a similar syntax
Pascal was designed to be easy to read/teach.
Blocks are typically surrounded by begin/end and use the keyword "do"
Indentation is not required but usually used for clarity.while iterations < 10 do begin // do stuff end
For if statements
if move.axes[0].homed do begin echo "axis homed" end else begin echo "axis is not homed" end
line ends are usually terminated with a semi colon ; except in nested begin/end blocks as if if else (the outer block must have a ; and the inner must not) but I don't think that is necessary here.
Likewise the do keyword is purely for human readability.I would not allow mixing of indentation and whatever block format is chosen.
-
I don't see the need for a begin keyword. If is the keyword that starts the block.
Perhaps if a keyword is required at the beginning, we could borrow some LUA parlance and use
THEN
, so that the parser knows when the conditional is over. -
Iām going to break with the group. I like the Python style of programming and keeping the indentations. Python is widely used and when writing code on the SBC, most likely a raspberry pi, Python is the natural choice.
-
@dbruce-ae05 said in Feedback wanted: conditional GCode without indentation:
Iām going to break with the group. I like the Python style of programming and keeping the indentations. Python is widely used and when writing code on the SBC, most likely a raspberry pi, Python is the natural choice.
You're forgiven your errant ways.
Frederick
-
@bot said in Feedback wanted: conditional GCode without indentation:
I don't see the need for a begin keyword. If is the keyword that starts the block.
Perhaps if a keyword is required at the beginning, we could borrow some LUA parlance and use
THEN
, so that the parser knows when the conditional is over.Well in Delphi if you only have one statement after the condition you don't need the begin/end pair. You use them when you have more than one statement.
I always thought that NOT always requiring begin/end even for one statement was a mistake.
Frederick
-
-
@DaveA As a C & C++ programmer from around 1976 I'd love to see the Kernighan and Ritchie style with { } syntax. I hate Python indention style.
Just my opinion since you asked.What? But python style works great in editors like EMACS! Fancy IDE's highlighting { } groupings is for schmucks right?
-
My opinion: use a keyword to end blocks (
end
is fine for me, but honestly I don't care).Do not allow mixing styles, use block end keywords exclusively (but allow indentation for style purposes).
-
@wilriker said in Feedback wanted: conditional GCode without indentation:
My opinion: use a keyword to end blocks (
end
is fine for me, but honestly I don't care).So you would be ok with "ruvineckerned" or "footguratunnie"?
Just checking to be sure.
Frederick
-
@wilriker +1
The target audience for this language is not skilled programmers. Its designers & makers that are trying to solve some problem with their printer. There is going to be a LOT of copy/paste code that mixes indentation types (tabs, spaces, number of spaces). Begin/end constructs survive this kind of abuse better than Python style strict indentation. Having just 1-way-to-do-it makes its safer/easier for newbies copying code.
The few of us that are writing most of the code can use whatever construct you come up with.
-
I think php might be a good example here as it allows two types of syntax.
For pure php
<?php if ($a > $b) { // do somehting } else { // do somehting else } ?>
For php mixed with large chunks of something else like html, JS etc.
<?php if ($a > $b) : ?> // do somehting <?php else: ?> // do somehting else <?php endif; ?>
All standard control structures have the second alternative syntax.
The parser knows php is only contained between the opening and closing tags
<?php // some code here ?>
The alternate control structures lets the parser know that logic spans multiple sets of opening and closing tags.
Each control structure has it's own unique opening and closing tags.
here is a quick little tutorial with examples.
https://riptutorial.com/php/topic/1199/alternative-syntax-for-control-structures -
One thought I guess as is how any start/end construct might be interpreted by common slicers if used in start gcode etc
Prusa slicer uses if-endif so is definitely going to try to post process that. Whether it causes any issues probably depends on how PS handles things it doesn't understand -
I agree that styles shouldn't be mixed and that RRF should either support one thing or another (and not both.) However, RRF 3 is a released product, so any change could be breaking a LOT of code, macros, etc.
Even the initial "conditional gcode" stuff in RRF3 was done in such a way to not break any existing gcode.
For that reason, I still think there are ways to solve the actual problem without breaking changes to the language. One idea I proposed above, though I don't know if that would actually work. Immediately after, someone else proposed something else that wouldn't break any existing gcode.
Breaking an existing programming language for single special cases isn't a good practice. Even large functional changes should be careful to not break existing code. I still have old K&R style C code that still compiles with a modern C/C++ compiler!