clipka <ano### [at] anonymousorg> wrote:
> Am 11.09.2016 um 22:06 schrieb LanuHum:
> > We continue to
> > https://github.com/Lanuhum/Blender-C-
> > Seeking a memory leak.
>
> The name of the repo is poorly chosen: Pasting the corresponding link
> into plain text such as a mail, software that auto-detects links in
> plain text may think the trailing `-` isn't part of the link (this is
> quite obviously the case with Thunderbird).
>
> I would recommend renaming the repo to, e.g., "Blender-Cpp".
>

I gave the name of the repository blender-C++
I did not know that github does not understand plus plus
Plus, plus, he was replaced by minus.
I tried renaming, but the button "Rename" is not active. :(
:)
> > If you decide the problem - I will continue. I'll connect povray with blender.
> > :)))
>
> You're not very familiar with C++, are you?
>
> One property of C++ is that there is no garbage collection in the
> language itself, and you'll have to actively release all memory you
> allocate. Thus, in the main() function,
>
>     int main(int argc,char *argv[]){
>         FXApp application("foxray",FXString::null);
>         application.init(argc,argv);
>         new ImageWindow(&application);
>         application.create();
>         return application.run();
>     }
>
> the `new ImageWindow(&application);` will allocate memory for, and
> create, an object of type `ImageWindow`, but makes no provision to
> remember the address of the memory allocated, so there is no way to
> release the memory later.
>
> You probably want to do something like this:
>
>     ImageWindow myWindow = new ImageWindow(...);
>     ...
>     delete myWindow;
>
> One memory leak eliminated. I'll have a look whether I can find some more.

Thank you. Yes, I'm just learning. If I close the app - the memory is freed.
Memory takes each successive press of a button.
Button believes the number of vertices.
Memory: 1760
Start app. Memory: 1760
vertices number = 983042
Press button "Render" . Memory: 2380
Press button "Render" . Memory: 2750
Press button "Render" . Memory: 3100
Press button "Render" . Memory: 3470
What you need to be reset. Which variable is stored. I see no reason.

Post a reply to this message

"LanuHum" <Lan### [at] yandexru> wrote:
> I started to learn programming language C ++.
> To transfer data from Blender in Povray, we use files
> My idea: to give up files.
>
> How will it work?
>
> #include <iostream>
> #include <string>
> #include <Python.h>
> #include <fx.h>
>
> [...]
> I want to ask: I can anyone help tips?


RNA being the data architecture in Blender:
https://wiki.blender.org/index.php/Dev:2.5/Source/Architecture/RNA

Blender does have a C++ RNA API exposing all the program data.
It is used by the Cycles rendering engine, which uses Python only for it's
graphical user interface.

Are you using the python version of this API instead?
So, maybe a faster version of what you're trying to achieve already exists, and
what would need developing would rather be the POV-Ray module.

This module would just use the existing API from a running Blender session
acting as a mere library to read the data.

Despite the "poor but improving" modularity of POV, Clipka,
would some kind of root to grow this module on, already exist in the shape of
POV-Ray's "GUI-Extension API"?


As much as I was also advised not to go there in the immediate future, with my
currently *inexistant* C programming skills, Probably Lanuhum is actually able
to get somewhere faster, even as a first C project, given his motivation and
fast learning skills.

Reading the following discussion,
http://news.povray.org/povray.beta-test/thread/%3C461768ac%241@news.povray.org%3E/
.... Hugo , who has long been the main user of this GUI-extension with Bishop 3D
might welcome some feedback?

