Previous day | Jump to hour: 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | Next day

Seconds: Show Hide | Joins: Show Hide | View raw
Font: Serif Sans-Serif Monospace | Size: Small Medium Large

Click in the nick column to highlight everything a person has said.
The Logo icon identifies that the person is a core developer (has commit access).

#rockbox log for 2024-05-18

00:03:56 Quit rudi_s (Ping timeout: 260 seconds)
00:04:14 Join rudi_s [0] (~simon@user/rudi-s/x-7673890)
00:30:08 Nick spork_ is now known as spork (topic@213-234-20-31.ftth.glasoperator.nl)
00:39:50 Quit massiveH (Quit: Leaving)
00:46:50***Saving seen data "./dancer.seen"
02:00
02:02:22 Quit amiconn (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.)
02:02:22 Quit pixelma (Quit: .)
02:03:20 Join amiconn [0] (jens@p4fe7632b.dip0.t-ipconnect.de)
02:03:23 Join pixelma [0] (marianne@p4fe7632b.dip0.t-ipconnect.de)
02:05:17 Quit Bobathan- (Ping timeout: 256 seconds)
02:09:42 Join Bobathan [0] (~admin@syn-065-029-248-157.res.spectrum.com)
02:46:51***Saving seen data "./dancer.seen"
03:00
03:00:58 Join lebellium [0] (~lebellium@2a01cb0405d07f009c9bc2bf3bb91400.ipv6.abo.wanadoo.fr)
03:08:26 Join lebellium_ [0] (~lebellium@2a01cb0405d07f00e959a6b9ae2455be.ipv6.abo.wanadoo.fr)
03:11:08 Join lebellium__ [0] (~lebellium@2a01cb0405d07f009c9bc2bf3bb91400.ipv6.abo.wanadoo.fr)
03:12:30 Quit lebellium (Ping timeout: 268 seconds)
03:14:29 Quit lebellium_ (Ping timeout: 240 seconds)
03:35:52 Nick Marqueteur is now known as TorC (~Tor@fsf/member/TorC)
04:00
04:03:29 Join Bobathan- [0] (~admin@syn-065-029-248-157.res.spectrum.com)
04:03:35 Quit Bobathan (Ping timeout: 264 seconds)
04:46:52***Saving seen data "./dancer.seen"
06:00
06:46:57***No seen item changed, no save performed.
08:00
08:47:00***No seen item changed, no save performed.
08:58:57 Quit CH23[m] (Ping timeout: 256 seconds)
08:59:30 Join CH23[m] [0] (~CH23@revspace/participant/ch23)
10:00
10:20:12 Join l0x0l [0] (~l0x0l@user/l0x0l)
10:37:01dookhttps://gist.github.com/D0-0K/db591e9ef8c58dce2d84d91e76457068
10:37:07dookWould someone be able to look over this code for me?
10:37:23dookAdmittedly my C knowledge is pretty poor, but I'm attempting to get the setting name set to qs top and then take that setting name to get it's value.
10:37:57dookI'm unsure how I should properly take the output of the first line as a char pointer.
10:47:03***Saving seen data "./dancer.seen"
11:00
11:07:04 Quit martylake (Ping timeout: 260 seconds)
11:08:22 Join davisr [0] (~davisr@fsf/emeritus/davisr)
11:20:54braewoodsdook, ... why did you think this woudl work?
11:21:29braewoodsthis is a struct pointer. this isn't something you can treat like a char pointer safely under normal situations.
11:21:54braewoodsyou can throw that out the window if you really do know better but i generally don't recommend it.
11:25:29braewoodsah this is a tagged union struct.
11:25:47dookbraewoods inexperience, I'm not that familiar with C yet.
11:26:05braewoodsdook, open settings_list.h
11:26:22braewoodsfind the struct and see the fields for yourself. likely what you want is in there somewhere.
11:27:01braewoodscfg_name and cfg_vals in particular.
11:27:32 Quit CH23[m] (Read error: Connection reset by peer)
11:27:46 Join CH23[m] [0] (~CH23@revspace/participant/ch23)
11:27:59dookI'll take a look at that, thank you!
11:28:16braewoodsand if you're not familiar with tagged unions, how you use them depends on the implementation, but typically one of the regular fields will indicate which of the union fields is actually in use.
11:28:23braewoods(in use meaning has valid data)
11:29:28braewoodsso you need you to do code conditionally based on the type, or just assume one in particular is in use for specific cases? what's correct depends heavily on understanding the implementation.
11:29:49braewoodslike knowing what will never be possible given the code flow.
11:30:11braewoodsif you don't know it that well, probably best to follow what other code is doing or just plan for the worst case.
11:30:38braewoodspays to be careful when dealing with C.
11:30:47braewoodsthere's literallly no guard rails.
11:31:04braewoodsif you tell it to do something stupid, it'll do it.
11:31:23dookYeah, I'm definitely learning that the hard way. I tried a few different ways of getting the same result and it would crash or read from the wrong part of the memory
11:31:50braewoodsi assume due to a lack of awareness of pointers.
11:32:30braewoodsare you familiar with memory allocation methods?
11:32:40braewoodsaka pointer lifetime and such.
11:33:38braewoodsThe same principles for userspace C apply to rockbox though implementations vary.
11:33:52dookPointer lifetime, no. My knowledge with C is pretty much the basics, I probably don't have the expertise to be even trying to do this
11:34:28braewoodsThere's 3 ways to allocate memory in most C environments. Stack, Heap, and Static.
11:35:03braewoodsFunctions allocate their variables on the stack or in registers (implementation defined).
11:36:07braewoodsTheir variables go out of scope when the function returns.
11:36:21braewoodsSo pointers to them are only good for that period.
11:37:04braewoodsStack allocation is small, fixed size, and fast.
11:37:22braewoodsIt can be reused indefinitely as long as it doesn't overflow.
11:38:07dookAh, that makes sense
11:38:48braewoodsStatic variables are allocated in a fixed region of memory dedicated to special storage. It can't grow and always consumes space but pointers to it are valid for the entire program's lifecycle.
11:39:15braewoodsThis is how global variables are allocated.
11:39:16braewoodsAs well.
11:39:27braewoodsBut it also applies to any variable with 'static' keyword.
11:40:07braewoodsAnd the last one is a very special case. Heap allocations aka dynamic memory allocations are very vast.
11:40:21braewoodsBut most of them come with an allocator and deallocator routine.
11:40:35braewoodsFor userspace C this is malloc / calloc / realloc and free.
11:40:59braewoodsRockbox has its own allocator library. I don't recall the names off hand.
11:41:47braewoodsThe lifetime of these pointers depends on the implementation but usually it will persist until the pointer is returned to the heap via the deallocator.
11:42:32braewoodsOnce a pointer becomes invalid, it is an error to dereference it as the data is no longer in a known state.
11:42:58braewoodsMore specificially, undefined behavior. Anything can happen.
11:43:39braewoodsAnd a pointer just stores a memory address. It says where to go looking for the given data.
11:44:10braewoodsWhen a memory address is no longer considered valid, the pointer likewise becomes invalid until it contains a valid address.
11:45:26braewoodsEvery pointer must be backed by memory so when learning to do with them you need to consider the memory allocation as well to know if you are using it correctly. "Will this pointer remain valid under all circumstances that I am using or storing it under?"
11:46:34braewoodsThis is the most basic thing you need to be aware of when trying to use pointers correctly. If your pointers are garbage then you won't get good results except by random chance.
11:46:49braewoodsThe next thing is whether the data at the given address is usable or not.
11:47:10braewoodsIf the memory pointed to is uninitialized, then you also get 'undefined behavior'.
11:47:28braewoodsYou can see this if you try to use local variables without setting a value first.
11:48:40braewoodsStatic storage is always initialized, but stack and heap are not.
11:49:54braewoodsThat's all I can think of for a basic pointer introduction.
11:50:12dookThank you, it's really helpful
11:50:34dookI can understand where my approach was incorrect. I can think of a few ideas to go forward with this too
11:50:42braewoodsMost of which is just advanced techniques involving particular design patterns or usages.
11:51:00braewoodsFunction pointers, etc.
11:51:52braewoodsdook, in particular be careful of chaining too many '->' together.
11:52:07braewoodsIf any of the pointers are invalid in the chain, you've got a problem.
11:53:13dookYeah, that would be difficult to debug if I had too many
11:53:16braewoodsI tend to try to check for NULL whenever it is possible, even if the chance is very slim (small heap allocations failing for example).
11:54:30braewoodsIf you need to practice, you may want to write userspace C instead for that. Far easier to test on your main system.
11:55:28braewoodsAnd, for the record, 'userspace' is 'hosted' in the standard. It's the C variant used for most programs written for a regular platform.
11:55:50braewoodsRockbox is 'freestanding' because it's closer to a kernel than userspace.
11:57:14braewoodsGiven my past experience with bootloaders, can't say I enjoy writing embedded C stuff. Even the most trivial of changes can cause a hang.
11:58:10dookThat's a good idea
11:58:12braewoodsI recall having bootloaders that compiled badly because of some issue with the toolchain that didn't manifest at all in regular programs.
11:58:49braewoodsPC bootloaders even... Good grief was that annoying.
11:59:07 Quit gevaerts (Ping timeout: 260 seconds)
11:59:19braewoodsReally low level code seems particularly fragile.
12:00
12:16:21 Join CH23 [0] (~CH23@revspace/participant/ch23)
12:33:49 Join gevaerts [0] (~fg@user/gevaerts)
12:39:56 Join martylake [0] (~martylake@82.66.174.242)
12:46:09 Quit CH23[m] (Read error: Connection reset by peer)
12:46:31 Join CH23[m] [0] (~CH23@revspace/participant/ch23)
12:47:07***Saving seen data "./dancer.seen"
12:53:23 Quit CH23[m] (Read error: Connection reset by peer)
12:53:42 Join CH23[m] [0] (~CH23@revspace/participant/ch23)
13:00
13:02:40 Quit davisr (Remote host closed the connection)
13:17:12 Quit user890104 ()
13:40:18 Quit martylake (Remote host closed the connection)
13:41:20 Join martylake [0] (~martylake@82.66.174.242)
14:00
14:19:38 Quit lebellium__ (Quit: Leaving)
14:44:53 Join lebellium [0] (~lebellium@2a01cb0405d07f00910a1eb6219a0712.ipv6.abo.wanadoo.fr)
14:47:11***Saving seen data "./dancer.seen"
15:00
15:04:03 Join jacobk [0] (~quassel@47-186-70-49.dlls.tx.frontiernet.net)
15:07:55 Join Jinx`` [0] (~Jinx@c-73-161-149-159.hsd1.mi.comcast.net)
15:38:13 Join user890104 [0] (~Venci@freemyipod/user890104)
15:51:47 Quit user890104 ()
15:52:24 Join user890104 [0] (~Venci@freemyipod/user890104)
15:56:13 Quit user890104 (Client Quit)
15:57:21 Join user890104 [0] (~Venci@freemyipod/user890104)
16:00
16:47:14***Saving seen data "./dancer.seen"
16:57:33 Join braewoods_ [0] (~braewoods@user/braewoods)
16:58:11 Quit braewoods (Read error: Connection reset by peer)
18:00
18:11:06 Quit pookie (Ping timeout: 255 seconds)
18:21:55 Join olspookishmagus [0] (~pookie@snf-137798.vm.okeanos.grnet.gr)
18:45:35 Quit lebellium (Quit: Leaving)
18:47:18***Saving seen data "./dancer.seen"
18:55:15 Join massiveH [0] (~massiveH@2600:4040:a982:c800:a87f:6c54:9a96:c310)
19:00
19:52:45 Quit advcomp2019__ (Ping timeout: 256 seconds)
20:00
20:30:18 Join advcomp2019 [0] (~advcomp20@user/advcomp2019)
20:47:22***Saving seen data "./dancer.seen"
20:52:21 Join othello7 [0] (~Thunderbi@pool-100-36-176-164.washdc.fios.verizon.net)
22:00
22:47:24***No seen item changed, no save performed.
22:59:28 Quit othello7 (Read error: Connection reset by peer)
23:00
23:00:05 Join othello7 [0] (~Thunderbi@pool-100-36-176-164.washdc.fios.verizon.net)

Previous day | Next day