From Lydia Sobot to ~sircmpwn/sr.ht-discuss
>> My question is whether it is possible to record the information >> received in this form in srht.site? It would be nice to have it as a >> csv file. > >short answer is no. >For that form to work you'll need your own server with proper software. >But if collecting questionnaire is what you need, I bet there are >pletheora of online collaberation tools that you can use out-of-the-box. > >I can't recommend any though, since I don't use them personally. Might I suggest https://riku.miso.town/
From Lydia Sobot to ~rabbits/uxn
On Mon Nov 25, 2024 at 13:24 CET, Karol Belina wrote: > Looks like the channel type of your screen is not handled by the SDL2 > port, which would explain why it works in drawterm (which probably > sets it to a generic RGB24 or XRGB32 or whatever). > > Could you, in npe/libnpe_sdl2/sdl2.c, at the start of the chan2mask > function just before the switch, add something along the lines of > fprint(2, "--- my channel: %08x ---\n", chan); and then mk install > npe, mk clean and mk install uxn, and see what uxnemu prints out > before crashing on the assert? We could then try to add your channel > to the switch in chan2mask and set the masks appropriately. > > (For example, on my machine the number printed out is 68081828, which > means XRGB32, based on the definitions in /sys/include/draw.h)
From Lydia Sobot to ~rabbits/uxn
> What architecture are you running it on? amd64 > I would probably start with > inspecting the assertion more closely, could you please run uxnemu > (and hit the assertion), get its process id, run acid <pid> and print > the stack trace with stk()? Sure, here is the stack trace: /proc/622/text:amd64 plan 9 executable /sys/lib/acid/port /sys/lib/acid/amd64 acid: stk() abort()+0x0 /sys/src/libc/9sys/abort.c:6
From Lydia Sobot to ~rabbits/uxn
Hi, I recently tried to use uxnemu on 9front. Unfortunately, it immediately fails with a trap from a failed assertion (it builds fine, but just in case I tried to screw around with the npe headers, no dice), namely, quite plainly: 630.1 x: assertion failed I then have to not only clean up the broken process, but also manually delete the spawning window, as it seems to have thoroughly broken any kind of input in the window even though it promptly crashed. Even more strangely, I can run it just fine on a VM but through drawterm, even though it complains about no audio (which I don't have on the VM
From Lydia Sobot to ~alias/services
Thanks :) applied with minor changes To git@git.sr.ht:~alias/student-docs 0bd67c1..aff285c main -> main
From Lydia Sobot to ~alias/polybase-devel
Applied, me dumb dumb To git@git.sr.ht:~alias/polybase b509d05..67a365b master -> master
From Lydia Sobot to ~alias/polybase-devel
Thanks :) applied with fixes Indeed this needs to be rehauled but good enough for now To git@git.sr.ht:~alias/polybase 3f532ba..51ad80d master -> master
From Allen Sobot to ~sircmpwn/sr.ht-discuss
Also sidenote but wouldn't this make build lists disjointed resulting in build status images not reporting the correct status? If so maybe a more elaborate collaborator check would have to be implemented
From Allen Sobot to ~sircmpwn/sr.ht-discuss
>IIUC, it's not only related to secrets (which indeed can be shared), but also to the current usage of sharing a repository in an organization-like account and using that repository to run CI jobs with a common paying account (as suggested at https://man.sr.ht/ops/builds.sr.ht-migration.md). > >So previously, if ~user (identified by their SSH key) pushed to ~org/repo, the job was run with ~org account. Now it is run with ~user account. So, previously, this worked as ~org is paying, but now it does not as ~user is not paying. Yes indeed basically
From Allen Sobot to ~sircmpwn/sr.ht-discuss
>This is by design -- sharing secrets is the intended approach now.
I see, fair enough, but until organizations are implemented what about the case of collaborator accounts?