It might be beneficial to several communities if the updating of POV-Ray's
GUI-Extension API could then be used as the foundation to create the said
module... Do you think it could?

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 11.09.2016 um 22:06 schrieb LanuHum:
>
> > https://github.com/Lanuhum/Blender-C-
>
> Some more comments:
>
>
> All the PyObject* items in py2c.cpp:
>
> First of all, you're using global variables, which you shouldn't use in
> C++ programs. You should wrap all the stuff in py2c.cpp into a class.
>
> Then, every time you set them to some value returned by PyWhatThe_Foo(),
> you're receiving a pointer to data residing... well, /somewhere/. Nobody
> knows. And, more importantly, given that it is /probably/ dynamically
> allocated, nobody knows who is responsible for /releasing/ the memory.
> And /how/ to release it. The <Python.h> functions may be striaghtforward
> C code, in which case you need to release the stuff using `free()`. Or
> it may be C++ code, in which case you need to release it using
> `delete[]` (most certainly not `delete`; subtle but important difference
> there). Or <Python.h> may provide a dedicated function to dispose of it.
> Obviously you're not really sure or aware of this issue either, because
> you never invoke any of these mechanisms.
>
> There is some code at the end of parse_blend() that /looks/ like it was
> intended to do the trick, but you commented it out. Worse yet, it
> wouldn't even be sufficient.
>
> *Every* time you assign something to one of these variables (and also
> when the program exits), the previous content gets lost, and the memory
> it pointed to remains in limbo: Your memory holes are legion.
>
> What you (presumably) need to to is call PyDECREF() *every* time before
> you *overwrite* one of those PyObject* variables.
>
>
> You may want to have a look at boost.python, which seems to encapsulate
> the Python API a bit better for use in C++, most notably allowing the
> use of smart pointers rather than classic C pointers. Smart pointers
> automatically release the data they point to when you assign a new value
> to the smart pointer, or even when the variable goes out of scope.
> (They're even smart enough to /not/ release data if another copy of the
> smart pointer still refers to the data.)
>
>
> PyName_AsName():
>
> Same problem as above, but even worse: You need to pass the data out of
> the function, so you can't just call PyDECRREF() on the data (if that's
> even the proper way of releasing char* data returned by the Python API).
> I would recopmmend constructing a std::string from it (creating a copy
> of its contents), and call the adequate memory release function
> immediately. You can then return the std::string, which will save the
> caller from the task of pointer handling.
>
>
> parse_verts():
>
> You're using a vector<double> to store three coordinates. This is
> inefficient: vector<> is designed to store dynamic arrays, /not/ what
> mathematicians would call a vector. Instead, simply use:
>
>     double coord[3];
>
> You can leave the remainder of the function entirely unchanged.
>
>
> parse_faces():
>
> Same deal as above for the `face` variable.
>
>
> ImageWindow:
>
> Here you're solving the global variables the right way: By making it a
> class, and working with an instance of it. /But/ you're falling short:
> Your constructor constructs an assload of data using `new`, but the
> destructor only releases three of those fields using `delete`. Also, for
> some of the stuff you're creating I wonder whether you're ever properly
> hooking it up to other stuff. Maybe it's a quirk of <fx.h>, but to me
> every "new" without an assignment to its left-hand side (or something
> else that stores its result value) reeks of a serious coding error.
>
>
> ImageWindow::onCmdRender():
>
> Beware that clock_gettime is /not/ portable.
>
>
> Well, I guess that should suffice for starters. I shall warn you though:
> I suspect you'll still have a looooooong way ahead of you, and I won't
> be able to provide this type of support on a regular basis.



Thank you so much! This is very useful information.

I will not always stupid! :))))

Once I was afraid python, now I'm not afraid of him.

I will learn and will help you.



>
> I don't mean to discourage you, but seriously: Do you /really/ feel up
> to this challenge you have given yourself? This is supposed to evolve
> into an interface between Blender and POV-Ray's render engine, right?

Yes. I would like to make an elephant out of a fly.
Now the data transfer takes a very long time. Write file, parse file...
I want to get rid of it.

Post a reply to this message

"Mr" <nomail@nomail> wrote:
> "LanuHum" <Lan### [at] yandexru> wrote:
> > I started to learn programming language C ++.
> > To transfer data from Blender in Povray, we use files
> > My idea: to give up files.
> >
> > How will it work?
> >
> > #include <iostream>
> > #include <string>
> > #include <Python.h>
> > #include <fx.h>
> >
> > [...]
> > I want to ask: I can anyone help tips?
>
>
> RNA being the data architecture in Blender:
> https://wiki.blender.org/index.php/Dev:2.5/Source/Architecture/RNA
>
> Blender does have a C++ RNA API exposing all the program data.
> It is used by the Cycles rendering engine, which uses Python only for it's
> graphical user interface.
>
> Are you using the python version of this API instead?
> So, maybe a faster version of what you're trying to achieve already exists, and
> what would need developing would rather be the POV-Ray module.
>
> This module would just use the existing API from a running Blender session
> acting as a mere library to read the data.
>
> Despite the "poor but improving" modularity of POV, Clipka,
> would some kind of root to grow this module on, already exist in the shape of
> POV-Ray's "GUI-Extension API"?
>
>
> As much as I was also advised not to go there in the immediate future, with my
> currently *inexistant* C programming skills, Probably Lanuhum is actually able
> to get somewhere faster, even as a first C project, given his motivation and
> fast learning skills.
>
> Reading the following discussion,
> http://news.povray.org/povray.beta-test/thread/%3C461768ac%241@news.povray.org%3E/
> .... Hugo , who has long been the main user of this GUI-extension with Bishop 3D
> might welcome some feedback?
>
> It might be beneficial to several communities if the updating of POV-Ray's
> GUI-Extension API could then be used as the foundation to create the said
> module... Do you think it could?

> > How will it work?

I do not want and I can not study the blender code. Blender always unstable, and
I do not have the knowledge to understand the code hundred meters. Blender can
not create a GUI, and how to create a Python module. This allows cmake. I get
bpy.so library. I can work without running the blender with this library, Using
any development environment that supports python or any text editor. But I can
also run the script using C++. C++ runs a script, the script calls the bpy.so
module and transmits the data in C++. My GUI (fx.h) causes Povray and sends data
to it. Povray requires a patch, which will need to write.
:)))

Post a reply to this message

Am 12.09.2016 um 16:04 schrieb LanuHum:

>> One memory leak eliminated. I'll have a look whether I can find some more.
> 
> Thank you. Yes, I'm just learning. If I close the app - the memory is freed.

When an application closes, the operating system always reclaims all of
the allocated memory, by force so to speak.

