ledasfen.blogg.se - Speedcrunch rpn

#SPEEDCRUNCH RPN 1080P#
#SPEEDCRUNCH RPN UPDATE#
#SPEEDCRUNCH RPN CODE#

When you don't need it anymore simply one more click to bring the window behind it in front, or click the taskbar icon once again to minimize the calculator. To be able to type into its window you need to click it in order to make give that window focus, but in Win7 you can click a pinned icon of SpeedCalc, this will launch it if not running or bring it to foreground if it is running, ending up with that window in focus so you can start typing. Something like SpeedCalc wouldn't be always open in a dedicated area of the screen for me, there is no significant benefit to that. I usualy have one maximized window of my main task on the main monitor and all the other things like documentation on the side. I find it being enough space for me, occasionally a third monitor might come handy, but Win7 being able to tile a window across half of a screen with the Win+Arrow shortcut makes it easier to multipurpose one screen.

#SPEEDCRUNCH RPN 1080P#

Oh, and looks like we'll jump to the 1.I have been using two 1080p monitors for a really long time now (Both home and at work). Also, I'm actually not so sure recursive functions will be really useful anyway: the only use case I can think of is sequences, but a spreadsheet application is more suited for that as users generally need to see the values of multiple elements rather than a single sequence element.

#SPEEDCRUNCH RPN CODE#

The code could be more generic so I won't publish it yet. Using a syntax tree would be better of course. Also, the unit string better matches what the user gives with this branch.Ĭoncerning branched flows and recursive functions, I managed to implement it using conditional jumps in the opcode stack (the same way it is implemented in programming language compilers), which didn't require so much work actually. So far, the only difference with current implementation is that the result of 1 meter -> 10 meter is 0.1 10 meter instead of 0.1 (10 meter) (using 0.1 10 meter in an expression will be evaluated as 0.110 meter because of digits groups separators detection). This removes the need to do extra parsing for the conversion operator at the end of the lexer. The parser_pr branch contains an implementation of Hadrien suggestion to carry information about the original text in each token. We concluded that RPN was not coming to SC anyway, so the latter might be a workable solution. It is on this matter that I mentioned that RPN would still not work.

Hadrien suggested that a (reduced) token should carry along original tokens it is made of.

A tree contains all the information about the original input. This represents quite a task, but will (probably?) solve the issues above.

I suggested rewriting the parser so that it generates a parse tree rather than opcodes.

(I had to hackishly include some strings into opcodes to make unit conversion work at all.) The opcodes do not carry any information about the string anymore, so they are useless in that regard. However, currently the compiler just produces opcodes (which are essentially RPN). This can only be done after the compiler has done its job. RPN for instance will totally wreck it as well.Ī more reliable way would actually consult the semantics of the expression. new operators) that will break this scheme. Also I can imagine additions to the grammar (e.g. Currently we only rely on the tokenized input, which is unsatisfactory, as it traverses the tokens twice (once for finding the string, and then once more when actually evaluating the expression), and applies precedence rules each time. For instance in (a+b -> c*d) * e we'd want to get c*d. This is useful for the conversion operation, as here we need to extract the right hand side of the -> operator. In particular the parser should also be able to produce a string (substring of the user input) that corresponds to the subexpression that is currently being evaluated. Such a tree based parser would also enable branched flows (think of the ternary operator ? : in C++), recursive user functions, pretty printing. This way, when a conversion operation is evaluated, the corresponding sub-tree would contain all the information of the unit, including the necessary string (either stored from the scanning step, or constructed on the fly from the nodes). For the evaluation we would just call an eval method of the root node, it would then recursively evaluate its children.

It would be very nice if the compiler would instead generate a parse tree (either abstract or concrete). Think autocompleter, or the unit parsing you mention. There are quite a few places that would benefit from being able to query the semantics of the expression. The parser could indeed do with some improvements just compiling the tokens into opcode is fairly limited.

#SPEEDCRUNCH RPN UPDATE#

While the units update was still in the works, we had a discussion on this over on Hadrien's repo.