| 00:00:05 | _bilgus_ | nope sigh I just looked at the wrong file twice that had pathfuncs defined |
| 00:02:54 | _bilgus_ | no I did include it |
| 00:02:57 | _bilgus_ | wth |
| 00:04:41 | _bilgus_ | so those sims must not bring in MV like the rest |
| 00:05:05 | _bilgus_ | I guess i'll look in a working config vs non |
| 00:10:59 | _bilgus_ | hmm it builds on my system |
| 00:17:29 | _bilgus_ | ccache was hiding it |
| 00:19:25 | _bilgus_ | ok so I should be able to add have mv there |
| 00:34:11 | rb-bluebot | Build Server message: New build round started. Revision 2348779ae6, 337 builds, 9 clients. |
| 00:34:11 | rb-bluebot | [Bugfix #2] initialize the volume names for the sim by William Wilgus |
| 00:35:17 | _bilgus_ | that took me way longer to figure out than it would have 12 hrs ago :/ |
| 00:45:13 | rb-bluebot | Build Server message: Build round completed after 663 seconds. |
| 00:45:14 | rb-bluebot | Build Server message: Revision 2348779ae6 result: All green |
| 01:00 |
| 01:56:36 | *** | No seen item changed, no save performed. |
| 02:00 |
| 02:03:54 | | Join braewoods [0] (~braewoods@user/braewoods) |
| 02:17:56 | | Quit pixelma (Quit: .) |
| 02:17:57 | | Quit amiconn (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) |
| 02:18:59 | | Join pixelma [0] (marianne@p4fe76325.dip0.t-ipconnect.de) |
| 02:18:59 | | Join amiconn [0] (jens@p4fe76325.dip0.t-ipconnect.de) |
| 03:00 |
| 03:56:40 | *** | Saving seen data "./dancer.seen" |
| 05:00 |
| 05:56:41 | *** | No seen item changed, no save performed. |
| 07:00 |
| 07:56:43 | *** | No seen item changed, no save performed. |
| 07:59:34 | _bilgus_ | I'm still trying to figure out a good way how to get when track changes occur sometimes its perfect and the event fires right when the buffer drops other times its 2 seconds prior |
| 08:00 |
| 08:00:58 | _bilgus_ | I'm guessing that depends on the bitrate mainly |
| 08:01:18 | _bilgus_ | I DON'T want to watch samples |
| 08:56:59 | speachy | In other news, I was doing another round of "have there been any developments in a FOSS audio-capable BT stack?" |
| 08:57:44 | speachy | and it looks like Zephyr is getting a classic A2DP implementation. |
| 08:58:29 | speachy | (still grumpy about BlueKitchen going from GPL to BSD with a non-commercial clause...) |
| 09:00 |
| 09:00:58 | speachy | (I mean, in practice it works out the same; anyone that's going to violate the GPL is going to violate the non-commercial clause just as freely) |
| 09:01:52 | speachy | (and the remedy is the same either way; ie a copyright infrinement lawsuit) |
| 09:15:45 | speachy | </rant> |
| 09:29:20 | | Quit speachy (Quit: WeeChat 4.3.4) |
| 09:32:59 | | Join speachy [0] (~speachy@hurricane.shaftnet.org) |
| 09:32:59 | | Quit speachy (Changing host) |
| 09:32:59 | | Join speachy [0] (~speachy@rockbox/developer/speachy) |
| 09:32:59 | Mode | "#rockbox +v speachy" by ChanServ (ChanServ@services.libera.chat) |
| 09:47:07 | _bilgus_ | dconrad I think I have this thing working pretty well |
| 09:47:42 | _bilgus_ | the third one is still a bit iffy to me but it seems to trigger just at the right time AFAICT |
| 09:48:34 | speachy | will this cause problems with gapless playback? |
| 09:48:46 | _bilgus_ | I did try calculating the sample size left and busy waiting and that worked but I really don't like busy looping in this situ |
| 09:49:17 | _bilgus_ | it won't work with crossfade |
| 09:49:32 | _bilgus_ | gapless should be ok |
| 09:50:02 | _bilgus_ | gapless won't be affected but it may or may not be valid silence |
| 09:50:56 | _bilgus_ | you may also be able to catch issues with a track by looking for idle 1/2 |
| 09:51:29 | _bilgus_ | basically I added my even just when the pcm buffer gets moved to the new track |
| 09:51:55 | _bilgus_ | in theory the previous track just played its last sample and the next track is just about to play |
| 09:52:52 | | Join dconrad_phone [0] (~dconrad_p@205.237.113.8) |
| 09:53:19 | _bilgus_ | I should say crossfade won't work without some testing + calculation I bet you could still get a spot right in the middle but that seems overly complicated |
| 09:54:30 | dconrad_phone | _bilgus: so is this a single event that fires when audio is detected to be idle? |
| 09:54:36 | _bilgus_ | yep |
| 09:54:53 | dconrad_phone | or is is repeatedly firing while audio continues to be idle? |
| 09:54:55 | _bilgus_ | it should fire when skipping fast fwd/rew and track skip |
| 09:55:37 | _bilgus_ | no but you may get 2 in sequence depending on how the track skip processed |
| 09:56:11 | _bilgus_ | I only saw that when skipping a lot but it is possible \ |
| 09:56:45 | _bilgus_ | also don't hold that event long if you need more time it needs to send a queue event to make it asynchronous |
| 09:56:46 | *** | Saving seen data "./dancer.seen" |
| 09:56:48 | speachy | my attempt to voice the mountpoint hasn't worked yet, at least not in the simulator. |
| 09:58:08 | _bilgus_ | could just make it say volume 0 1 or w/e so you don't have to do anything extra |
| 09:58:18 | dconrad_phone | part of what I need to work through is how do we enable the detection (this idle event) and then how do we disable it when audio starts playing again... I'll need to look if theres already something analogous to your AUDIO_IDLE? |
| 09:58:21 | _bilgus_ | rather than the actual type |
| 09:59:26 | _bilgus_ | adding a second event is probably overkill |
| 10:00 |
| 10:00:19 | _bilgus_ | you should be able to look at the indexes to see if its playing |
| 10:01:35 | _bilgus_ | actually as long as you do your processing in that event for case 3 (track change) the other two are ffwd/rew and track skip |
| 10:02:21 | _bilgus_ | we could send the idle event again with a sentinel of 0 |
| 10:04:03 | _bilgus_ | I can set it up to use the audio queue to send events but you are then at the whim of the scheduler |
| 10:04:27 | _bilgus_ | and you kinda need realtime info on the track change one |
| 10:05:36 | dconrad_phone | to be honest, I'm not entirely sure if we actually want the detection to happen during the "between tracks" events |
| 10:06:57 | dconrad_phone | my conception of it was that the user is unplugging/plugging in things, that's not going to happen in the moments between tracks probably |
| 10:08:01 | _bilgus_ | that makes it a lot easier |
| 10:08:22 | | Quit dconrad_phone (Quit: Connection closed) |
| 10:08:50 | _bilgus_ | in that case you can get an event for idle / active |
| 10:09:35 | _bilgus_ | but the issue there is that may be the only time you get to check |
| 10:09:55 | | Join dconrad_phone [0] (~dconrad_p@205.237.113.8) |
| 10:10:39 | _bilgus_ | IDK I think this won't work |
| 10:10:58 | dconrad_phone | but to this functionality, it's really more like 2 states, playing/not playing |
| 10:11:29 | _bilgus_ | I think maybe you could check your detection if shows its changed set a flag and check over the next second of time and if its the same lock it in |
| 10:12:05 | _bilgus_ | basically use that instability around level to verify you have a real plug/unplug event |
| 10:13:00 | dconrad_phone | yeah that's true, that debounce will be important to keeping the pause on unplug functionality active |
| 10:13:15 | dconrad_phone | to avoid false unplugs on LO |
| 10:13:33 | _bilgus_ | Its the only way I can see that it will work in a satisfactory manner in any situation |
| 10:14:16 | _bilgus_ | otherwise you'll be looking at the actual audio data and man thats going to suck |
| 10:15:50 | _bilgus_ | then if you want to be reallly sure inject silence for a sample and check again before you pull the trigger |
| 10:17:56 | dconrad_phone | well, the main issue to get around is the output latching to the hp... I'll have to get out a piece of paper and really start thinking through the various scenarios |
| 10:18:57 | _bilgus_ | whatever you decide LMK I'll try to help |
| 10:19:17 | dconrad_phone | for sure, 'preciate it |
| 10:19:50 | | Quit dconrad_phone (Quit: Connection closed) |
| 10:28:28 | | Join dconrad_phone [0] (~dconrad_p@205.237.113.8) |
| 10:30:16 | _bilgus_ | dconrad is there a reason you can't just leave the detection loop running or is it just that you were getting bunk data? |
| 10:31:56 | dconrad_phone | well... I gotta get back to, yknow, job but I think maybe I'm overthinking this... can keep the detection going all the time, and do: 1) block changing outputs unless not playing 2) debounce detection 3) switch to LO during not playing so we can detect a LO plugged in |
| 10:33:10 | _bilgus_ | should be able to know pretty definitively after a few samples matching hp_detect_reg |
| 10:33:13 | _bilgus_ | or not |
| 10:33:23 | dconrad_phone | the stopping detection was largely because of (2) |
| 10:33:28 | _bilgus_ | even if playing |
| 10:34:39 | dconrad_phone | because we can only detect a hi-z sink while that output is already active |
| 10:34:55 | dconrad_phone | hence the "latching" behavior |
| 10:35:14 | _bilgus_ | if playback data changes your detection though it should throw out the event |
| 10:35:58 | _bilgus_ | becuase its going to change every detection if you look for it to be stable over n millisec in theory its a good event |
| 10:36:25 | dconrad_phone | well that's only one part of it, see - we also need to handle if nothing is currently plugged in to the LO port and then something is plugged in |
| 10:36:54 | dconrad_phone | so yes, you're right we need debounce |
| 10:37:01 | _bilgus_ | thats the most important one too |
| 10:37:49 | dconrad_phone | but also if we change outputs while audio is playing, you cannot detect a LO plugfed back in. fine if pause on unplug is active, a problem if it is not |
| 10:39:02 | dconrad_phone | god if they would not have cheaped out and used jacks with real switches this wouldnt be a problem |
| 10:39:29 | dconrad_phone | or if they used the ground ring instead of tip |
| 10:40:20 | speachy | saved a fraction of a penny per unit that way, eh? |
| 10:40:39 | dconrad_phone | not even if they used ground! |
| 10:40:48 | speachy | it's a head scratcher |
| 10:40:49 | _bilgus_ | in that case I wonder how much silence we could get away with and not cause a user to notice |
| 10:41:08 | dconrad_phone | oh well. gotta go do job, thanks for the thoughts 👍 |
| 10:41:09 | speachy | it's not "Silence" so much as "carefully coordinated silence in realtime" |
| 10:41:18 | speachy | ugh. |
| 10:41:32 | _bilgus_ | like inject a single packet and check right then |
| 10:41:46 | | Quit dconrad_phone (Quit: Connection closed) |
| 10:42:02 | speachy | we could just throw up our hands and say "if you want to swap plugs, pause the audio first" |
| 10:42:23 | _bilgus_ | i was thinking that too just add a button for em |
| 10:42:58 | _bilgus_ | I wonder if we could interrupt the audio output just long enough to do our detection |
| 10:43:37 | speachy | ...reliably, you mean. |
| 10:43:41 | _bilgus_ | in theory you could throw an interrupt and halt the world while you check your gpio and be back before anyone notices |
| 10:44:19 | _bilgus_ | yes reliably I think bad LO detection is grounds for termination :p |
| 10:45:01 | speachy | audio is tricky like that |
| 10:45:37 | speachy | ... because our ears are incredibly sensitive to dropouts like that. |
| 10:45:59 | speachy | this is why the codecs do things like volume adjustments etc at zero crossovers. |
| 10:53:51 | _bilgus_ | yeah thats a good point so tell the user to pause to do LO and leave it at that |
| 10:55:06 | _bilgus_ | ...and remove the pause on unplug |
| 11:00 |
| 11:56:47 | *** | Saving seen data "./dancer.seen" |
| 12:00 |
| 12:16:50 | | Quit b0 (Read error: Connection reset by peer) |
| 12:18:40 | | Join b0 [0] (~b0@user/b0) |
| 13:00 |
| 13:17:57 | | Join lebellium [0] (~lebellium@2a01cb0405d07f00d414dfe6eaeda6ef.ipv6.abo.wanadoo.fr) |
| 13:56:50 | *** | Saving seen data "./dancer.seen" |
| 13:57:03 | | Join ac_laptop [0] (~ac_laptop@2a0c:e303:0:7300:e29d:31ff:fe2d:a258) |
| 14:00 |
| 14:24:38 | | Join dconrad_phone [0] (~dconrad_p@205.237.113.8) |
| 14:25:44 | dconrad_phone | So I think I was way off base on how to handle the lo/hp detect before... ref. my new comments at the bottom of g#5786 |
| 14:25:46 | rb-bluebot | Gerrit review #5786 at https://gerrit.rockbox.org/r/c/rockbox/+/5786 : ErosQNative: Proof-Of-Concept headphone/line-out detection by Dana Conrad |
| 14:26:14 | dconrad_phone | got my player all fixed up so it detects properly too |
| 14:28:08 | dconrad_phone | pretty sure we just need to implement a debounce and make the LO the default output |
| 14:29:29 | dconrad_phone | I'll work on that tonight when I get home |
| 14:30:08 | | Quit dconrad_phone (Quit: Connection closed) |
| 14:31:15 | | Join dconrad_phone [0] (~dconrad_p@205.237.113.8) |
| 14:34:38 | | Quit dconrad_phone (Client Quit) |
| 14:49:05 | | Quit b0 (*.net *.split) |
| 14:49:09 | | Quit paulk (*.net *.split) |
| 14:49:35 | | Quit npmania (*.net *.split) |
| 14:49:35 | | Quit Natch (*.net *.split) |
| 14:49:35 | | Quit TorC (*.net *.split) |
| 14:49:35 | | Quit jj5 (*.net *.split) |
| 14:49:35 | | Quit yosafbridge (*.net *.split) |
| 14:49:35 | | Quit JanC (*.net *.split) |
| 14:49:37 | | Join b0 [0] (~b0@user/b0) |
| 14:49:37 | | Join paulk [0] (~paulk@about/aquilenet/user/paulk) |
| 14:49:37 | | Join npmania [0] (~npmania@210.123.73.190) |
| 14:49:37 | | Join Natch [0] (~natch@c-9e07225c.038-60-73746f7.bbcust.telenor.se) |
| 14:49:37 | | Join TorC [0] (~Tor@fsf/member/TorC) |
| 14:49:37 | | Join jj5 [0] (~jj5@100.80.216.139.dynamic.dsl.dv.iprimus.net.au) |
| 14:49:37 | | Join yosafbridge [0] (~yosafbrid@static.38.6.217.95.clients.your-server.de) |
| 14:49:37 | | Join JanC [0] (~janc@user/janc) |
| 14:51:07 | | Quit JanC (Max SendQ exceeded) |
| 14:52:21 | | Join JanC [0] (~janc@user/janc) |
| 15:00 |
| 15:56:52 | *** | Saving seen data "./dancer.seen" |
| 16:00 |
| 16:38:10 | | Join davisr [0] (~davisr@fsf/emeritus/davisr) |
| 16:58:11 | | Quit davisr (Quit: yeehaw) |
| 17:00 |
| 17:16:53 | rb-bluebot | Build Server message: New build round started. Revision 10e883fe02, 337 builds, 10 clients. |
| 17:16:53 | rb-bluebot | FS #13455: Updated Italian translation (Alessio Lenzi) by Solomon Peachy |
| 17:22:03 | speachy | c |
| 17:28:14 | rb-bluebot | Build Server message: Build round completed after 683 seconds. |
| 17:28:16 | rb-bluebot | Build Server message: Revision 10e883fe02 result: All green |
| 17:36:53 | | Join PheralSparky [0] (~S|h|a|w|n@user/shawn/x-4432647) |
| 17:47:15 | | Join Moriar [0] (~moriar@107-200-193-159.lightspeed.stlsmo.sbcglobal.net) |
| 17:56:17 | | Quit lebellium (Quit: Leaving) |
| 17:56:55 | *** | Saving seen data "./dancer.seen" |
| 18:00 |
| 18:00:43 | | Quit ac_laptop (Ping timeout: 264 seconds) |
| 18:17:49 | | Quit Natch (Remote host closed the connection) |
| 18:27:33 | | Join dconrad [0] (~dconrad@152.117.104.217) |
| 18:38:09 | | Join Natch [0] (~natch@c-9e07225c.038-60-73746f7.bbcust.telenor.se) |
| 18:42:23 | | Quit PheralSparky (Read error: Connection reset by peer) |
| 18:42:55 | | Join PheralSparky [0] (~S|h|a|w|n@user/shawn/x-4432647) |
| 19:00 |
| 19:10:23 | _bilgus_ | I'm going to start on a new cue viewer plugin and explore if i'll be able to get away with it and still have enough ram to actually display them |
| 19:12:26 | _bilgus_ | after observing just how long it takes to pull metadata from a file I think this should probably do just fine |
| 19:14:59 | _bilgus_ | its the playlist to cue part that needs some work like maybe incremental updates because I haven't quite figured out how to match the current track to the playlist once they diverge, maybe take the crc of them to make a faster search |
| 19:16:59 | _bilgus_ | I intend to leave this even if we do go to extended id3 which would use the db and be just as slow for unindexed files |
| 19:49:45 | | Join massiveH [0] (~massiveH@2600:4040:a982:dc00:18e2:9fc:2a9d:bf86) |
| 19:56:58 | *** | Saving seen data "./dancer.seen" |
| 20:00 |
| 20:17:04 | | Join saratoga [0] (~saratoga@64.201.232.94) |
| 20:27:16 | saratoga | building on WSL2 in Win11 is really fast |
| 20:27:31 | saratoga | i remember WSL on 10 being painfully slow |
| 20:31:08 | saratoga | whats the link for the editable wiki? |
| 20:32:55 | | Quit speachy (Quit: WeeChat 4.3.4) |
| 20:33:13 | | Join speachy [0] (~speachy@rockbox/developer/speachy) |
| 20:33:13 | Mode | "#rockbox +v speachy" by ChanServ (ChanServ@services.libera.chat) |
| 20:33:19 | speachy | saratoga: /realwiki/ |
| 20:33:40 | speachy | _bilgus_: volume display on sim is still busted fwiw. |
| 20:35:03 | speachy | still on the x3, hit e to insert the simdisk and browse to files, you'll see<microSD1>. browse into a subdir, you'll see those files... and <microSD1> |
| 20:35:09 | | Join ac_laptop [0] (~ac_laptop@2a0c:e303:0:7300:e29d:31ff:fe2d:a258) |
| 20:35:35 | speachy | oddly enough I can't actually browse _into_ <microSD1> |
| 21:00 |
| 21:11:50 | saratoga | i can run sdl-config from the command line but configure says "configure didn't find sdl-config, which indicates that you don't have SDL (properly) installed. " |
| 21:14:18 | dconrad | Alright, get some eyes on g#5845 - I was indeed vastly overthinking this issue before. It appears to work as you would expect both with pause-on-unplug disabled and enabled, on both my new(ish) player and my old v1.3 player. Detects both headphones and line-out, and makes headphones take precedence if both are present. |
| 21:14:21 | rb-bluebot | Gerrit review #5845 at https://gerrit.rockbox.org/r/c/rockbox/+/5845 : ErosQNative: Debounce jack detection and make Line-Out default by Dana Conrad |
| 21:14:24 | speachy | cross-compiled winsim? |
| 21:14:46 | speachy | or linux sim compiled under wsl? |
| 21:15:03 | saratoga | cross-compiled on WSL |
| 21:15:07 | saratoga | i'm trying to update the instructions |
| 21:15:35 | speachy | do you have the _right_ sdl-config? |
| 21:15:38 | dconrad | I didn't test quite as much on the old player but it sure seemed like it was behaving exactly as you would expect. The only gotcha is that line-in devices will not be detected in the HP port. Headphones will be detected in the LO port though, but.... use the right device in the right place I guess? |
| 21:15:44 | saratoga | https://pastebin.com/jHLjiU0U |
| 21:15:47 | speachy | (ie 32/64-bit cross cmmpile?) |
| 21:16:21 | speachy | ah, ok. just running sdl-config on the path will get you the "native" (ie linux) sdl |
| 21:16:21 | saratoga | i did −−host=i686-w64-mingw32 for SDL |
| 21:17:05 | speachy | eg on my system (mingw64 cross toolchain) you need |
| 21:17:07 | speachy | /usr/x86_64-w64-mingw32/sys-root/mingw/bin/sdl-config |
| 21:17:27 | speachy | provided by the mingw64-sdl12-compat package (on Fedora) |
| 21:17:38 | saratoga | lrwxrwxrwx 1 root root 50 Jul 25 21:08 /usr/bin/sdl-config -> /usr/local/cross-tools/i386-mingw32/bin/sdl-config |
| 21:17:44 | | Quit ac_laptop (Quit: WeeChat 3.8) |
| 21:17:52 | saratoga | although i386 seems weird |
| 21:18:36 | speachy | I'm pretty sure MarcAndersen is doing his winsim builds from under WSL |
| 21:19:22 | speachy | /usr/bin/sdl-config symlinked to a cross-built sdl-config? that's... odd. |
| 21:19:47 | saratoga | i just tried that when configure couldn't find it |
| 21:19:47 | speachy | but that path is also not part of the standard mingw directory |
| 21:20:30 | saratoga | The build for SDL 1.2 says "Libraries have been installed in: /usr/local/cross-tools/i386-mingw32/lib" so I think that is correct |
| 21:21:19 | speachy | mingw is expecting them to live under its sysroot |
| 21:21:31 | speachy | $CPP −−print-sysroot |
| 21:21:42 | speachy | that's where the configure script looks |
| 21:21:59 | saratoga | huh, the wiki says to do "ln -s /usr/local/cross-tools/i386-mingw32/bin/sdl-config /usr/bin/i686-w64-mingw32-sdl-config" |
| 21:22:01 | speachy | could probably add an option to pass the path to sdl-config |
| 21:23:37 | saratoga | is $CPP supposed to be defined on the command line? |
| 21:24:36 | speachy | x86_64-w64-mingw32-cpp |
| 21:26:27 | speachy | saratoga: https://www.shaftnet.org/~pizza/config.diff |
| 21:26:53 | speachy | try applying that, then SDL_PATH=/path/to/dir/with/sdl-config ./configure |
| 21:27:30 | speachy | if that works then I'll make that a little more robust/documented |
| 21:29:42 | rb-bluebot | Build Server message: New build round started. Revision e8d7a8baaf, 337 builds, 9 clients. |
| 21:29:42 | rb-bluebot | simulator: Fix browsing into secondary drive on multidrive targets by Solomon Peachy |
| 21:30:18 | speachy | _bilgus_: this ^^ appears to fix what I bugged you about |
| 21:31:24 | speachy | saratoga: wait, I was looking at that pastebin and it looks like you didn't choose a winsim build? |
| 21:32:00 | saratoga | did not realize that was an option, let me look |
| 21:32:11 | speachy | you have to do A W (or 6) S |
| 21:33:37 | saratoga | it is W/6 AND S? |
| 21:35:12 | speachy | yeah |
| 21:35:30 | speachy | (should probably coalesce that) |
| 21:35:44 | speachy | (one more thing for the miles-long list...) |
| 21:36:08 | saratoga | I get: /usr/bin/x86_64-w64-mingw32-ld: skipping incompatible /usr/local/cross-tools/i386-mingw32/lib/libSDLmain.a when searching for -lSDLmain |
| 21:36:45 | speachy | btw, thanks for continuing to represent on various social media |
| 21:37:17 | saratoga | i'm a little confused since they're both the 64 bit compile |
| 21:37:23 | speachy | that error looks like you chose a 64-bit winsim build but the libs are 32-bit |
| 21:38:00 | saratoga | for sdl I did "./configure −−host=i686-w64-mingw32" and for minigw I did: sudo apt-get install mingw-w64 |
| 21:38:10 | saratoga | unless those names are really misleading should both be 64 bit |
| 21:38:17 | saratoga | and i'm doing the 64 sim build |
| 21:38:32 | speachy | I don't know how deb/ubuntu do their mingw stuff |
| 21:38:52 | saratoga | ugh i686-w64-mingw32 is 32 bit |
| 21:41:28 | rb-bluebot | Build Server message: Build round completed after 706 seconds. |
| 21:41:29 | rb-bluebot | Build Server message: Revision e8d7a8baaf result: All green |
| 21:41:43 | speachy | I don't think we're actually clean ona 64-bit windows build anyway |
| 21:42:10 | speachy | (due to 'unsigned long' not being the same width as a pointer) |
| 21:43:50 | saratoga | i got it to build |
| 21:43:59 | saratoga | seems to work, i'll update the instructions |
| 21:44:06 | saratoga | is there a reason to prefer a 32 bit build? |
| 21:44:33 | saratoga | i guess it might be easier to debug memory problems if everything is 32 bit like target |
| 21:45:55 | speachy | we're 64-bit clean in general but when I was last trying to clean out bitrot on the winsim builds I saw warnings about pointer size mismatches on the win64 build |
| 21:46:21 | speachy | (because on sane platforms, unsigned long is defined to be the same as the native pointer size. not so under windows..) |
| 21:47:39 | saratoga | in terms of debugging things like codecs, 32 bit is probably more useful |
| 21:47:44 | saratoga | i'll put instructions for both |
| 21:49:52 | speachy | yeah, warnings in the skin parser, tslf library, and lua |
| 21:50:21 | speachy | please recommend 32-bit unless they want to suffer needlessly |
| 21:51:39 | speachy | fwiw I intend to add per-commit winsim builds to the buildfarm |
| 21:52:18 | speachy | but I don't have a sane way to determine what other dependencies need to be bundled.. |
| 21:56:59 | *** | Saving seen data "./dancer.seen" |
| 21:58:10 | saratoga | i updated the WSL cross compiler wiki page, both 32 and 64 bit builds work for me |
| 21:58:34 | saratoga | setting up WSL is now shockingly easy, longest step was rebooting |
| 22:00 |
| 22:30:03 | | Quit saratoga (Quit: Connection closed) |
| 23:00 |
| 23:00:10 | _bilgus_ | speachy sorry I didn't realize it wasn't anything more than it not showing in the list |
| 23:12:51 | | Quit jn (Ping timeout: 252 seconds) |
| 23:13:08 | | Join jn [0] (~quassel@user/jn/x-3390946) |
| 23:19:38 | | Quit braewoods (Read error: Connection reset by peer) |
| 23:19:43 | | Join braewoods_ [0] (~braewoods@user/braewoods) |
| 23:22:24 | | Quit Moriar (Ping timeout: 252 seconds) |
| 23:35:04 | speachy | _bilgus_: I didn't realize it either. keep running into new rabbit holes that get in the way of what I want to do |
| 23:36:19 | speachy | ...it's been broken for a while. |
| 23:57:03 | *** | Saving seen data "./dancer.seen" |
icon identifies that the person is a core developer (has commit access).