" Nothing more expected -> " when running "do it" in Squeak - squeak
I'm trying to run some command split on several lines from the Workspace in Squeak 5.1
When it's on one line, like below, it works fine:
Perroquet new nom: 'Polly' ; vocabulaire: 'Screatch! Go away'; vocabulaire: 'give me food'; parle.
However, if I try to split it on several lines, with or without tabs, it doesn't run and adds "Nothing more expected ->" in the workspace
Perroquet new nom: 'Polly' ;
vocabulaire: 'Screatch! Go away';
vocabulaire: 'give me food'; parle.
after "do it":
Perroquet new nom: 'Polly' ;
vocabulaire: 'Screatch! Go away';
Nothing more expected ->vocabulaire: 'give me food'; parle.
In the doc that I'm using, the examples given seem to be able to split it without any trouble. Is that because of different version of Squeak? Am I missing something somewhere?
You have to select the whole expression so it is highlighted and then invoke the do-it command. Otherwise, only the text on the current line is attempted to be evaluated, which fails because there is no receiver before #vocabulaire:
Related
Issue in pexpect when text wraps within session
I am working on a pexpect script that is running populating an output file name and then a prompt for the file's parameters.
The program that the script runs asks for Device: then Parameters: always on the same line.... so if the file path-name that is entered for Device is long, sometimes the Parameters prompt wraps to the next line.
My code looks like..
child.expect_exact('Device:')
child.sendline('/umcfiles/ftp_dir/ftp_peoplesoft/discount/AES_DISCOUNT_15010.TXT')
child.expect_exact('Parameters:')
This times out.. and here is what is in child.before
' /umcfiles/ftp_dir/ftp_peoplesoft/discount/AES_DISCOUNT_15010.TXT Param\r\neters: "RWSN" => '
so the expect fails... (a child.expect('Parameters:') also fails)
How can I ignore the \r\n if it is there, because depending on the length of the path/filename I am using it may not be there at all, or be in a different position.
Thanks!
Actually... I found a way to calculate how much is left on the given line, and dynamically set my expect to how much of the Parameter prompt should be visible... seems to be working
#look for end of line and fix how much of 'Parameters:' we look for in pexpect
dlen = 80-len('Device: /umcfiles/ftp_dir/ftp_peoplesoft/discount/AES_DISCOUNT_15010.TXT')
pstr='Parameters:'
if dlen > len(pstr):
dlen=len(pstr)
else:
dlen=dlen-3 #remove the /r/n
child.expect(pstr[0:dlen])
code blocks don't work in Spyder (Anaconda3)
I am a beginner in Python using Spyder to code from Anaconda3.
I tried to enter such codes in Spyder (Python 3.7). I pressed "Enter" when trying to split the codes and the indents appear auto. But it always returns with "SyntaxError: invalid syntax" and "SyntaxError: 'return' outside function".
E.g. 1
data = {'state':['Ohio','Ohio','Ohio','Nevada','Nevada','Nevada'],
'year':[2000,2001,2002,2001,2002,2003],
'pop':[1.5,1.7,3.6,2.4,2.9,3.2]}
When I press F9 in either line, it returns "SyntaxError: invalid syntax".
E.g. 2
def f(x):
return pd.Series([x.min(),x.max()],index=['min','max'])
Press F9 to run the line, it returns "SyntaxError: unexpected EOF while parsing". If in the second line, it returns "SyntaxError: 'return' outside function".
In addition, I also tried to put "\"s at the end of each line. It doesn't work either. And find from webpages that if the lines end with : or , then you don't need \ to split.
But!!! if I deleted the 'Enters' and put everything in a single line without splits, it works well totally.
Why my python cannot work with code blocks? How can I fix it with Anaconda3?
Thank you so much~~~~
The problem is that you need to select the entire function before pressing F9, if you select only a part of it it will raise an error
You can use \ at the end of each line to tell Python that the line continues below:
data = {\
'state':['Ohio','Ohio','Ohio','Nevada','Nevada','Nevada'],\
'year':[2000,2001,2002,2001,2002,2003],\
'pop':[1.5,1.7,3.6,2.4,2.9,3.2]\
}
Having the dictionary split across multiple lines may look pretty, but it is not proper syntax. I've also been tripped up by tutorials that show their dictionaries like that :|
This may not work in interpreters other than IDLE.
How do I command the Rascal Shell not to truncate my output if it's quite long
This seems like a pretty basic question to me, but I don't seem to be able to find the answer anywhere. I need to get the full output of a command in the Rascal shell, however, Rascal seems to truncate long outputs automatically. Is there any way to tell the shell to always show the full output for a given command.
Example:
rascal>calculateCodeDuplication("smallsql0.21_src")
list[list[loc]]: [
[
|java+compilationUnit:///src/smallsql/database/NoFromResult.java|(1310,26,<34,0>,<34,26>),
|java+compilationUnit:///src/smallsql/database/NoFromResult.java|(1494,56,<43,1>,<43,57>),
|java+compilationUnit:///src/smallsql/database/NoFromResult.java|(1558,49,<46,1>,<48,2>),
|java+compilationUnit:///src/smallsql/database/NoFromResult.java|(1616,44,<51,1>,<53,2>),
|java+compilationUnit:///src/smallsql/database/NoFromResult.java|(1665,57,<55,1>,<57,2>),
|java+compilationUnit:///src/smallsql/database/NoFromResult.java|(1731,51,<59,1>,<61,2>),
|java+compilationUnit:///src/smallsql/database/NoFromResult.java|(1791,57,<63,1>,<66,2>),
|java+compilationUnit:///src/smallsql/database/NoFromResult.java|(1853,65,<68,1>,<71,2>),
|java+compilationUnit:///src/smallsql/database/NoFromResult.java|(1927,61,<74,1>,<77,2>),
|java+compilationUnit:///src/smallsql/database/NoFromResult.java|(1993,56,<79,1>,<82,2>),
|java+compilationUnit:///src/smallsql/database/NoFromResult.java|(2055,50,<84,1>,<86,2>),
|java+compilationUnit:///src/smallsql/database/NoFromResult.java|(2114,54,<88,1>,<90,2>),
|java+compilationUnit:///src/smallsql/database/NoFromResult.java|(2177,42,<92,1>,<94,2>),
|java+compilationUnit:///src/smallsql/database/NoFromResult.java|(2248,7,<96,24>,<96,31>),
|java+compilationUnit:///src/smallsql/database/NoFromResult.java|(2225,136,<96,1>,<101,2>),
|java+compilationUnit:///src/smallsql/database/NoFromResult.java|(2390,8,<103,24>,<103,32>),
|java+compilationUnit:///src/smallsql/database/NoFromResult.java|(2367,153,<103,1>,<107,2>),
|java+compilationUnit:///src/smallsql/database/NoFromResult.java|(2526,54,<109,1>,<111,2>),
|java+compilationUnit:///src/smallsql/database/NoFromResult.java|(2586,51,<113,1>,<115,2>),
|java+compilationUnit:///src/smallsql/database/NoFromResult.java|(2671,16,<118,27>,<118,43>),
|java+compilationUnit:///src/smallsql/database/NoFromResult.java|(2645,78,<118,1>,<120,2>),
|java+compilationUnit:///src/smallsql/database/NoFromResult.java|(2731,49,<123,1>,<125,2>),
|java+compilationUnit:///src/smallsql/database/NoFromResult.java|(2789,48,<128,1>,<130,2>),
|java+compilationUnit:///src/smallsql/database/NoFromResult.java|(2846,48,<133,1>,<135,2>),
|java+compilationUnit:///src/smallsql/database/NoFromResult.java|(2902,46,<138,1>,<140,2>),
|java+compilationUnit:///src/smallsql/database/NoFromResult.java|(2955,72,<143,1>,<143,73>),
|java+compilationUnit:///src/smallsql/database/NoFromResult.java|(3118,19,<149,43>,<149,62>),
|java+compilationUnit:///src/smallsql/database/NoFromResult.java|(3041,227,<146,4>,<152,5>),
|java+compilationUnit:///src/smallsql/database/NoFromResult.java|(1340,1931,<36,0>,<153,1>),
|java+compilationUnit:///src/smallsql/database/NoFromResult.java|(0,3273,<1,0>,<153,3>),
|java+compilationUnit:///src/smallsql/database/ExpressionFunctionLog.java|(1305,26,<33,0>,<33,26>),
|java+compilationUnit:///src/smallsql/database/ExpressionFunctionLog.java|(1418,51,<38,4>,<38,55>),
|java+compilationUnit:///src/smallsql/database/ExpressionFunctionLog.java|(1477,123,<40,4>,<43,5>),
|java+compilationUnit:///src/smallsql/database/ExpressionFunctionLog.java|(1337,266,<36,0>,<44,1>),
|java+compilationUnit:///src/smallsql/database/ExpressionFunctionLog.java|(0,1603,<1,0>,<44,1>),
|java+compilationUnit:///src/smallsql/junit/TestDBMetaData.java|(1298,23,<33,0>,<33,23>),
|java+compilationUnit:///src/smallsql/junit/TestDBMetaData.java|(1325,18,<35,...
(note that the console outputs cuts off in the middle of the line with ...)
There are a number of ways. Here are the two I use most frequently:
use iprintln or println from the IO module. The former does indentation which is nice for complex outputs. example: import IO; iprintln(calculateCodeDuplication("smallsql0.21_src")); The nice thing about this is that in the terminal values of loc type are hyperlinks
open an editor for the value using the util::ValueUI module (only in Eclipse), for example: import util::ValueUI; text(calculateCodeDuplication("smallsql0.21_src")); This will pop up an editor with the indented output value (nice to search in using CTRL+F, but the loc is not a hyperlink. Would love to have a contribution in that direction :-))
Caveat for the first one is that scrolling up and down in the Eclipse terminal is very slow on Mac's, and not really fast on Windows either.
Linux expect newline
I have a custom package I want to install automatically in my docker using expect. The first thing the package asks me to do is press Enter to continue, then it prints another 2 empty lines then it waits for an input. My expect script : #!/usr/bin/expect -f set timeout -1 spawn ./install expect "\n" send -- "\n" But as you can see in the image, it just runs the installer and exits. I tried removing the expect "\n" so only send -- "\n" will execute but now even the install message doesn't appear (tried with set timeout 1000 before send and it also didn't work) Any ideas? P.S : This is a link to the package if anyone wants to have a go at it: https://www.bayometric.com/downloads/digital-persona/DP_UareU_Linux223_20140429.2.zip (the installer is inside DP-UareU-RTE-2.2.3-1.20140429_1533.tar.gz)
expect "\n" match a linefeed exactly, I think this is not what your program is sending. To wait for a Shell prompt you can use expect "%" or expect "*" to match anything. If you need to make sure you're dealing with the right prompt you may be able to use something like expect "*Linux Installation*". Also don't send \n but \r for the enter key : #!/usr/bin/expect spawn ./install expect "*Linux Installation*" send "\r" expect eof Note that the default flag is -gl for glob pattern matching but you can also use the -re flag for regular expression matching.
How to specify a value for a Jenkins environment variable that contains a space
I am trying to specify a value for a Jenkins environment variable (as created on the Manage Jenkins -> Configure System screen, under the heading "Global properties") which contains a space. I want to use this environment variable in an Execute Shell build step. The option that I need to appear in the command line in the build step is:
--platform="Windows 7"
The syntax I am using on the command line is --platform=${VARIABLE_NAME}
No matter how I attempt to format it, Jenkins seems to reformat it so that it is treated as two values. I have tried:
Windows 7
"Windows 7"
'Windows 7'
Windows\ 7
The corresponding results, when output during the Execute Shell build step have been:
--platform=Windows 7
'--platform="Windows' '7"'
'--platform='\''Windows' '7'\'''
--platform=Windows/ 7
I have also tried changing my command line syntax to --platform='${VARIABLE_NAME}' as well as '--platform=${VARIABLE_NAME}', but in each of those cases the ${VARIABLE_NAME} is not resolved at all and just appears as ${VARIABLE_NAME} on the resulting command.
I am hoping there is a way to make this work. Any suggestions are most appreciated.
You should be able to use spaces without any special characters in the global properties section.
For example, I set a variable "THIS_VAL" to have the value "HAS SPACES".
My test build job was the following:
#!/bin/bash
set +v
echo ${THIS_VAL}
echo "${THIS_VAL}"
echo $THIS_VAL
and the output was
[workspace] $ /bin/bash /tmp/hudson8126983335734936805.sh
HAS SPACES
HAS SPACES
HAS SPACES
Finished: SUCCESS
I think what you need to do is use the following:
--platform="${VARIABLE_NAME}"
NOTE: Use double quotes, not single quotes. Using single quotes makes the stuff inside the quotes literal, meaning that any variables will be printed as is, not parsed into the actual value. Therefore '${VARIABLE_NAME}' will be printed as is, not parsed into "Windows 7".
EDIT:
Based on #BobSilverberg comment below, use the following:
--platform="$VARIABLE_NAME"
Note: no curly brackets.