List of AndroWish Bugs '''11 Jan 2014''' The "Metropolis" edition: package require Thread cannot find symbol "Tclthread_Init": Symbol not found: load_library[[1109]]: Library 'libtclthread.so' not found Fixed starting with the ''"James Joyce"'' edition '''2014-01-13'''. ---- jima 2014-01-13 According to a report from rmax in the Tcler's Chat: ====== wm overrideredirect . 1 ====== kills AndroWish. [chw] 2014-01-14 confirmed for all versions of AndroWish. "adb logcat" reports a SIGSEGV in the X11 emulation code for XDestroyWindow. This bug will be fixed soon, hopefully. ---- [MG] Not sure if it's a bug (my experience with Android devices is limited to 0, and so far I've only played in the SDK's emulator), but info nameofexecutable returns an empty string - assuming it's possible to [exec] an APK to run it, it would be handy if it returned a path (or whatever is needed for said [exec]ing) instead. [chw] 2014-01-14 wouldn't call this a bug. Process (application) startup on Android is quite different from traditional UN*Xen. It is not possible to start an APK by means of exec(2) or exec(n). However from within AndroWish it is of course possible to use exec(n) to spawn a normal UN*X process (e.g. "ps"). When you need information about AndroWish's execution environment there's hopefully everything available in the "env" array: env(EXTERNAL_FILES) app specific directory on external storage env(EXTERNAL_STORAGE) path name of external storage (could be internal SD card) env(EXTERNAL_STORAGE2) path name of external storage (real external SD card) env(HOME) app's home directory (internal storage) env(INTERNAL_STORAGE) app specific directory on internal storage (identical with $env(HOME)) env(LANG) system language env(LD_LIBRARY_PATH) load path for shared libraries including app specific directory env(OBB_DIR) on some Android versions extra stuff bundled with the app env(PACKAGE_CODE_PATH) path name of the app's APK env(PACKAGE_NAME) package name where the app's main class comes from env(PATH) path for exec(n) including app specific directory env(TMPDIR) path name for temporary files For the structure of an APK please see http://en.wikipedia.org/wiki/APK_(file_format) The "assets" directory from the APK is "mounted" on application startup using the built-in virtual ZIP file system of the Tcl shared library. This is where all Tcl library code (and possibly your application Tcl code) has been bundled at build time (e.g. /assets/tcl8.6, /assets/tcllib1.5 etc.) The entire APK is mmap(2)'ed on application startup, thus the cost for accessing the files under "/assets" is decompression time only. Parts of the APKs "lib" directory (mostly architecture specific shared libraries) are copied to internal device storage at installation time of the APK. That is the reason, why all extension shared libraries are kept below "lib" and not "assets". ---- [MG] just noticed a couple of things: 1. tcl_platform(pathSeparator) is set to ":" not "/" 1. Running the latest AndroWish on the official Android SDK emulator, the cursor keys aren't working (no binding fires for them at all). Not sure whether the problem lies with AndroWish or the emulator, though. Other than that, everything seems to be working perfectly so far. Thanks for all your time and effort on it. ---- [RS] pathSeparator is correct on Unixes with ":". The question is how elements of $env(PATH) are separated, C:\bin;D:\bin or /bin:/usr/bin:/usr/local/bin [MG] D'oh, my mistake - confused it with [file separator]. Thanks, Richard. ---- [ramsan]: these two commands give me problems: package require img::png package require treectrl ---- [mh2] 26.01.2014, when I run a big tcl program (impress.tcl from [http://www.ntlug.org/~ccox/impress/Download.html] sligtly modified for tk8.4), on my cheap tablet with 256MB RAM and android 2.3.3, than: 1. with androwish 8.4, impress.tcl works perfectly 1. with androwish 8.6, impress.tcl crash (android's oom killer kills it or something else?) is androwish 8.6 much more memory hungry than 8.4 ??? if it is so, than may be 8.4 line of androwish should be continued ??? [chw] 2014-01-26 turned out to be a SIGSEGV in the Xlib emulation, please refetch the "''Leningrad''" edition, should work now. ---- '''[ES] - 2014-02-09 12:19:44''' Wow, fantastic response - confirm that "Jules Verne" fixes the Bluetooth bug under Android 4.0.3. Thanks! ---- [MG] I just built the HelloTclTk example app on Windows using Eclipse from the Android SDK, but the resulting file fails to load, saying it can't find libSDL2.so - full log at http://pastebin.com/LRsWg3v0 . I haven't gotten around to firing up a Linux VM to try the other buildtools yet. [chw] pretty sure your build environment is not the culprit. Where on your device is libSDL2.so located when you install the latest AndroWish-debug.apk? That's most likely the problem. Unfortunately, the HelloTclTk Java code has /data/data/lib/tk.tcl.wish/lib hard coded as the path where it expects the AndroWish native runtime. And this takes places in a static initializer where no full Android application context is established. [chw] 2014-02-11 16:10+0000: please refetch the ZIP and the APK files. I hope it is fixed now. ---- [GCS] 2014-02-15 Galileo Galilei has a problem with the new SQLite3: ====== package require sqlite3 attempt to provide package sqlite3 3.8.3 failed: package sqlite3 3.8.3.1 provided instead ====== The trivial workaround in a script is to use [catch], but thought this should be reported. ''Eppur si muove!'' [chw] 2014-02-15 18:58+0000: thanks, should be fixed now. ---- [GCS] 2014-02-22 The Heinrich Hertz files do not seem to be on the server [chw] 2014-02-22 15:39:47+0000: should be fixed now. ---- Uli 2014-03-02 13:57 Androwish containing Tk8.6 crashes when you type in ''lower .'' ! Androwish containing Tk8.4 is ok! [chw] confirmed for all my devices. Bug must have been invented in the 8.6 port. Fixed in ''Pioneer 10'' edition as of 2014-03-03. ---- NN 2014-03-07 (Pioneer 10): accelerator values seem to be wrong reported by virtual event <> %s is 1 or 2 or 3 (axis) -> ok, but values are e.g. 200, 32000, 212. I would expect e.g. 0.2, 9.8, 0.3 [chw] 2014-03-07: not a bug, see updated [AndroWish: Documentation]. In the SDL library the accelerometer is handled like a joystick with 3 axes. The values are reported as signed shorts {-32768...+32767}. ---- '''[Superlinux] - 2014-03-08 18:18:08''' command [checkbutton] exits. command [ttk::checkbutton] does not exist. On the desktop, latest ActiveTcl this command exists. ---- '''[JM] - 2014-03-15''' Looks like extension .tcl is always added to the file selection dialog from the console's menu File>>>Source. For example, I was trying to source a script named "blt", and I am always getting the error message saying that "blt.tcl" does not exist, while the name is just "blt" without any extension. Of course, you can source it from the console but I should be able to source a file without extension with the dialog... [chw] 2014-03-16: yes, that is a misfeature (or even bug?) of the file selection dialog on all UN*Xen including Android. I'll try to fix that in a later edition of AndroWish, however IMO you should file that bug report for Tk in general. [JM] It was really a very minor thing, but now, with the "The Dark Side of the Moon" edition, I cannot see any file to source with the fileSelection dialog...I see the directories, and the file that I want to source is there of course, it is just that is not listed anymore... I am very happy with the Icon though ;) [chw] 2014-03-25: oooooops! I've messed the file selection up. Will fix it soon. And again [JM] thank you for the Icon. ---- '''[Superlinux] - 2014-04-01 09:09:54''' I had a crash of AndroWish ("The Dark Side of the Moon" edition, 2014-03-24) when I installed it on Android-x86 4.4 RC1. [http://sourceforge.net/projects/android-x86/files/Release%204.4/android-x86-4.4-RC1.iso/download%|%get it here]. Crash report here: [http://paste.tclers.tk/3115%|%open report here] ---- '''[PWE] - 2014-05-12''' I tried to run the tkgamepack.kit on android, and got errors. A closer look at the problem showed that a "package require Tk" in a slave interpreter causes an error in androwish. Other tclkit programs and wish do not give an error. set s slave interp create $s $s eval { package require Tk } '''[chw] - 2014-05-12''' There's a similar entry in [AndroWish Questions]. The reason is the missing pkgIndex.tcl file in the /assets/sdl2tk8.6 folder (grrrr, took months to find this out :-(. This will be fixed in the next edition of [AndroWish]. '''[escargo]''' - Does this mean that the reporting of the error was not sufficiently specific enough for you to be able to tell what the true underlying error was? If so, does that constitute a bug in the error reporting? (I would think so. I really hate the loss of information that happens in some software where a specific error is encountered but only a vague error message results.) '''[chw]''' - No problem with the reporting. My problem is that I've stumbled over this months ago but missed the missing pkgIndex file and had the wrong impression that it could be related to the VFS mount of the /assets folder of the Android APK. ---- '''[OxFEEDBACC] - 2014-05-18 10:46:51''' On my Motorola Moto G (physical display size 1280x720), AndroWish's display (I think I've read it uses some sort of X server?) seems to think it is bigger than it actually is. As far as I can evaluate, this is not a bug of AndroWish, however. [borg displaymetrics] properly reports 1186x720 or 720x1184 (plus soft buttons, each). The point seems to be that the Moto G's display is classified as MDPI with only 526x320 pixels resolution; so obviously the X server examines the display size by the display's getRealMetrics() method, but later on only the classified display resolution as returned by getMetrics() is used (compare the screenshot). The fix I finally found, after some days of fighting with this issue, was to acquire a bitmap with the real metrics, associate it to a custom view component, and draw the bitmap in this component's onDraw handler. (full resolution image http://arno-nuehm.square7.ch/and/andforms.png%|%here%|%) [http://arno-nuehm.square7.ch/and/andforms_scaled.png] '''[chw] - 2014-05-18''' Trying to catch your findings (without a device with similar behavior) what is needed to get things proper? Would that help in ''AndroidManifest.xml'': ====== ====== And BTW did you succeed in rebuilding [AndroWish] from sources? '''[OxFEEDBACC] - 2014-05-19''' well no... i just downloaded the AndroWish sources, and read that the NDK is required --- I think I can do without those steps. Thanks anyway BTW, since changing the ''AndroidManifest.xml'' would require recompilation, I don't know if that would help. BTW 2, while trying out how to include screen shots (still didn't figure how to properly scale them (and yes, I've looked at [http://wiki.tcl.tk/14%|%pg. 14%|%])), i forgot those of AndroWish, as it shows up on the Moto G. (Maybe I just got the wrong figure and everything is as expected? But can't be... I can't even reach the scrollbar without moving the window) [http://arno-nuehm.square7.ch/and/aw_startup_scaled.png] [http://arno-nuehm.square7.ch/and/aw_metrics_pt_keys_scaled.png] [http://arno-nuehm.square7.ch/and/aw_metrics_ls_keys_scaled.png] [http://arno-nuehm.square7.ch/and/aw_metrics_ls_nokeys_scaled.png] (full resolution images here: http://arno-nuehm.square7.ch/and/aw_startup.png%|%startup%|%, http://arno-nuehm.square7.ch/and/aw_metrics_pt_keys.png%|%portrait%|%, http://arno-nuehm.square7.ch/and/aw_metrics_ls_keys.png%|%landscape%|%, http://arno-nuehm.square7.ch/and/aw_metrics_ls_nokeys.png%|%landscape after dismissing keyboard%|%. ----- [chw] 2014-05-21: More and more am I convinced that everything works as expected. We have the console made up of a default text widget having 80 columns by 25 rows using the ''DejaVu Sans Mono'' font at 8 points (1 point = 1/72 inch). That makes for the console a real world estate of about 7 centimeters in height and (since the character width is smaller) about 13 centimeters in width. Sure that is more than the Moto G's display's area, so you cannot see the console in its entirety. But you can change either the console's font or the console's geometry in your ~/.wishrc. And no, I will not change the [AndroWish] behavior in this regard, since we already had some opposite complaints 3 month ago about requiring a microscope due to font sizes. ----- [OxFEEDBACC] 2014-05-21: Okay, then it was just about my expectation to see the window adapting to the screen size. > And no, I will not [[...]] And no, I wasn't even considering to argue about preferences ;-) that's what *rc files are for... thanks for your time. ----- [YS] "encoding names" gives me only "utf-8 X11ControlChars ucs-4 ucs-2be identity unicode iso8859-1". Why don't you include other encodings? Hmm, I see all encoding files in [encoding dirs], but observed behavior is quite strange: "source -encoding" works correctly, while using "fconfigure -encoding" produces garbage (but this depends on file extension?) Create this file in cp1251 and save as a.ini and a.tcl: ====== set a "что-то по-русски" set fd [open [info script]] fconfigure $fd -encoding cp1251 gets $fd line close $fd set b [lindex $line 2] button .b1 -text $a button .b2 -text $b grid .b1 .b2 ====== Then this exposes the bug: ====== source -encoding cp1251 a.ini ====== [chw] 2014-05-23: the problem with ''encoding names'' is most likely related to globbing in a virtual file system (the mounted APK file). I'll try to fix this. Regardless of the ''encoding names'' the encoding files are there and can be used. [YS] 2014-05-23: Did you try the script? Are different texts displayed in buttons? [chw] 2014-05-23: Tried it, both buttons show the same text. I've called that file a.tcl and source'd it with source -encoding cp1251 a.tcl. Where is the problem? [YS] Nowhere. It was caused by interaction with tcllib's "inifile" package rewriting file in incorrect (non-system) encoding, I didn't recheck. Sorry to confuse you. :( ---- [YS] Also, trying to use usbserial I've discovered this bug: ====== set fd [usbserial [usbserial]] fconfigure $fd -mode ====== > 19200,n,8,1 ====== fconfigure $fd -mode 19200,n,8,1 ====== Gives error that 'data' value is invalid. [chw] 2014-05-23: in ''fconfigure -mode'' you should specify baud,parity,data,stop (not baud,data,parity,stop). [YS] That's what happens when copying from memory. :( Sorry about that, I've fixed the example. But my point is that I'm passing the value returned by fconfigure into fconfigure, It should work (and works on other platforms). This is more obvious: ====== fconfigure $fd -mode [fconfigure $fd -mode] ====== Gives this: "bad value for -mode date: should be 5, 6, 7 or 8" [chw] 2014-05-23: confirmed, fix is [WIP]. ---- [YS] 2014-05-23: One more bug for you. ;) I can write to file in [pwd] using [open], but: ====== file copy a.txt b.txt ====== complains that I'm not owner. [chw] 2014-05-23: Please provide a more precise test case. What was the current directory? [YS] 2014-05-23: I mean this: ====== set fd [open a.txt w] ; puts $fd a ; close $fd ; #Works ok file copy a.txt b.txt ====== gives: error copying "a.txt" to "b.txt": not owner [chw]: I see, that happens when run on the external or internal SD card (e.g. /storage/sdcard0). It is caused by Android's permission system and usage of supplementary group ids. The fix for Android will be to relax error reporting in the [file] command when errno is EPERM on the chmod() and/or utimes() system calls. For [file] copy the behavior will not be exactly as on normal UN*X platforms, i.e. the exact permission and modification/access time stamps of the destination file cannot always be copied. ---- [YS] 2014-06-02: Trying to use usbserial after your fixes I've found these bugs: I can't read anything from usbserial (nothing returned from [read], [gets] or [fileevent] readable). Looks like there is output buffer length setting bug: ====== puts -nonewline $fd "12345678" > "12345678" comes from the port to the other side. puts -nonewline $fd "aaa" > "aaa45678" comes from the port to the other side. ====== I wonder if you actually have any usbserial device to check these? [chw] 2014-06-02: using a converter with a PL2303 chip I can confirm the output bug (will be fixed soon). However, with this setup I have no problems reading data. [YS] 2014-06-03: I'll see what chip is in my converter... Do you use nonblocking mode? Does [[fileevent readable]] work for you? I see that there is no -timeout option in AndroWish's [fconfigure], so it seems that using nonblocking mode becomes a must for real serial communication. BTW, how your device (AndroWish) reacts if you disconnect converter when port is open? On my device, AndroWish usually just hangs. [chw] 2014-06-04: Since ''usbserial'' is not quite a POSIX tty there's no way to support ''fconfigure -timeout''. So when using ''fileevent'' it is required to use ''fconfigure -blocking 0''. That is working in my setup when the read callback procedure uses ''eof'' and ''fblocked'' appropriately. Regarding disconnects I've observed similar problems. It seems that one of the two Java threads dealing with the USB transfers goes in an endless loop. I'll try to fix this soon. [YS] 2014-06-03: One of converters I've got also has PL2303. I've retested reading on it, and it works. Also I've noticed that [puts] actually always outputs 256 bytes to port, sent data followed by 0x00's. ---- [GCS] 2014-06-18: [[borg isspeaking]] always returns 0 On my Galaxy Note 3, running Alan Turing under kitkat 4.4.2, both speaking and speech recognition work well, but I cannot set up a conversation because I can't tell when [[borg speak ...]] completes. As a workaround, I can put a human in the loop and require a keypress to indicate that the app should start listening for the next vocal input, but a hands-free mode would be nice. [chw] 2014-06-18: not much I can do regarding detecting when TTS is over than calling some Java stuff on Android's side. But OTOH what do you understand exactly as "hands-free mode"? And what would be required to make Tcl/Tk (plus some AndroWish stuff) hands-free? It could possibly be helpful if you would provide a code snippet to illustrate your intention. [GCS] 2014-06-19 Below is a snippet of the code, which I execute in namespace ::Eliza. I removed most of the GUI stuff, leaving only a bit to show how I use the key to have the code ask for input. In the desired hands-free mode, Eliza would ask me to state my problem, I would reply, she would "give advice," I would comment,.... Having to press a button to indicate I want to talk is not terrible, but I think it would be geekier if it were pure conversation. BTW, the rest of Eliza's code in in http://wiki.tcl.tk/36981 ====== # Say something, check once a sec for end of speech and listening, then ask for vocal input variable islistening 0 borg speak "Eliza will see you now. Please state your problem." while 1 { after 1000 if {![borg isspeaking] && ! $islistening} { getinput } } # In hands-free mode the following is never executed. Where [borg isspeaking] does not work, change [while 1] to [while 0] above focus .eliza.t bind .eliza.t ::Eliza::getinput # Start speech recognition and wait for callback proc getinput {} { variable islistening 1 borg speechrecognition {} processspeech return } # Use data from speech recognition to compute the next thing to say and say it proc processspeech {retcode data} { variable islistening 0 array set recog $data set input [lindex $recog(android.speech.extra.RESULTS) 0] set response [response $input] borg speak [string tolower $response] } ====== [chw] 2014-06-20: thanks, I see. During review of the C code implementing ''borg isspeaking'' etc. I've found a bug which safely suppresses the proper return code. It will be fixed soon. [chw] 2014-06-21: The "''Manu Chao''" edition (2014-06-21) should fix all speech issues now. Consequently, I couldn't resist to adapt the Eliza from this Wiki to the new speech recognition features and copy her as /assets/sdl2tk8.6/demos/android_eliza.tcl into the [AndroWish] package. Updated documentation on '''borg speechrecognition''' follows soon on [AndroWish: Documentation]. [GCS] 2014-06-26: Thank you for the fast response. It took me a couple days to get back to the project, and then a while to get my code working, but I have now verified that Manu Chao works properly, allowing an AndroWish app to converse with the user. I will soon post some code on my Classic Eliza wiki page. ---- '''[AM] - 2014-07-04 12:54:26''' Got my first app working on my Cubot GT99, but the Checkbuttons and Radio Buttons are both tiny, althogh the text is the expected size. The screen resolution on the phone is 1280x720. ---- '''[AM] - 2014-07-04 13:19:37''' [http://s30.postimg.org/ulbc3fos1/Screenshot.png] <>Android