I came across an interesting issue writing a little side scroller today. Instead of a sprite sheet I planned to use single pictures for the animations as I'm lacking a good "packer" for creating sprite sheets (and honestly, also the patience and passion as it's only a test project).
Anyways, I created a list of the 8 PNGs (with transparency) depicting the walk animation to the right side. I deemed it a good idea to prepare the flipped images for walking to the left side also in the constructor and not frame-wise when the game is running (flip really consumes a lot of CPU as I measured).
using a for loop, I get a memory leak
self.move_l = [##List of 8 PNG images with transparency for moving right]
self.move_r = []
for img in self.move_l:
self.move_r.append(pygame.transform.flip(img, True, False)
Error traceback:
Traceback (most recent call last):
File "D:\Python34\_Projects\efg\efg.py", line 196, in <module>
Main = MainProgram((1024, 680))
File "D:\Python34\_Projects\efg\efg.py", line 31, in __init__
self.player = actors.Player(screen_size)
File "D:\Python34\_Projects\efg\actors.py", line 30, in __init__
self.move_r.append(pygame.transform.flip(img, True, False))
pygame.error: Out of memory
When I add each image seperately, it works perfectly:
self.move_r = []
self.move_r.append(pygame.transform.flip(self.move_l[0], True, False))
self.move_r.append(pygame.transform.flip(self.move_l[1], True, False))
self.move_r.append(pygame.transform.flip(self.move_l[2], True, False))
self.move_r.append(pygame.transform.flip(self.move_l[3], True, False))
self.move_r.append(pygame.transform.flip(self.move_l[4], True, False))
self.move_r.append(pygame.transform.flip(self.move_l[5], True, False))
self.move_r.append(pygame.transform.flip(self.move_l[6], True, False))
self.move_r.append(pygame.transform.flip(self.move_l[7], True, False))
Does anybody have a clue what makes the difference between adding them one by one and using a for loop?
I also tried a while loop:
_index = 0
while len(self.move_r) < len(self.move_l):
self.move_r.append(pygame.transform.flip(self.move_l[_index], True, False))
_index += 1
This also worked, no memory leak. I'm wondering what the difference is between the two latter solutions - appending one by one and using a while loop - to the for loop (which I thought should even be faster and more efficient than a while loop).
I'll appreciate any hints. The problem for my game is solved (I can either use the while loop or append one by one), but I'm really curious about what could cause such behaviour.
Thanks
Patric
Problem solved! In another portion of the code (not shown here) the image was also added to the self.move_l array, so the source array would continuously growing longer which would result in the leak of memory.
So the for loop, the while loop and the separated addition would all work with the for loop as most efficient according to my measurements.
Related
Problem
Hello, StackOverflow community! I am working on this Lua game, and I was testing to see if it would change the text on my TextLabel to the Bitcoins current worth, I was utterly disappointed when nothing showed up.
I have tried to do research on Google, and my code seems to be just right.
Code
Change = false
updated = false
while Change[true] do --While change = true do
worth = math.random(1,4500) --Pick random number
print('Working!') --Say its working
Updated = true --Change the updated local var.
end --Ending while loop
script.Parent.TextLabel.Text.Text = 'Bitcoin is currently worth: ' .. worth
--Going to the Text, and changing in to a New worth.
while Updated[false] do --While updated = false do
wait(180) --Wait
Change = true --After waits 3 minutes it makes an event trigger
end -- Ending while loop
wait(180) --Wait
Updated = false --Reseting Script.
I expect the output on the Label to be a random number.
I can't really speak to roblox, but there are a couple of obvious problems with your code:
Case
You have confusion between capitalized ("Updated", "Change") and lowercase ("updated", "change" [in commented while statement]), which will fail. See, for example:
bj#bj-lt:~$ lua
Lua 5.2.4 Copyright (C) 1994-2015 Lua.org, PUC-Rio
> Updated = true
> print(Updated)
true
> print(updated)
nil
So be super-careful about what identifiers you capitalize. In general, most programmers leave variables like that in all-lowercase (or sometimes things like camelCase). I suppose there might be some oddball lua runtime out there that is case-insensitive, but I don't know of one.
Type misuse.
Updated is a boolean (a true/false value), so the syntax:
while Change[true] do
...is invalid. See:
> if Updated[true] then
>> print("foo")
>> end
stdin:1: attempt to index global 'Updated' (a boolean value)
stack traceback:
stdin:1: in main chunk
[C]: in ?
Note also that the "While change == true do" is also wrong because of case ("While" is not valid lua, but "while" is).
Lastly:
Lack of threading.
You have basically two different things that you're trying to do at once, namely randomly change the "worth" variable as fast as possible (it's in a loop) and see a set a label to match it (it looks like you probably want it to change constantly). This requires two threads of operation (one to change worth and another to read it and stick it on the label). You've written this like you're assuming you have a spreadsheet or something and that. What your code is actually doing is:
Setting some variables
Updating worth indefinitely, printing 'Working!' a bunch, and...
Never stopping
The rest of the code never runs, because the rest of the code isn't in a background thread (basically the first bit monopolizes the runtime and never yields to everything else).
Lastly, even if the top code was running in the background, you only set the Text label one-time to exactly "Bitcoin is currently worth: 3456" (or some similar number) one time. The way this is written there won't be any updates thereafter (and, if it runs once before the other thread has warmed up, it might not be set to anything useful at all).
My guess is that your runtime is spitting out errors left and right due to the identifier problems and/or is running in a tight infinite loop and never actually getting to the label refresh logic.
BJ Black has given an excellent description of the issues with the syntax, so I'll try to cover the Roblox piece of this. In order for this kind of thing to work properly in a Roblox game, here are some assumptions to double check :
Since we are working with a TextLabel, is it inside a ScreenGui? Or a SurfaceGui?
If it's in a ScreenGui, make sure that ScreenGui is in StarterGui, and is this code in a LocalScript
If it's in a SurfaceGui, make sure that SurfaceGui is adorning a Part and this code
is in a Script
After you checked all those pieces, maybe this is closer to what you were thinking :
-- define the variables we're working with
local textLabel = script.Parent.TextLabel
local worth = 0
-- create an infinite loop
spawn(function()
while true do
--Pick random number
worth = math.random(1,4500)
-- update the text of the label with the new worth
textLabel.Text = string.format("Bitcoin is currently worth: %d", worth)
-- wait for 3 minutes, then loop
wait(180)
end
end)
I removed Updated and Changed because all they were doing was deciding whether or not to change the value. The flow of your loop was:
do nothing and display an undefined number. Wait 3 minutes
update the number, display it, wait 6 minutes
repeat 1 and 2.
So hopefully this is a little clearer and closer to what you were thinking.
Documentation is not helpful to me at all.
First, I tried using set() ,but I don't understand what it means by
set an instance for future calls
I could successfully feed my data using my dataset's structure described below.
So, I am not sure why I need to use set for that as it mentioned.
Here is my feature sequence of type scipy.sparse after I called nonzero() method.
[['66=1', '240=1', '286=1', '347=10', '348=1'],...]
where ... imply, same structure as previous elements
Second problem I encountered is Tagger.probability() and Tagger.marginal().
For Tagger.probability, I used the same input as Tagget.tag(), and I get this follwoing error.
and if my input is just a list instead of list of list. I get the following error.
Traceback (most recent call last):
File "cliner", line 60, in <module>
main()
File "cliner", line 49, in main
train.main()
File "C:\Users\Anak\PycharmProjects\CliNER\code\train.py", line 157, in main
train(training_list, args.model, args.format, args.use_lstm, logfile=args.log, val=val_list, test=test_list)
File "C:\Users\Anak\PycharmProjects\CliNER\code\train.py", line 189, in train
model.train(train_docs, val=val_docs, test=test_docs)
File "C:\Users\Anak\PycharmProjects\CliNER\code\model.py", line 200, in train
test_sents=test_sents, test_labels=test_labels)
File "C:\Users\Anak\PycharmProjects\CliNER\code\model.py", line 231, in train_fit
dev_split=dev_split )
File "C:\Users\Anak\PycharmProjects\CliNER\code\model.py", line 653, in generic_train
test_X=test_X, test_Y=test_Y)
File "C:\Users\Anak\PycharmProjects\CliNER\code\machine_learning\crf.py", line 220, in train
train_pred = predict(model, X) # ANAK
File "C:\Users\Anak\PycharmProjects\CliNER\code\machine_learning\crf.py", line 291, in predict
print(tagger.probability(xseq[0]))
File "pycrfsuite/_pycrfsuite.pyx", line 650, in pycrfsuite._pycrfsuite.Tagger.probability
ValueError: The numbers of items and labels differ: |x| = 12, |y| = 73
For Tagger.marginal(), I can only produce error similar to first error shown of Tagger.probabilit().
Any clue on how to use these 3 methods?? Please give me shorts example of use cases of these 3 methods.
I feel like there must be some example of these 3 methods, but I couldn't find one. Am I looking at the right place. This is the website I am reading documentation from
Additional info: I am using CliNER. in case any of you are familiar with it.
https://python-crfsuite.readthedocs.io/en/latest/pycrfsuite.html
I know this questions is over a year old, but I just had to figure out the same thing as well -- I am also leveraging some of the CliNER framework. For the CliNER specific solution, I forked the repo and rewrote the predict method in the ./code/machine_learning/crf.py file
To obtain the marginal probability, you need to add the following line to the for loop that iterates over the pycrf_instances after yseq is created (see line 196 here)
y_probs = [tagger.marginal(y, ii) for ii, y in enumerate(yseq)]
And then you can return that list of marginal probabilities from the predict method -- you will in turn be required to rewrite additional functions in the to accommodate this change.
This question already has answers here:
Lua for loop reduce i? Weird behavior [duplicate]
(3 answers)
Closed 7 years ago.
im trying this in lua:
for i = 1, 10,1 do
print(i)
i = i+2
end
I would expect the following output:
1,4,7,10
However, it seems like i is getting not affected, so it gives me:
1,2,3,4,5,6,7,8,9,10
Can someone tell my a bit about the background concept and what is the right way to modify the counter variable?
As Colonel Thirty Two said, there is no way to modify a loop variable in Lua. Or rather more to the point, the loop counter in Lua is hidden from you. The variable i in your case is merely a copy of the counter's current value. So changing it does nothing; it will be overwritten by the actual hidden counter every time the loop cycles.
When you write a for loop in Lua, it always means exactly what it says. This is good, since it makes it abundantly clear when you're doing looping over a fixed sequence (whether a count or a set of data) and when you're doing something more complicated.
for is for fixed loops; if you want dynamic looping, you must use a while loop. That way, the reader of the code is aware that looping is not fixed; that it's under your control.
When using a Numeric for loop, you can change the increment by the third value, in your example you set it to 1.
To see what I mean:
for i = 1,10,3 do
print(i)
end
However this isn't always a practical solution, because often times you'll only want to modify the loop variable under specific conditions. When you wish to do this, you can use a while loop (or if you want your code to run at least once, a repeat loop):
local i = 1
while i < 10 do
print(i)
i = i + 1
end
Using a while loop you have full control over the condition, and any variables (be they global or upvalues).
All answers / comments so far only suggested while loops; here's two more ways of working around this problem:
If you always have the same step size, which just isn't 1, you can explicitly give the step size as in for i =start,end,stepdo … end, e.g. for i = 1, 10, 3 do … or for i = 10, 1, -1 do …. If you need varying step sizes, that won't work.
A "problem" with while-loops is that you always have to manually increment your counter and forgetting this in a sub-branch easily leads to infinite loops. I've seen the following pattern a few times:
local diff = 0
for i = 1, n do
i = i+diff
if i > n then break end
-- code here
-- and to change i for the next round, do something like
if some_condition then
diff = diff + 1 -- skip 1 forward
end
end
This way, you cannot forget incrementing i, and you still have the adjusted i available in your code. The deltas are also kept in a separate variable, so scanning this for bugs is relatively easy. (i autoincrements so must work, any assignment to i below the loop body's first line is an error, check whether you are/n't assigning diff, check branches, …)
If you have the befunge program 321&,how would you access the first item (3) without throwing out the second two items?
The instruction \ allows one to switch the first two items, but that doesn't get me any closer to the last one...
The current method I'm using is to use the p command to write the entire stack to the program memory in order to get to the last item. For example,
32110p20p.20g10g#
However, I feel that this isn't as elegant as it could be... There's no technique to pop the first item on the stack as N, pop the Nth item from the stack and push it to the top?
(No is a perfectly acceptable answer)
Not really.
Your code could be shortened to
32110p\.10g#
But if you wanted a more general result, something like the following might work. Below, I am using Befunge as it was meant to be used (at least in my opinion): as a functional programming language with each function getting its own set of rows and columns. Pointers are created using directionals and storing 1's and 0's determine where the function was called. One thing I would point out though is that the stack is not meant for storage in nearly any language. Just write the stack to storage. Note that 987 overflows off a stack of length 10.
v >>>>>>>>>>>12p:10p11pv
1 0 v<<<<<<<<<<<<<<<<<<
v >210gp10g1-10p^
>10g|
>14p010pv
v<<<<<<<<<<<<<<<<<<<<<<<<
v >210g1+g10g1+10p^
>10g11g-|
v g21g41<
v _ v
>98765432102^>. 2^>.#
The above code writes up to and including the n-1th item on the stack to 'memory', writes the nth item somewhere else, reads the 'memory', then pushes the nth item onto the stack.
The function is called twice by the bottom line of this program.
I propose a simpler solution:
013p 321 01g #
☺
It "stores" 3 in the program at position ☺ (0, 1) (013p), removing it from the stack, and then puts things on the stack, and gets back ☺ on top of the stack (01g). The # ensures that the programs finishes.
require "alien"
--the address im trying to edit in the Mahjong game on Win7
local SCOREREF = 0x0744D554
--this should give me full access to the process
local ACCESS = 0x001F0FFF
--this is my process ID for my open window of Mahjong
local PID = 1136
--function to open proc
local op = alien.Kernel32.OpenProcess
op:types{ ret = "pointer", abi = "stdcall"; "int", "int", "int"}
--function to write to proc mem
local wm = alien.Kernel32.WriteProcessMemory
wm:types{ ret = "long", abi = "stdcall"; "pointer", "pointer", "pointer", "long", "pointer" }
local pRef = op(ACCESS, true, PID)
local buf = alien.buffer("99")
-- ptr,uint32,byte arr (no idea what to make this),int, ptr
print( wm( pRef, SCOREREF, buf, 4, nil))
--prints 1 if success, 0 if failed
So that is my code. I am not even sure if I have the types set correctly.
I am completely lost and need some guidance. I really wish there was more online help/documentation for alien, it confuses my poor brain.
What utterly baffles me is that it WriteProcessMemory will sometimes complete successfully (though it does nothing at all, to my knowledge) and will also sometimes fail to complete successfully. As I've stated, my brain hurts.
Any help appreciated.
It looks like your buffer contains only 2 bytes ("99"), but you specify 4 bytes in the call to WriteProcessMemory.
If your intention was to write the 32-bit value 99 into memory (as a number, not an ASCII string), you can use:
alien.buffer("\99\0\0\0")
You can convert arbitrary integers to string representations using alien.struct.pack:
require "alien.struct"
s = alien.struct.pack('i', 99)
buf = alien.buffer(s)
I know this question is long forgotten, but I ran into the same issue (with the same function), and there was nothing on the web except this question, and then I solved it myself, so I'm leaving my solution here.
SHORT ANSWER
The type of the second argument of WriteProcessMemory is not "pointer". I mean, officially it is, but alien cannot cast a raw address to a "pointer", so you are better off pretending it's a "long" instead. So your types declaration should look like
wm:types{ ret = "long", abi = "stdcall"; "pointer", "long", "pointer", "long", "pointer" }
LONG ANSWER
I was playing around with ReadProcessMemory, since I figured that before writing something you need to verify that this something actually exists. So one time I called ReadProcessMemory, and it returned a buffer that wasn't what I was looking for, but it wasn't empty either. In fact, it seemed something was written there - as in, an ASCII string. Not text, though, just some digits. But that was enough to convince me that the data actually came from somewhere.
So I grabbed Cheat Engine, opened the same process and ran a search for this string. And guess what - it actually was there, but the address was completely wrong. That led me to believe that the address is specified wrongly. After trying to find a way to generate a "pointer" object from a Lua number, I gave up and changed the types declaration - after all, a pointer is just a differently interpreted integer.
After all that, I did some investigating, including reading the sources of both lua and alien, and stepping through the relevant parts with a debugger. It turns out, the full walkthrough of the error is as follows:
The "pointer" keyword has special behaviour for strings: if your "pointer"-declared argument is actually a Lua string, then a new buffer is instantly created, the string is copied there, and it is used as the real argument.
Alien uses the lua_isstring function to implement this
lua_isstring returns "true" not only for actual strings, but for numbers as well, since they are auto-convertible into strings.
As a result, your SCOREREF is turned into a string, copied into a newly created buffer, and the address of THAT is passed into WriteProcessMemory as a void*.
Since the layouts of most processes in their respective address spaces are similar, this void* more often than not happens to coincide with an address of some thing or another in the target process. That is why the system call sometimes succeedes, it just writes into a completely wrong place.