I've been working through the Julia Tutorial, and strangely (1,2,3) returns (1,2,0).
(1,2,3,4) returns (1,2,0,0)
(1,2,3,4,5) returns (1,2,3,4,5) as expected.
It seems that sets of size 3 or 4 replace the 3rd and fourth elements with 0. I don't expect that this is normal behavior but I'm not familiar with the environment so I'm not sure with what I might have done to cause this.
I deleted all julia files from my profile and restarted the interpreter, and the behavior persists.
Version 0.3.5 (2015-01-08 22:33 UTC) under windows executed in cygwin.
Same problem when executed from command.
This is a (very strange!) long standing display bug on Windows. You can read about it at the link - in short, the value is correct but it doesn't display right. It should also be fixed in final release of Julia 0.4, which will use LLVM 3.5 (at least, thats what the thread says).
Related
Anyone got an idea why
system2("bash", "ls")
would result in (both in R-Gui and RStudio Console)
/usr/bin/ls: /usr/bin/ls: cannot execute binary file
while other shells work w/o issues (see example below) and the "bash" in the RStudio Terminal also works w/o problems. AND if there is a remedy for that?
Working system2 example:
system2("powershell", "dir")
Running R-3.6.3 on Windows 10 here ... with "Git bash" executing as "bash".
PS: just in case someone wonders - I also tried the full path ie /usr/bin/ls -> same result
Ok - this does the trick
system2("bash", input = "ls")
so instead of args = ... as with the powershell command one needs (or more interestingly sometimes 'can') use the input = ... parameter with bash
OR as mentioned in the comments by #oguzismail this will also work
system2("bash", "-c ls")
as well as pointed out by #Christoph
system2("ls")
also works sometimes (ie in some RStudio[?] setups it will not return results in some it will).
But I have come to notice that different combinations of R-versions with different RStudio versions [or more probably Locales] will not always behave consistently of course also depending on the availability of bash commands like ls (more generally /usr/bin) being on the PATH or not.
So choose what suits u best!
IPython and Jupyter notebooks keep track of an 'execution count'. This is e.g. shown in the prompts for input and output: In[...] and Out[...].
How can you get the latest execution count programmatically?
The variable Out cannot be used for this:
Out is a dictionary, with execution counts as keys, but only for those cells that yielded a result; note that not all (cell) executions need to yield a result (e.g. print(...)).
The variable In seems to be usable:
In is a list of all inputs; it seems that In[0] is always primed with an empty string, so that you can use the 1-based execution count as index.
However, when using len(In) - 1, in your code, you need to take into account that the execution count seems to be updated before execution of that new code. So, actually, it seems you need to use len(In) - 2 for the execution count of the most recent already completed execution.
Questions:
Is there a better way to get the current execution count?
Can you rely on the above observations (the 'seems')?
After more digging, I found the (surprisingly simple) answer:
from IPython import get_ipython
ipython = get_ipython()
... ipython.execution_count ...
This does not show up in the IPython documentation, though could (should?) have been mentioned here: https://ipython.readthedocs.io/en/stable/api/generated/IPython.core.interactiveshell.html (I guess attributes are not documented). Here you do find run_line_magic (which was mentioned in a comment to my question).
The way I found this attribute is by defining ipython as above and then doing code completion (TAB) on ipython. (but it does not have documentation).
help(ipython)
gives you documentation about InteractiveShell, and it does mention execution_count (though it does not confirm its purpose):
| execution_count
| An int trait.
I'm messing around with tables in PyQt for the first time and am running into some unexpected behaviour when editing cell values.
Specifically when I type data, it appears over the top of the existing cell data (so if the cell originally had '123' in it, and I type '456', I end up with 2 lots of 3 characters, one over the top of the other - at least until I press enter).
Just to be clear, I have no issues with setData writing the changes to the model, or with the changes being reflected in the table after editing is complete - that's all happening fine. The only problem is seeing the original value and the new value I'm typing in occupying the same space until editing finishes.
So presumably what I want to do is alter my existing data method:
def data(self, index, int_role=None):
row = index.row()
column = index.column()
if int_role == QtCore.Qt.DisplayRole:
return str(self._data[row][column])
elif int_role == QtCore.Qt.EditRole:
return str(self._data[row][column])
else:
return None
so that it somehow recognizes if the cell it's being asked to provide data for (in DisplayRole mode) is currently being edited, and if so, return an empty string instead of the actual data (as the EditRole branch of the code is being called as well at the same time and is happily handling display duties until editing is finished).
I've had a look around the QT docs but cannot work out how to do this.
Edit: After ceppo's comments, I've looked at creating a new ItemDelegate - but looking into it further it looked like I would be able to instead switch out the itemEditorFactory in the existing one - specifically I added the following to my code:
newEditor = QLineEdit()
newEditor.setAutoFillBackground(True)
ief = QItemEditorFactory()
ief.registerEditor(QVariant.String, LineEditorCreator())
tableView.itemDelegate().setItemEditorFactory(ief)
with LineEditorCreator defined as follows:
class LineEditCreator(QItemEditorCreatorBase):
def __init__(self):
QItemEditorCreatorBase.__init__(self)
def createWidget(self, parent):
wdgt = QLineEdit(parent)
wdgt.setAutoFillBackground(True)
return wdgt
def valuePropertyName(self):
return "String"
however now I get a Segmentation fault as soon as I try to edit a cell value. Putting a print statement in as the first line in the createWidget statement shows it not ever getting executing - some print statements in the createWidget shows that the Segmentation faults occur even before the first line of createWidget executes (though the __ init __ method completes fine).
Ceppo also said that the behaviour I'm experiencing could be due to a bug (in Qt, PyQt or something else underlying) - I'll be replacing my current Ubuntu 15.10 installation with 16.04 soon so with some luck that will solve the issue entirely.
Upgrading ubuntu 15.10 to 16.04 did indeed fix the problem.
My 16.04 distro has python3-pyqt5 and other qt packages with versions all around 5.5.1 - I did check but didn't think to jot down the versions of those packages in my 15.10 installation before wiping it - but packages.ubuntu.com says 5.4.2 is the current version for 15.10 and that sounds familiar.
So if anyone else with QT 5.4.2 is running into the same thing, upgrading to 5.5.1 might be worth a try - either by upgrading to a newer distro or attempting to find and use a backport of the newer QT version.
Thanks Ceppo93, it was a good guess.
I'm making a Turbo Pascal 7.0 program for my class, it has to be on Graphic Mode.
A message pops up
BGI Error: Graphics not initialized (use InitGraph).
I'm already using InitGraph and graph.tpu and I specified the route as "C:\TP7\BGI".
My S.O is Windows 7 and I'm using DosBox 0.74, I already tried to paste all the files from the folder BGI into BIN.
What should I do?
Since dos doesn't have system graphic drivers, the BGI functions as such for BP7.
So in short, use a BGI suitable for your videocard. The ones supplied with BP7 are very old, there are newer, VESA ones that you could try.
Afaik 3rd party BGI needs to be registered explicitly in code though.
At first I have had this "missing Graph.tpu"- ... and later the "Use Initgraph"-issue too.
After hours trying (and reading some not politeful comments in the internet) I finally got Turbo Pascal 7 succesfully running (in Windows 10, x64). In summary I want to share "some secrets":
install the "TP(WDB)-7.3.5-Setup.msi" (comes from clever people in Vietnam)
make sure, that there's the CORRECT PATH to the "BGI"-directory in your program-code. For example:
driver := Detect;
InitGraph (driver, modus, 'c:\TPWDB\BGI');
(By the way: This is ALL, what's there to do with "Initgraph".)
make sure, that in TP7 under "Options" --> "Directories" are the CORRECT PATHS both to "C:\TPWDB\UNITS" and Your actual working dir e.g. "C:\TPWDB\myPrograms"
THAT's IT.
Annotations: The "Graph.TPU" (usually) is already in "UNITS" (together with "Graph3.tpu" by the way).
Hazzling around old driver's isn't needed even... :)
Just the correct paths... :)
Hope, that can help ...
Good day. The programs function is to take an equipment number (or none), display that number with a description (or all) in alv, and then run IE03 should the user double click on
Program worked fine in client 110, but in 150 a runtime error happens. This morning I tried to make a new program with a shorter name (only lead I had), activated it (window popped up asking me to activate the previous version as well). That didn't work and now the original doesn't work in either.
The program "SAPLSKBH" is terminating because program line is too long, being 78 chars wide which is too much for the internal table "\FUNCTION=K_KKB_FIELDCAT_MERGE\DATA=L_ABAP_SOURCE[]"
It sounds like you are using REUSE_ALV_GRID_DISPLAY for output, is that correct?
Check you source code; somewhere you have a line that is more than 78 characters. The function K_KKB_FIELDCAT_MERGE takes the source code of your program to produce a structure that corresponds to the table/structure you give it. (In the old days, there was a limit of 78 characters width for a line of ABAP code, and this is an old function module).
You can alternatively build a field catalog yourself in code, rather than use this function.