--- Log for 21.05.123 Server: copper.libera.chat Channel: #rockbox --- Nick: rb-logbot Version: Dancer V4.16 Started: 1 month and 0 days ago 00.05.07 *** Saving seen data "./dancer.seen" 00.24.21 Quit massiveH (Quit: Leaving) 00.37.11 Quit m01 (Quit: Konversation terminated.) 00.39.41 Join m01 [0] (~quassel@vps-b172b88b.vps.ovh.net) 02.05.09 *** Saving seen data "./dancer.seen" 02.12.17 Nick tr is now known as Nyaa (Nyaaori@cyberia.club/meow/nyaaori) 03.31.08 Quit LjL (Read error: Connection reset by peer) 03.32.03 Join LjL [0] (~ljl@user/ljl) 04.05.12 *** Saving seen data "./dancer.seen" 04.36.00 Join lebellium [0] (~lebellium@2a01cb040610e0009594ac063bcc870f.ipv6.abo.wanadoo.fr) 06.05.15 *** No seen item changed, no save performed. 06.19.03 Quit sam_d (Quit: Bye) 06.19.17 Join sam_d [0] (~sam@user/sam-d/x-8933526) 08.05.17 *** Saving seen data "./dancer.seen" 09.03.06 # <_bilgus> I'm looking to add another interpreted language to RB ATM I'm really leaning towards micropython 09.03.33 # <_bilgus> so starting with a plugin and I'd then like to investigate putting the VM in core and eventually move all our parsers and etc 09.13.04 Join othello7 [0] (~Thunderbi@pool-100-36-166-8.washdc.fios.verizon.net) 09.23.03 # _bilgus, careful it doesn't bite you. :P 09.29.47 # <_bilgus> the dynamic memory worries me 09.30.44 # <_bilgus> theres a lua inspired squirrel that has a better ethos but I figure it'd be hard to integrate a c++ code base to anything dealing with core 09.32.56 # <_bilgus> braewoods, I actually started with thinking about a basic interpreter but I think it'd end up pretty clunky 09.33.40 # _bilgus, no offense but it should be something people actually *want* to use. i can't say I know many people who would want to use BASIC today. 09.34.18 # There's a fair number of options for embeddable interpreters. There's also JS ones. 09.34.47 # But JS has its own issues. Probably slower than Lua. 09.35.30 # <_bilgus> lua is not very fast and the dynamic memory is baddd 09.35.59 # Aren't most of these going to use dynamic memory? 09.36.19 # <_bilgus> I had hope of embedding lua but I think the ram usage just makes it a bad choice anywhere near the core 09.36.47 # Did you look at duktape? 09.37.27 # https://duktape.org/ 09.37.42 # they have a table for RAM usage in such an embedded situation. 09.38.35 # <_bilgus> thats higher than lua 09.38.41 # Oh, it is? 09.38.50 # And micropython is better? 09.39.22 # <_bilgus> No IDK yet 09.39.51 # I see. So why would you move C code to micropython, if it were viable? It's slower, isn't it? 09.40.01 # <_bilgus> squirrel really matched my goals but integrating c++ into core seems difficult 09.40.39 # <_bilgus> my idea would be to move all the setup bits to pre compiled bytecode 09.40.55 # And why would we want that? 09.41.07 # I'm trying to understand how this helps in an embedded device situation. 09.41.22 # <_bilgus> all these parsers menus and backend could by dynamically loaded and unloaded 09.42.19 # It sounds like what you really want is to make kernel modules. 09.42.49 # Am I wrong? 09.43.11 # <_bilgus> that probably wouldn't be a bad idea but moving to an interpreter would allow more customization 09.43.50 # How so? 09.44.31 # I know C code is hard-coded once compiled but isn't byte code the same way? 09.44.58 # Where's the customization or flexibility you are referring to? 09.45.30 # <_bilgus> you could compile to bytecode with the plugin 09.46.07 # <_bilgus> so lets say you want scrolling menus you could change the code and load it like a theme 09.46.08 # I could see value if you were thinking of making something like scriptable themes. 09.46.23 Quit othello7 (Ping timeout: 264 seconds) 09.46.47 # So this is all in the name of UI customization? 09.47.18 # <_bilgus> my thought is start there and move it further as it matures 09.47.53 Join othello7 [0] (~Thunderbi@pool-100-36-166-8.washdc.fios.verizon.net) 09.47.56 # It just doesn't make sense unless you are wanting to work with user scripts or target independent code. 09.48.30 # <_bilgus> we already work with user scripts 09.48.38 # <_bilgus> tagnav for instance 09.49.35 # Fair. 09.49.59 # <_bilgus> the parser can still use that old syntax or we could change it 09.50.51 # I'm planning to return to rockbox stuff later this year probably. Right now I'm working on a project to get used to libusb. :3 09.52.06 # <_bilgus> I think everyone has been busy 09.52.08 # I had a weird idea that might be fun to do with Rockbox, plausibly anyway. What if plugins could act as a usb driver? 09.52.18 # <_bilgus> judging by the dearth of commits 09.52.41 # <_bilgus> USB is already exclusive 09.53.02 # <_bilgus> so would be fine after some API massage 09.53.28 # I was just considering that it might be interesting to be able to implement a plugin to allow USB control of the screen or similar. 09.53.46 Quit othello7 (Quit: othello7) 09.53.49 # <_bilgus> well you already have the multimedia buttons 09.53.51 # My current project is a program to manage USB LCD screens that use 16 bit pixels. 09.54.33 # <_bilgus> I just saw a spotify frontend screen like a bluetooth volume and track skip and shows the current songs 09.55.21 # well, the idea I had was to maybe use the usb serial device to allow a client program to control the rockbox LCD screen arbitrarily. 09.56.05 # It may sound strange but adding essentially a dock mode for Rockbox might be interesting. 09.57.27 # anyway i'll look into it later. it sounds best done as part of MTP honestly. 09.58.44 # <_bilgus> would you be able to tell if a device had been removed 'safely'? 09.59.32 # <_bilgus> I guess we could detect the dirty bit? 10.00.10 # MTP? 10.00.50 # <_bilgus> yeah does USB have any way to tell the device it wasn't removed safely? 10.00.58 # <_bilgus> or that it was? 10.03.31 # not that I know of? 10.03.57 # MTP was designed to resolve this by eliminating raw access. 10.04.42 # It won't replace our UMS driver entirely as it's still needed sometimes for maintenance. 10.05.02 # But it could serve as a replacement for general use. 10.05.18 *** Saving seen data "./dancer.seen" 10.18.16 # <_bilgus> ah ok 10.27.21 # Plus it also allows for some extra stuff that aren't commonly used, like device properties that could be used to allow remote control. 10.27.54 # One use case I could see is exposing the RTC so a host utility could set the rockbox RTC. 10.28.07 # This would be much better than manually adjusting it. 10.43.31 # Personally I'd like to see the half-fiinshed playlist reworking finished. 10.43.50 # ...The half-finished USB reworking finished... 10.43.58 # exFAT support 10.44.00 # and a pony 10.44.20 # along those lines, anyone else tried the GPT stuff yet? 10.46.12 # I started working on moving the internal representation of disk/flash sector and storage/volume size to 64-bit. What makes this fun is that many of the APIs use pointers so it's looking like it's going to be an all-or-nothing proposition. 10.47.07 # we _might_ be able to make the type build-time selectable, ie don't go 64-bit on parts that only have internal storage, for example. 10.47.40 # but anything with ATA/CF or SD will need to be 64-bit. 10.49.41 # _bilgus: loath as I am to suggest it, if we're going to embed another interpreted language, I'd suggest micropython. 10.51.32 # but I don't know if that would be worth it for parsers etc; might make more sense to use some sort of codegen tool that takes an IDL and spits out C. 11.55.17 # c 11.59.38 Quit JanC (Remote host closed the connection) 11.59.58 Join JanC [0] (~janc@user/janc) 12.05.22 *** Saving seen data "./dancer.seen" 12.18.25 # Also as a general FYI, I'm going to have to take down the main VM for an OS upgrade in the near future. 13.49.45 Quit speachy (Quit: WeeChat 3.6) 14.05.23 *** Saving seen data "./dancer.seen" 16.05.27 *** No seen item changed, no save performed. 17.28.09 Quit Nyaa (Read error: Connection reset by peer) 17.29.41 Join Nyaa [0] (Nyaaori@cyberia.club/meow/nyaaori) 17.42.35 Quit lebellium (Quit: Leaving) 18.05.30 *** Saving seen data "./dancer.seen" 18.53.02 Join Acou_Bass [0] (~eddie@bolt-17-b2-v4wan-167407-cust78.vm18.cable.virginm.net) 18.54.58 Quit Piece_Maker (Ping timeout: 268 seconds) 18.54.58 Nick Acou_Bass is now known as Piece_Maker (~eddie@bolt-17-b2-v4wan-167407-cust78.vm18.cable.virginm.net) 19.01.46 Join massiveH [0] (~massiveH@2600:4040:a99f:1f00:e8e5:fe5e:50b7:6ba) 20.05.32 *** Saving seen data "./dancer.seen" 20.23.08 Quit jacobk (Ping timeout: 250 seconds) 20.34.30 # Build Server message: 3New build round started. Revision 5dc0e4e0bc, 303 builds, 8 clients. 20.34.30 # 3disk: Support GUID Partition Tables (GPT) by Solomon Peachy 20.49.07 # Build Server message: 3Build round completed after 878 seconds. 20.49.09 # Build Server message: 3Revision 5dc0e4e0bc result: 0 errors 4 warnings 20.58.38 # Build Server message: 3New build round started. Revision 3a8d5525ae, 303 builds, 8 clients. 20.58.38 # 3pdbox: Fix warning with GCC13 by Solomon Peachy 21.01.59 Join jacobk [0] (~quassel@47-186-122-163.dlls.tx.frontiernet.net) 21.11.32 # Build Server message: 3Build round completed after 775 seconds. 21.11.34 # Build Server message: 3Revision 3a8d5525ae result: 0 errors 20 warnings 21.12.06 Quit LjL (Quit: Scappò via con la paura di arrugginire. Il giornale di ieri lo dà morto arrugginito. I becchini ne raccolgono spesso fra la gente che si lascia piovere addosso.) 21.13.28 Join LjL [0] (~ljl@user/ljl) 21.45.02 Quit jacobk (Ping timeout: 250 seconds) 22.04.40 # <_bilgus> speacy i'm still studying it now but at the very 22.04.54 # <_bilgus> least I intend to get a plugin running 22.05.30 # <_bilgus> re playlist I think amachronic has quite a bit of WIP concerning it ATM 22.05.33 *** Saving seen data "./dancer.seen" 22.53.22 Join jacobk [0] (~quassel@47-186-122-163.dlls.tx.frontiernet.net)