Python 2.7.x has *much* better cross-compiling support so that it's now
actually possible to properly cross-compile Python during the bootstrap.
Before, it would just depend a lot on luck and the build host used, now
it even cross-compiles on OS X.
This means it's now possible to build a working bootstrap image on OS X!
:)
- Allows one to choose the type which the current expression
should be evaluated as.
- Don't attempt to evaluate expression if the input field is
currently empty.
- Remove dependency on MAPM/ExpressionParser. Consequently also adjust
CliDumpMemoryCommand, InspectorWindow and WatchPromptWindow to use
CLanguageExpressionEvaluator for address input evaluation.
CLanguageExpressionEvaluator:
- Revise to make use of Number class rather than MAPM. In the process,
implement support for bitwise operators.
SourceLanguage/CLanguageFamily/CLanguageExpressionEvaluator:
- Adjust interface for expression evaluation to allow specifying the
type to evaluate the expression as. Adjust implementing classes
accordingly.
ExpressionEvaluationWindow:
- Adjust to new expression interface. For now defaults to 64-bit integer
type, UI for type selection to be added.
- This class abstracts out the underlying type of a value, and handles
all the basic mathematical logical operators accordingly. Replaces
the MAPM type previously used for these respective operations.
The language and formatting conventions can now only be set when
creating the objects. This removed the needs for locking them when
formatting to avoid some other thread changing the format while it's
being used.
Adjust tests and DeskBar TimeView to the API changes.
- CLanguageExpressionEvaluator now handles all the basic logical
comparison operators. Bitwise operators still to come, as some
of those may possibly require modifications to the MAPM library.
- Separate operator parsing out into its own function, and refactor
it to handle multi-character operators. These aren't yet handled
by the parser itself though.
- Using BMessenger as an indirect lock is unnecessary, as
BLooper::Lock() checks if the current looper is valid via the global
looper list directly.
- Fix race conditions. When asked to show various subwindows, lock them
before calling Activate(), as the window could otherwise potentially
quit in between us checking pointer validity and calling Activate().
- _GetActiveSourceLanguage() needs to acquire a reference to the language
object in the case where it's retrieved from the active source code.
Otherwise, an unbalanced release would take place when creating the
expression window, leading to crashes.
Thanks to Stephan for reviewing.
Although done with the best intentions, the usage of #warning in the
ARM build makes it hard to see what's going on, or see any "real"
warnings.
Remove at least this particularly often triggered one, so we can
have a relatively "quiet" build again...
Not yet visible. But the package list area in the main window has a card
layout now and a second (hidden) page for featured packages. Which packages
are visible there will depend on the prominence value from the web-app
and other parameters later (suggestions based on packages already installed
and user-ratings). At the moment, there is no mechanism for updating the
package list when package info is retrieved asynchronously, even from the
cache. Also, the view should switch to the list when searching and perhaps
in other situations as well, like selecting a category or when no packages
would be featured. And clicking featured packages does not yet select them in
the info area...
Currently a vertically scrollable container for views which are similar
to the title area in the package info view (and share most code, but it
will diverge later on). Untested and not yet used.
Package contents are scanned to find deskbar links. If a package has less
than four links, they will be offered in separate "Open <link name>" buttons
in the package info area. Usually, this results in one button to open the
main application from the package. If the heuristic proves to be not good
enough, this could be improved of course.
The "2nd" assert that we always ran into was due to bootloader mappings
still being active after VM init. Turns out we missed a call in the
architecture specific code for cleaning this up.
Many thanks to Ingo for spending the time to figure this out!
- Adjust expression window interface so it can report being closed
to TeamWindow or whoever else invokes it.
- Add a menu item to Tools to request expression evaluation. This
now attempts to get the expression evaluator for the current language,
and subsequently opens the expression evaluation window with it.
With these changes, basic numerical expression evaluation works.
Resolution of variable values and condition operators aren't yet
handled.
- Add override for EvaluateExpression(), and hook it up to
CLanguageExpressionEvaluator. Note that for the moment it assumes
the expression will result in an integer value.
