We Keep Coding

How can I change baselines code output/replay (PPO) on github?

I am trying to run my own version of baselines code source of reinforcement learning on github: (https://github.com/openai/baselines/tree/master/baselines/ppo2).
Whatever I do, I keep having the same display which looks like this :
Where can I edit it ? I know I should edit the "learn" method but I don't know how

Those prints are the result of the following block of code, which can be found at this link (for the latest revision at the time of writing this at least):
if update % log_interval == 0 or update == 1:
ev = explained_variance(values, returns)
logger.logkv("serial_timesteps", update*nsteps)
logger.logkv("nupdates", update)
logger.logkv("total_timesteps", update*nbatch)
logger.logkv("fps", fps)
logger.logkv("explained_variance", float(ev))
logger.logkv('eprewmean', safemean([epinfo['r'] for epinfo in epinfobuf]))
logger.logkv('eplenmean', safemean([epinfo['l'] for epinfo in epinfobuf]))
logger.logkv('time_elapsed', tnow - tfirststart)
for (lossval, lossname) in zip(lossvals, model.loss_names):
logger.logkv(lossname, lossval)
logger.dumpkvs()
If your goal is to still print some things here, but different things (or the same things in a different format) your only option really is to modify this source file (or copy the code you need into a new file and apply your changes there, if allowed by the code's license).
If your goal is just to suppress these messages, the easiest way to do so would probably be by running the following code before running this learn() function:
from baselines import logger
logger.set_level(logger.DISABLED)
That's using this function to disable the baselines logger. It might also disable other baselines-related output though.

CTypes error in return value

I'm testing a very simple NASM dll (64-bit) called from ctypes. I pass a single int_64 and the function is expected to return a different int_64.
I get the same error every time:
OSError: exception: access violation writing 0x000000000000092A
where hex value translates to the value I am returning (in this case, 2346). If I change that value, the hex value changes to that value, so the problem is in the value I am returning in rax. I get the same error if I assign mov rax,2346.
I have tested this repeatedly, trying different things, and I've done a lot of research, but this seemingly simple problem is still not solved.
Here is the Python code:
def lcm_ctypes():
input_value = ctypes.c_int64(235)
hDLL = ctypes.WinDLL(r"C:/NASM_Test_Projects/While_Loop_01/While_loops-01.dll")
CallTest = hDLL.lcm
CallTest.argtypes = [ctypes.c_int64]
CallTest.restype = ctypes.c_int64
retvar = CallTest (input_value)
Here is the NASM code:
[BITS 64]
export lcm
section .data
return_val: dq 2346
section .text
finit
lcm:
push rdi
push rbp
mov rax,qword[return_val]
pop rbp
pop rdi
Thanks for any information to help solve this problem.

Your function correctly loads 2346 (0x92a) into RAX. Then execution continues into some following bytes because you didn't jmp or ret.
In this case, we can deduce that the following bytes are probably 00 00, which decodes as add byte [rax], al, hence the access violation writing 0x000000000000092A error message. (i.e. it's not a coincidence that the address it's complaining about is your constant).
As Michael Petch said, using a debugger would have found the problem.
You also don't need to save/restore rdi because you're not touching it. The Windows x86-64 calling convention has many call-clobbered registers, so for a least-common-multiple function you shouldn't need to save/restore anything, just use rax, rcx, rdx, r8, r9, and whatever else Windows lets you clobber (I forget, check the calling convention docs in the x86 tag wiki, especially Agner Fog's guide).
You should definitely use default rel at the top of your file, so the [return_val] load will use a RIP-relative addressing mode instead of absolute.
Also, finit never executes because it's before your function label. But you don't need it either. You had the same finit in your previous asm question: Passing arrays to NASM DLL, pointer value gets reset to zero, where it was also not needed and not executed. The calling convention requires that on function entry (and return), the x87 FPU is already in the state that finit puts it in, more or less. So you don't need it before executing x87 instructions like fmulp and fidivr. But you weren't doing that anyway, you were using SSE FP instructions (which is recommended, especially in 64-bit mode), which don't touch the x87 state at all.
Go read a good tutorial and some docs (some links in the x86 tag wiki) so you understand what's going on well enough to debug a problem like this on your own, or you will have a bad time writing anything more complicated. Guessing what might work doesn't work very well for asm.
From a deleted non-answer: https://www.cs.uaf.edu/2017/fall/cs301/reference/nasm_vs/ shows how to set up Visual Studio to build an executable out of C++ and NASM sources, so you can debug it.

How to debug Access Violation that it thrown from windows library ucrtbase?

My app (java based) launches python for Windows, which, in turn, calls os.spawnv to launch another python.
From time to time I am having Access Violation exception.
00 005eedb0 763e68f3 ucrtbase!<lambda_7d9ee38b11181ddfdf5bd66394e53cb7>::operator()+0x1b
01 005eedfc 763e65d9 ucrtbase!construct_environment_block<char>+0xdb
02 005eee14 763e7aba ucrtbase!common_pack_argv_and_envp<char>+0x31
03 005eeebc 763e778a ucrtbase!execute_command<char>+0x62
04 005eeee8 763e8066 ucrtbase!common_spawnv<char>+0x13f
05 005eeef8 65a323d7 ucrtbase!_spawnve+0x16
06 005eef38 65a360c6 python35!os_spawnve_impl(int mode = 0n0, struct _object * path = 0x03adfde0, struct _object * argv = 0x03b258a0, struct _object * env = 0x03b25a80)+0x1a7 [c:\build\cpython\modules\posixmodule.c # 5299]
I've set bp on c:\build\cpython\modules\posixmodule.c # 5299 and here is what I see in python sources
Py_BEGIN_ALLOW_THREADS
spawnval = _spawnve(mode, path_char, argvlist, envlist);
Py_END_ALLOW_THREADS
I've checked all arguments twice: they are ok. mode is 0, path_char is path to my interpeter, argvlist and envlist are both char**: NULL-terminated arrays of NULL-teminated strings.
So, it is not python fault.
I know that _spawnve is not thread safe, but there is only one thread.
I do not have sources nor private symbols for MS ucrtbase. What is the right approach to investigate it?
--
What is the difference between ucrtbased.dll and ucrtbase.dll?
Should I compile Python against ucrtbased.dll to find more symbols?

Aha! Mystery solved.
See https://bugs.jython.org/issue29908 for details, but basically spawnve() is broken. It relies on these secret current directory environment variables that start with an =, and is likely to crash if the environment doesn't contain them.
cmd.exe and explorer.exe set them when launching processes, but if you launch a process yourself with a constrained environment that doesn't include them, then that process itself tries to call spawnve() you are heading to crash land.
The workaround is to set at least one environment variable that matches the pattern; e.g. =c:=pants and you are good.

I have just encountered the same problem while trying to build SciPy; an access violation is thrown as part of setup.py trying to spawnve() a C compiler.
I haven't gotten to the bottom of it yet, but stepping through the disassembly, in my case at least. Here's what happens:
Calls get_environment_from_os() which gives you a pointer to the current process's environment variables.
Iterates through this list of null-terminated strings looking for environment variables whose name starts with an '='
Apparently this is Windows's way of expressing the set of current directories, e.g. there should be an environment variable '=c:' with a value like "c:\mystuff"
It never finds any, and trundling off into uninitialized memory in its futile quest.
Boom.
Inspecting the memory address returned by get_environment_from_os() shows me a pretty sane looking list of environment variables, but none whose key begins with an '=' character.
I'm still digging into exactly why and how things get into this state; it doesn't always seem to happen which makes me suspect threads, but like you, I can't find any evidence to back this up; though I don't have intimate knowledge about how distutils works.

Python futurize without replacing / with old_div

I am using futurize --stage2 which aplies a number of source-source transformation to make the code python2 and python3 compatible. One of those fixes is that all divisions a/b are replaced by old_div(a/b), which I would like to avoid (there is too many, and many of them are replaced unnecessarily, such as math.pi/2.. The documentation says that --nofix (or -x) can be used to avoid running a certain fixes, but trying --nofix=fix_divison or --nofix=libfuturize.fixes.fix_divison has no effect with --stage2. Can someone perhaps help how to ignore that particular fixer otherwise?

Omit the prefix fix_.
futurize --nofix=division ...
Depending on version you're using, you may need to specify the division_safe:
futurize --nofix=division_safe ...

Loading a document on OpenOffice using an external Python program

I'm trying to create a python program (using pyUNO ) to make some changes on a OpenOffice calc sheet.
I've launched previously OpenOffice on "accept" mode to be able to connect from an external program. Apparently, should be as easy as:
import uno
# get the uno component context from the PyUNO runtime
localContext = uno.getComponentContext()
# create the UnoUrlResolver
resolver = localContext.ServiceManager.createInstanceWithContext(
"com.sun.star.bridge.UnoUrlResolver", localContext)
# connect to the running office
ctx = resolver.resolve("uno:socket,host=localhost,port=2002;"
"urp;StarOffice.ComponentContext")
smgr = ctx.ServiceManager
# get the central desktop object
DESKTOP =smgr.createInstanceWithContext("com.sun.star.frame.Desktop", ctx)
#The calling it's not exactly this way, just to simplify the code
DESKTOP.loadComponentFromURL('file.ods')
But I get an AttributeError when I try to access loadComponentFromURL. If I make a dir(DESKTOP), I've see only the following attributes/methods:
['ActiveFrame', 'DispatchRecorderSupplier', 'ImplementationId', 'ImplementationName',
'IsPlugged', 'PropertySetInfo', 'SupportedServiceNames', 'SuspendQuickstartVeto',
'Title', 'Types', 'addEventListener', 'addPropertyChangeListener',
'addVetoableChangeListener', 'dispose', 'disposing', 'getImplementationId',
'getImplementationName', 'getPropertySetInfo', 'getPropertyValue',
'getSupportedServiceNames', 'getTypes', 'handle', 'queryInterface',
'removeEventListener', 'removePropertyChangeListener', 'removeVetoableChangeListener',
'setPropertyValue', 'supportsService']
I've read that there are where a bug doing the same, but on OpenOffice 3.0 (I'm using OpenOffice 3.1 over Red Hat5.3). I've tried to use the workaround stated here, but they don't seems to be working.
Any ideas?

It has been a long time since I did anything with PyUNO, but looking at the code that worked last time I ran it back in '06, I did my load document like this:
def urlify(path):
return uno.systemPathToFileUrl(os.path.realpath(path))
desktop.loadComponentFromURL(
urlify(tempfilename), "_blank", 0, ())
Your example is a simplified version, and I'm not sure if you've removed the extra arguments intentionally or not intentionally.
If loadComponentFromURL isn't there, then the API has changed or there's something else wrong, I've read through your code and it looks like you're doing all the same things I have.
I don't believe that the dir() of the methods on the desktop object will be useful, as I think there's a __getattr__ method being used to proxy through the requests, and all the methods you've printed out are utility methods used for the stand-in object for the com.sun.star.frame.Desktop.
I think perhaps the failure could be that there's no method named loadComponentFromURL that has exactly 1 argument. Perhaps giving the 4 argument version will result in the method being found and used. This could simply be an impedance mismatch between Python and Java, where Java has call-signature method overloading.

This looks like issue 90701: http://www.openoffice.org/issues/show_bug.cgi?id=90701
See also http://piiis.blogspot.com/2008/10/pyuno-broken-in-ooo-30-with-system.html and http://udk.openoffice.org/python/python-bridge.html