> Memory takes each successive press of a button.
> Button believes the number of vertices.
> Memory: 1760
> Start app. Memory: 1760
> vertices number = 983042
> Press button "Render" . Memory: 2380
> Press button "Render" . Memory: 2750
> Press button "Render" . Memory: 3100
> Press button "Render" . Memory: 3470
> What you need to be reset. Which variable is stored. I see no reason.

I've seen plenty ;)

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 12.09.2016 um 16:04 schrieb LanuHum:
>
> >> One memory leak eliminated. I'll have a look whether I can find some more.
> >
> > Thank you. Yes, I'm just learning. If I close the app - the memory is freed.
>
> When an application closes, the operating system always reclaims all of
> the allocated memory, by force so to speak.
>
> > Memory takes each successive press of a button.
> > Button believes the number of vertices.
> > Memory: 1760
> > Start app. Memory: 1760
> > vertices number = 983042
> > Press button "Render" . Memory: 2380
> > Press button "Render" . Memory: 2750
> > Press button "Render" . Memory: 3100
> > Press button "Render" . Memory: 3470
> > What you need to be reset. Which variable is stored. I see no reason.
>
> I've seen plenty ;)

We will look for errors. :))))

Post a reply to this message

Am 12.09.2016 um 16:20 schrieb Mr:

> Despite the "poor but improving" modularity of POV, Clipka,

Hah! Just recently I've managed to cut off last appendages by which the
VFE had invaded the render engine modules; so there's actually a silver
lining at the horizon.


> would some kind of root to grow this module on, already exist in the shape of
> POV-Ray's "GUI-Extension API"?

I must confess that I have no idea. IIRC the whole GUI-Extension thing
is specific to POV-Ray for Windows, and I've never had a close look at
it. My naive assumption would be that it is just the other way around:
An interface to plug stuff into POV-Ray, not to plug POV-Ray into stuff.

I think I recall that some modelers were written as a GUI extension and
were somehow able to start renders and such; but I'm 99% sure the data
transfer always used .pov files.


> Reading the following discussion,
> http://news.povray.org/povray.beta-test/thread/%3C461768ac%241@news.povray.org%3E/
> ..... Hugo , who has long been the main user of this GUI-extension with Bishop 3D
> might welcome some feedback?

The request for feedback had been directed at Chris; I have no idea what
became of it. But today, the feedback would presumably be "Here, be
invited to look at the code at GitHub, and see what you can do with it."

Post a reply to this message

"LanuHum" <Lan### [at] yandexru> wrote:
>
> We will look for errors. :))))

:(
If I uncommented Py_Finalize(), application crash when the command Py_Finalize()
run. If I do not use the import of bpy, the application lives

https://docs.python.org/3.5/c-api/init.html

Bugs and caveats: The destruction of modules and objects in modules is done in
random order; this may cause destructors (__del__() methods) to fail when they
depend on other objects (even functions) or modules. Dynamically loaded
extension modules loaded by Python are not unloaded. Small amounts of memory
allocated by the Python interpreter may not be freed (if you find a leak, please
report it). Memory tied up in circular references between objects is not freed.
Some memory allocated by extension modules may not be freed. Some extensions may
not work properly if their initialization routine is called more than once; this
can happen if an application calls Py_Initialize() and Py_Finalize() more than
once.

Post a reply to this message

Am 12.09.2016 um 22:13 schrieb LanuHum:
> "LanuHum" <Lan### [at] yandexru> wrote:
>>
>> We will look for errors. :))))
> 
> :(
> If I uncommented Py_Finalize(), application crash when the command Py_Finalize()
> run. If I do not use the import of bpy, the application lives

Have you finished your other homework yet?

I wouldn't be surprised if unreleased stuff allocated by Py_Whatever()
might cause crashes upon calling PyFinalize().

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 12.09.2016 um 22:13 schrieb LanuHum:
> > "LanuHum" <Lan### [at] yandexru> wrote:
> >>
> >> We will look for errors. :))))
> >
> > :(
> > If I uncommented Py_Finalize(), application crash when the command Py_Finalize()
> > run. If I do not use the import of bpy, the application lives
>
> Have you finished your other homework yet?
>

No. To learn your lesson, I started from scratch. I started all over again.
I wrote a single function.
The function must import the module, clean it and write "Hello World".

#include <python3.3m/Python.h>
#include <iostream>

int main() {
    Py_Initialize();
    PyRun_SimpleString("import sys");
    PyRun_SimpleString("sys.path.append(\".\")");
    PyObject *pyModuleName = PyUnicode_FromString("bimport");
    PyObject *pyModule = PyImport_Import(pyModuleName);
    Py_DECREF(pyModuleName);
    Py_DECREF(pyModule);
    Py_Finalize();
    std::cout<<"Hello world!";
    return 0;
}

The "bimport" module is only one row : import bpy

make and run.

Konsole wrote:

Blender quit
------------------
(program exited with code: 0)
Press return to continue...

Where is the "Hello World"?

I can rearrange some places line:

    Py_DECREF(pyModule);
    Py_DECREF(pyModuleName);

same result.

There is also need classes? In my opinion, it is a bug, and need a new idea.

Post a reply to this message