I have a problem to detect global variables with scilab. In the parameters, by default "ExternalVariables" should be shown in red. However, variables defined in the function and outside both show in black and not in red... do you have an idea to solve this problem?
In Scilab, a variable can be inherited by all children functions (without being the argument list) and is unknown by all parent functions. This is always true. It's value will not change after leaving the children function (even if it's value can change inside), except if it's an output argument.
The syntax highlighting seems (by experience) to rely heavily of the state of the workspace at the moment you called Scinotes:
A variable will appear read if
it's in your workspace
and a variable with the same name exist in a file
and if you open that file in SciNotes
Let's take an example:
Lets open Scilab and create a simple function with a variable that is defined in its scope
We see that it's not in red meaning that scinote is not aware of its global scope.
Let's close the editor, declare y in the console and open it again, but with the graphical button
Nothing as changed, because I think SciNotes is only aware of the state of the workspace at the moment it was called.
But if you open it with edit or if we close Scinotes (every tab) and open it again, then y will be in red !
I think edit may update the SciNotes knowledge of the workspace, whereas the button only display the file. Dunno why.
Related
I am utilizing Pick Basic on the uniVerse operating system. Many times, I will need to watch a variable change during a debugging session. I will locate the variable throughout the program and note every time it can possibly be modified. I will then go into the program and during its execution, I have the program display the value of the variable on the screen along with the line number of the source code. For argument's sake, let us say that the variable name is begdate and in this case, on line 146, I set it to today's date. I will add the proceeding line:
146: begdate = DATE()
147: DISPLAY "Line 147: ":OCONV(begdate,"D4-")
This works just fine. But, if the program can possibly change this variable on many different lines, once I start adding or subtracting lines to the source code, the display is usually not displaying the correct line number anymore because the line number is hardcoded.
Does Pick Basic have any system variable that captures the line number of the source code so that:
I do not have to keep going back and changing the hardcoded line number and better yet,
I do not have to hardcode the line number at all.
Welcome to StackOverflow! The answer to this is in the UniVerse BASIC User Guide V11.3.4:
https://docs.rocketsoftware.com/bundle/UniVerse_BASICUserGuide_V1134/resource/UniVerse_BASICUserGuide_V1134.pdf
Ref page 63 on Debugging Tools (RAID) and the M command to set watchpoints on variables.
A watchpoint condition occurs when RAID monitors a variable until the variable’s value changes. The
program then suspends operation and displays the variable’s old value, its new value, and the source
instruction that caused the change to occur
The command is entered at the :: prompt, within the debugger. You can enter the debugger with a DEBUG statement in your code or by breaking into it at runtime. You can also use the command RAID BP ProgName.
Another way to go about this is to compile with -X option so that you can get see where variables are referenced. See page 35 from above.
When I debug like this in BASIC, I tend to use names, not line numbers, to indicate what the code is doing, not where it is. So the code would look more like this:
147: DISPLAY "Initializing Beginning Date: ":OCONV(begdate,"D4-")
Now the line can move and you'll still be able to find it easily with the unique text. You can also use simpler unique text like this:
147: DISPLAY "BEGDATE_INIT: ":OCONV(begdate,"D4-")
Use whatever pattern seems comfortable.
Be sure begdate isn't EQUated to a dynamic element or some other variable. If, for example, EVENT<3> is equated to begdate the debugger tracing the specific variable name might not pick up on EVENT<3> or EVENT<Beginning_Date> being modified.
I am not aware of a specific #VAR or other runtime mechanism in UniVerse that will return the currently executing line number back to the BASIC code so that you can DISPLAY "Current line is ":#LINE.
In D3 I peeked into the local workspace and the current stack trace.
Someone with more current UniVerse expertise might be able to cite a specific function, #VAR, user exit, or other mechanism for this. It's possible that the feature you're looking for is only available in a later platform.
Rocket Support will help with this question : Support Agreement should not be necessary to ask a simple question like this. If that's not an option, check the forum on the Rocket site, or one of the community forums. I can provide links if required.
I'm struggling to find out how to create a new syntax highlighting in Sublime Text 3 using the new .sublime-syntax style definition (most previous answers relate to old ways of doing it).
As of Sublime Text Build 3084, a new syntax definition format has been added, with the .sublime-syntax extension.
I can find the:
syntax rules
scope naming rules
colour scheme rules
But I can't find the most basic piece of information detailing how these tie together!
I'm not trying to create a theme, or tweaking an existing syntax definition. I just want to create syntax highlighting to files with an extension I plan on using for my own purposes.
In the syntax definition I have to specify a scope (e.g. scope: source.c) but where does that scope file live? Or rather, where do I create my scope file, and how do I name it, so that it loads?
How do I know that my syntax file, and the scope file it uses, are loaded and applied successfully?
Are there any compile or refresh steps, or does everything automatically reload?
Thanks.
A full discussion of how to create a custom syntax is well outside the bounds of something as simple as a Stack Overflow answer. Also I think you're making your problem more complicated than it actually is (although creating a syntax is pretty complicated in general).
In order to walk you through the steps that you would take to create a custom syntax, here's an example.
To start with, create a file with the following contents and save it somewhere as sample.ec, and leave the file open:
// This is a line comment
if (x == 2)
y = 1
else
z = 1
You'll notice that the syntax for this file is set to Plain Text (see the status line in the lower right), which is the default syntax for files that are unknown to Sublime.
Now, select Tools > Developer > New Syntax... from the menu. A buffer with the following will appear. Use File > Save to save the file; the location will default to your User package. The name you give it is not important, but make sure that the extension is sublime-syntax. In my example I'm calling my file Sample.sublime-syntax.
%YAML 1.2
---
# See http://www.sublimetext.com/docs/3/syntax.html
file_extensions:
- ec
scope: source.example-c
contexts:
main:
# Strings begin and end with quotes, and use backslashes as an escape
# character
- match: '"'
scope: punctuation.definition.string.begin.example-c
push: double_quoted_string
# Comments begin with a '//' and finish at the end of the line
- match: '//'
scope: punctuation.definition.comment.example-c
push: line_comment
# Keywords are if, else for and while.
# Note that blackslashes don't need to be escaped within single quoted
# strings in YAML. When using single quoted strings, only single quotes
# need to be escaped: this is done by using two single quotes next to each
# other.
- match: '\b(if|else|for|while)\b'
scope: keyword.control.example-c
# Numbers
- match: '\b(-)?[0-9.]+\b'
scope: constant.numeric.example-c
double_quoted_string:
- meta_scope: string.quoted.double.example-c
- match: '\\.'
scope: constant.character.escape.example-c
- match: '"'
scope: punctuation.definition.string.end.example-c
pop: true
line_comment:
- meta_scope: comment.line.example-c
- match: $
pop: true
Now open the Sublime Console with View > Show Console or press the associated key binding. You'll see that the last line in the console is this:
generating syntax summary
Leaving the console open, click in the syntax file and perform another save operation again without changing anything. The same line appears in the console again.
Are there any compile or refresh steps, or does everything automatically reload?
As seen here, every time you modify the syntax definition, the file is recompiled and the results are cached. So there are no compile steps (other than saving) and nothing you need to do in order to refresh anything.
Now lets turn our attention back to the sample file. It's still open, and the syntax still says that it's Plain Text.
Now close the file and re-open it again; a shortcut for this is to use File > Open Recent > Reopen Closed File or it's associated key binding.
Notice that now that the file is re-opened, there are several changes. Firstly, the syntax name in the bottom right side of the window says Sample (or whatever you named your sublime-syntax file above). For another, the contents of the file are now syntax highlighted.
The colors you see are dependent on the color scheme you use, but an example might look like this:
// This is a line comment
if (x == 2)
y = 1
else
z = 1
How do I know that my syntax file, and the scope file it uses, are loaded and applied successfully?
You can see that the syntax file was compiled by the lack of an error message when you save your changes, and you can tell that it's applied by trying to use the syntax.
Here the syntax is being used automatically, but you'll find that if you check View > Syntax in the menu or click the current syntax name in the bottom right of the window, your syntax will appear there. Similarly there is now an entry in the command palette named Set Syntax: Sample (or whatever).
That leads us into your last question. If you go back to your sublime-syntax file, you'll see this at the top:
# See http://www.sublimetext.com/docs/3/syntax.html
file_extensions:
- ec
scope: source.example-c
The first thing to note is that file_extensions includes ec, and our sample file is called sample.ec; thus this syntax applies to it automatically due to it's name.
Now switch into the sample.ec file, place the cursor somewhere in the buffer and use Tools > Developer > Show Scope Name or press the associated key.
The content of the popup that appears will vary depending on where in the file the cursor is located, but the common point is that the scope that appears always starts with source.example-c.
In the syntax definition I have to specify a scope (e.g. scope: source.c) but where does that scope file live? Or rather, where do I create my scope file, and how do I name it, so that it loads?
As seen here, there is no such thing as a "scope file"; the sublime-syntax file directly specifies the scope as part of the syntax rules, so it's the only file that you need to create in order to create a syntax. It may look like a filename, but it is not one.
The scopes that are applied in the syntax matching rules in the syntax need to coincide with the scopes in your color scheme in order to be syntax highlighted; that's why you should use the scope naming rules to use the common set of scopes that all syntaxes share unless you're also planning to make a color scheme to go along with your syntax, but unless you use the recommended scopes, your syntax won't work well with other color schemes and your color scheme won't work well for other syntaxes.
From this starting point you can modify the sublime-syntax file here in order to make it highlight files the way you want. That would include changing the base scope at the top, applying an appropriate extension, and then including all of the rules that match your language.
As mentioned above, creating the actual rules to match your file is the most complicated part of creating a syntax unless your file format is very simplistic. It's outside the scope of something that could be conveyed in a Stack Overflow answer, but the official documentation linked above gives you some information on it.
Apart from looking at existing syntax files to see how they're doing what they do, you can also ask more directed questions on the Sublime forum.
I will shortly answer your questions, someone else can feel free to write a longer guide:
You put your syntax definitions inside a package: Select Preferences > Browse Packages... this should open your file explorer. There you can either create a new folder for a new package or use the User folder, which is the default user package. Inside that create a file YourSyntax.sublime-syntax.
You can open the ST console ctrl+` and it will output that the syntax is loaded and potential errors. You can also press ctrl+shift+p and write Set Syntax: YourSyntax in a buffer to directly see it.
You just need to save the file and it will reload the syntax definition.
So basically I am trying to rewrite a bash script which uses dialog --radiolist for choosing locale,keyboard,time. At the moment the tag is a number that corresponds to a local (I created a hashtable for it). But because I have, and want to keep it that way for now, around 100 locales it gets messy at the end.
What I wanna achieve is to make it more compact without having to add or add an artificial, non visible item that might easily translate to its tag. (as a tag I would put the locale name)
What I have tried:
1. Noobish thing but I though that there might be some way to include empty like NULL in ASCII or 0, blank space etc, but dialog would always make it visible.
2. Exclude the item at all and finish on on/off but instead on/off takes place of item (not surprisingly if options are as follow --radiolist text height width list-height [ tag item status ])
3. Instead of letting the dialog on exit write to the output the name of the chosen locale I created an output statement myself.
I had red a lot about dialog and whiptail(http://linux.die.net/man/1/dialog, http://linuxcommand.org/lc3_adv_dialog.php) but always end up with having to add tag and an item. Would appreciate any suggestions and maybe some info if there is easily plug-gable dialog/whiptail compatible libs.
Thank You in advance
Perhaps you overlooked the --no-tags option (see manpage):
--no-tags
Some widgets (checklist, inputmenu, radiolist, menu) display a
list with two columns (a "tag" and "description"). The tag is
useful for scripting, but may not help the user. The --no-tags
option (from Xdialog) may be used to suppress the column of tags
from the display. Unlike the --no-items option, this does not
affect the data which is read from the script.
The question mentions whiptail and consistency, which could refer to consistency across dialog and whiptail. There is none, since
whiptail provides fewer options than dialog (inevitably, there will be differences, since there is no one-one mapping possible)
consistency as such between the two is done in dialog occasionally to help with compatibility (the reverse is not true).
I wanted to know if there are any resources
available for understanding and using
the 'term' class in urxvt.
The documentation makes a very general
set of references to it, but doesn't really
define the terms.
The uxrvt perl extensions also make very limited use
of the 'term' object, so there isn't much code
to study for reference.
My goals are simple:
To open a new terminal window.
To pass a command to the new terminal window,
then leave the window open for further input.
(example: "ls" or "echo 'Hello World'", then
leave the cursor awaiting further input)
To be able to specify which desktop the
new terminal will appear on.
Questions:
1. How exactly is $term defined?
The documentation says:
$term = new urxvt::term $envhashref, $rxvtname, [arg...]
I've used "my $env = $self->env;" to define the
$envhashref. So I suppose that the existing terminal's
environment variables are used for the new terminal.
I suppose this corresponds directly to the environment
variables themselves, since the following reproduces
those variables...
my #envv = $self->envv;
foreach (#envv) {
print "$_\n";
}
...and the following creates a reference to the 'env' hash:
my $env = $self->env;
Is this correct? It seems odd to have to explicitly declare
the environment if that setting will remain unchanged in the
vast majority of cases.
2. How should $rxvtname be set? Setting it to a name of my
choice results in two windows opening rather than one.
That behavior is odd... what is the correct way to define
the $rxvtname variable?
What exactly does ", [arg...]" refer to?
3. How is $term itself used? It apparently isn't
a reference to the new terminal window. What is its
purpose and how do you use it? An example would
probably be extremely useful here.
4. How can $term->exec_async ($cmd) send a command
to the new terminal window? Is there a better way
to send commands to a new window? Examples?
5. Is there a way to specify which desktop a terminal
window should appear in?
Hopefully this thread can serve as 'documentation' for anyone else
who has already scoured the man pages for urxvt, urxvtperl (as well as
urxvt.pm) and is left without a clear understanding. And if there's
a comprehensive reference on the web somewhere that contains full
explanations and examples, that would be great to know about, too.
Thanks in advance for your help.
I have a linux installation without X. When I launch a third-part application (i.e. gstreamer) it draws on a portion of the screen, let the users see through the external areas.
I want to "clear" the console so it appears black. Of course the clear command won't work because you still see the prompt.
Might you recommend any way to achieve this?
The environment variable which contains the output displayed by the prompt is named PS1. You can empty this variable when needed.
Don't forget to keep a 'backup' of the value in order to be able to set it back to its old value