Release [Rebirth Comp] PandaFE

[Sigma]

Thank you for the update, I'll move the files but there are a lot op them, Maybe just renaming the search path will be enough.. I hope then I can copy the pnd files from the renamed dir. to a new directory and maybe can find the cause of the problems, I have a lot of PXML files on it because I compiled some apps and made pnd files of them, I keep a backup of the original directories on this card and therefor there are other PXML files on it.


Will post the results when I have them.


grtz.

 

[skeezix]

lindpnd structs have never changed, beyond adding memebrs to the 'end'; ie: if your'e assujming struct size, and packing them in an array, it could possible be a problem; however, libpnd includes alloc/dealloc type functions for such purposes, as well as lists, so shoudlnt' be a problem.


There've been a couple parallel libpnds where other people have pulled it, changed it and used their version, then submitted patches upstream, and I've rearranged their patches so as struct changes go to the end; but if you used someone elses interim libpnd, it could have run into member location changes.


Or perhaps something slipped through the fcracks.. I'm pretty anal about such things, but if a member got injected into the middle, please let me know which so I can examine the history.


(Also note, you might want to use struct member getter functions to avoid a problem in the future, though I agree, they're cumbersome and I tend not to use them either


So let me know more information (I just popped into thread, will go read..), so I can fix up any problems or we can find the source troublemaker


jeff


Hmm, taking a look at current.. I notice package_ stuff is at the end:


88 char *package_version_major;


89 char *package_version_minor;


90 char *package_version_release;


91 char *package_version_build;


But up at the top, package-id got injected:


61 char *package_id;


If thats a new one, that coudl be a problem shuffling the whole struct down a few bytes; is that the one? I'll have to check back and figure out what to do if so .. bump it to the end and risk breaking others, but being 'correct'...


I wonder if this was the patch in question:


http://git.openpando...b79d1c20090ecbb


If thats the culprit, twas back in May. Do I bump the package_id to bottom, risking a few apps, or just leave it at this point?

The libpnd change that bit me was most certainly this one: http://git.openpando...5966aba3607374b


I don't think though that the problem I ran into necessarily represents a problem in libpnd, but rather just my vala vapi binding (vala<->c-header bridge) for pnd_discovery.h being out of date after the change, and also probably a poor vapi design on my part.


Because of the way my binding is designed (struct members are explicitly repeated, with char* mapped to string, and uint mapped to explicit flags definition, etc), I think I ended up with mismatched pointer sizes in the pandora-glib wrapper vs libpnd.


I may be able to fix this by not explicitly defining each member in the vapi file, and/or by treating pnd_disco_t on the vala side as a class rather than a struct. The trick is that the size of a pnd_disco_t instance is defined at compile time rather than runtime, and so my wrapper library might have a hard time supporting multiple versions of libpnd and still be able to work with instances of pnd_disco_t.


I agree that using member getter functions would be more ideal in my situation, though I don't see any specifically for pnd_disco_t members. Do you mean I might should use the pnd_pxml_get_* methods? This might work, though then I'd have to essentially reimplement pnd_disco_search and call pnd_pxml_fetch myself for each pnd.


So ideally I guess I would like to see maybe one or both of the following added to libpnd:

• pnd_disco_get_* methods in pnd_discovery.h for each pnd_disco_t member, taking a void* handle/reference as input. Perhaps define pnd_disco_handle, as with pxml, just as long as this is really void*.
  
• pnd_disco_search variant that returns a list of pnd_pxml_handle instances, rather than a list of pnd_disco_t instances.
  

In any case, I will try and look for a good solution on my side that involves no libpnd changes.


Thanks for taking the time to consider and discuss this!

Adding; adding members to the 'end' should be fine ..if its not, its some problem with the way the bindings are done. (ie: Things change over time, thats usually 'how its done', so shoudl be managable.) A common problem is assumnign structy size and making an array of them, and then copying struct over and losing the new bits.. that sort of thing. But if you can use the struct pointer as given, ignoring extra bits, you should be okay.


(The one I referred to was a injected member 'at the front' which bumps the others down, so a naive binding would totally blow up.)


We could add accessor (get/setters) for disco-t if they're missing if it helps (no big deal to add), but if theres anythign you can do on your hand, let me know. Can you PM me? April is a crazy busy month for me so I'm not tracking the forum as often as usual, but a PM will email me a notification I'll help you wherever I can


jeff

 

[Sigma]

Nuhrin I've traced the item that created the problem, I have a lot of Pnd files in the directory menu but


"panplayer.pnd" is causing the crash, It a rather big pnd file but maybe the structure of the pnd file or PXML


is causing this. maybe now you can trigger the crash on your pandora if you download the panplayer.pnd.

 

[nuhrin]

Nuhrin I've traced the item that created the problem, I have a lot of Pnd files in the directory menu but


"panplayer.pnd" is causing the crash, It a rather big pnd file but maybe the structure of the pnd file or PXML


is causing this. maybe now you can trigger the crash on your pandora if you download the panplayer.pnd.

Nicely done!


I downloaded panplayer.pnd from http://repo.openpandora.org/?page=detail&app=PanPlayer, placed into pandora/menu/, removed appdata/pandafe, and...it worked just fine. :huh:


Do you have an older/different version of panplayer.pnd, or an applicable ovr file maybe?

 

[Sigma]

I think I use the latest version but perhaps not I have to look into that.


I now can test your app and see if I can use/configure all the emulators.

 

[nuhrin]

Thanks again for all your testing and feedback Sigma.


I have a new child on the way (any day now), so I will probably end up going dark for a few weeks pretty soon. But if you have more feedback, suggestions, bug reports, etc after having (finally) gotten to try it out, please do go ahead and post it. I will hopefully have a chance to hack on this here and there during my time off from work.


For anyone interested in the promised source code: I intend to put that together before proceeding with any further development, but it will probably be a couple weeks before I will be able to get that together.