Programming PW2 using Go language

[knc1]

Originally Posted by rupor

@knc1

I looked at linaro before building my own - 2 points here. First it is 32 bits hosted and I wanted 64 bits (call me nut). Second - I build softfp, not "soft float". It is not the same as ARMel - are you trying to confuse matters on purpose?

All you have to do is open the spoiler.
The differences in configuration are clear, there should be no confusion introduced.

[knc1]

Originally Posted by NiLuJe

Just one Q: since you appear to be building against the lab126 kernel, did you have to mangle it in any way to get it to behave? I haven't done this in a long time (I usually fall back on the nearest long-term kernel release), but some of them needed some tinkering to behave nicely as a kernel header 'provider' .

- - - - -

I think that still requires the external "nads" module.

I.E: You need go-nads to interface directly with the lab126 kernel headers.

[rupor]

Bumping this thread a bit....

I posted go program (see first message) which may serve as an example, but is fully functional (or so I hope). It has functionality similar to some of barsanuphe's LibrarianSync but without its dependencies. It does not require python and runs without KUAL (see readme, basically I am using /etc/lipc-daemon-events.conf to run it after every fullscan).

Hopefully somebody may find this useful.

[eureka]

Originally Posted by rupor

basically I am using /etc/lipc-daemon-events.conf to run it after every fullscan

JFYI: you can avoid editing /etc/lipc-daemon-events.conf by using lipc-wait-event program provided by stock firmware (lipc-wait-event -h is suffuciently helpful). Search for lipc-wait-event in this subforum also brings useful information.

Or use underlying library directly: Openlipc (though, unfortunately, that project misses event subscribing function prototype). Or instead of reverse-engeneering liblipc.so, yo can link to Lua and use Kindle_Touch_Hacking#LIPC_Lua_bindings.

[rupor]

@eureka

Thank you for the info!

I have seen lipc-wait-event - it is quite useful in a script, but than something has to start this script and keep it running The same I think is true for linking with liblipc.so - my program has to be running and than it could register a handler and listen for the event (I will have to use upstart I think - unless there is a way to ask lipc to take care of my program lifetime). By editing a single line of /etc/lipc-daemon-events.conf I could easily avoid all of that, reduce memory footprint and simplify my code, so usage of lipc-daemon this time was intentional.

[kaznelson]

The KAL extension for KUAL:
- to unpack archive kal_0.1.tar.gz in a folder /extensions;
- to unpack archive kual_kal_0.1.zip in a folder /extensions;
- use new menu "Collections from folders".

[rupor]

Thank's for your help - we could even combine this with the next dump for the time being, however my idea would be to have device, which does not have kual installed Despite its great utility it is difficult to explain to 80 year old what kual is and does, so I really would like to have something which simply runs and is not really visible to the user... Not sure that I will be able to achieve this, but (time permitting) will try.

I updated my package (I think I found some problems with error processing)

[rupor]

Added proper install and uninstall .bin (based on NiLuJe's code). Package now includes KUAL extension (useful if something goes wrong).