1429

pretty hard to continue.  maybe with some time I can understand how to respond to the guy.

i'll move forward and testing the stable code with the test app.  then i'll try adding my change.  if I ever finish, i'll plan to tell the guy, "hey what you said was kinda confusing to me, so I just did it".

1430

tmux reloading panes again

1431

1432

gotta bring raid array up.  looks like my usb hub is unpowered.

1434

gotta reboot android 

1435

k test time

1436

test passed.  which gives me working code and shows me how to rebuild this project at the same time.  i'll try removing the extra set option call, and look at appropriate control flow logic hopefully.

okay.  I remember now.  wait.  no.  I don't.

1438

1439

the first confusing thing is the check in libusb_init .  it passes the default options to the backend again only if no ctx pointer was bpassed, and there is no default ctx pointer.

ok, so it only passes them, if it is making a new default ctx ptr.

meanwhile, the old android flag had set a static flag and ignored the ctx pointer.

my new code associates the flag with the ctx instead.  currently unstable.

the current code still ignores the ctx pointer.

1442

so, the current tip code assumes that options are associated with ctxs.  if no ctx is passed, it stores them as defaults: but it only passes them on if creating a default ctx.

so there's maybe a tiny leakish, for this use, in hjelmn's code where defaults set with no context, are unused if the user sets a context

and something else with harbulot's code

with the old android code, defaults were set for the context before it was created.

this could mean passing them on, even if the context is not the default.

alternatively, the intent of hjelmn's code could have been to set options on context storage before it is initialised.  I guess that seems a little unsafeish to me, unsure, nobody's mentioned trying it I guess.

1445

so what's the plan

seems most direct to pass defaults in whether a new default context is made or not

alternatively we could stay near the current code, and set defaults when the option is passed, and read straight from the defaults.

I thought of two approaches to the option situation I might as well add as comments to a different issue

- options could be passed on an uninitialised context

- the backend could be refactored to initialise on use, so that early options can be passed after it is constructed

regarding the first option, it seems that the user only has control of context pointer storage, so that's not too workable unless allocation is separated from initialisation

k I submitted those ideas to their issue for such ideas

1454

ok um

copypaste: seems most direct to pass defaults in whether a new default context is made or not

alternatively we could stay near the current code, and set defaults when the option is passed, and read straight from the defaults.

it seems more compatible a little to keep the approach I currently have of setting the defaults in the option handler, and reading from them to manage the options.

this is similar to the solution bits made by the visiting contributer.

1455

current issues include:

- deadlock, roughly resolved

- segfault?  let's see what he addressed

right.  my option handler checks wrt null.

this issue should go away if duplicate passing goes away.

but basically, it's ok to reset it if the value is unchanged ... I guess ... maybe ...?  i'll try looking at it!

I think I might be able to complete this!

1459