#metabrainz

I've reopened https://tickets.metabrainz.org/browse/MBS-3775

MBS-3775: Add a cancel radio button in edit search

The absence of such a feature is rather punishing for beginners.

@Mr_Monkey which code is deployed in test.bookbrainz.org? I don't think it's master branch of bookbrainz repo - it doesn't have merge feature yet

@Mr_Monkey Nvm I found the feature-merge PR.

iliekcomputers: did it work?

right, their creative work is the algorithm, even though it is mostly implementing a monkey-typewriter, not the melodies.

It's more this emphasizes that scores are not the (only) creative part of a musical work.

chaban: agreed, and thanks

(It does need to be done carefully to avoid them cancelling stuff by mistake, but it should still be doable)

pristine__: it should automatically do its work in ~2h20m.

moooin

iliekcomputers: I've had this strange problem that has wasted a few hours of my time already...

but I've got a new container for the timescale_writer proof of concept.

and the uwsgi.service script attempts to call the timescale writer.

yet nothing happens.

if I enter the container and run the script by hand, it works fine with the same invocation as the script uses.

have you ever seen that?

do you get this log (https://github.com/metabrainz/listenbrainz-serv...) or not even that

no.

interesting

so the uwsgi file is not even being called

any chance you can push a branch?

it is called. I've put debug statements in it and the right exec statement is called.

and if I do `python3 -m listenbrainz.timescale_writer.timescale_writer` from the shell, it fires right up

ruaok: could it be the case that the docker logs are not being directed correctlhy

i've seen that happen

(no idea how to fix though)

is possible, yes.

I do get some output, but it is from brainzutils and the base image.

but once it exec's my code, silence.

yeah, that sounds like it's not logging correctly, i'd try to verify if listens are being written some other way

to confirm that it's just not logging

well, the code doesn't seem to receive anything yet, so I suspect incorrect rmq settings. or impatience. lol.

but let me have it touch a file and see.

confirmed. just a logging issue.

iliekcomputers: when you've seen this issue happen, under what circumstances was it?

also an exec?

zas: ping

my new favorite shell alias. `alias dps='docker ps | colrm 16 88'`

remove useless column and fit the whole thing in a more normal sized window.

ruaok: yes

was it to python or something else?

I would not be surprised if some of our Prod containers did not have logs showing up right now

Python only afaik

odd. https://stackoverflow.com/questions/29663459/py...

adding -u to the script invocation works.

(unbuffered output)

I personally think it has something to do with us starting up an app object to setup logging.

the only output I see is the print()

ruaok: pong

I just solved the issue I was going to ask about. nm. :)

perfect ;)

you're magic.

!m zas

You're doing good work, zas!

:P

well he does good work anyway

iliekcomputers: ok, one question solved. the -u works because the container crashes before the max buffer size is reached and the output is not flushed on crash.

now why I am not getting a stacktrace out of this, is another matter.

ah! no traceback because it dies in the rmq callback.

foo() bar() Mr_Monkey !

welcome back, in more than one meaning. :)

Hello all, I am Sweta Vooda currently pursuing a bachelors in technology in Information Technology.

it.

Welcome sweta05 !

iliekcomputers: listens are now being written to timescale as well. now to leave this for a while and observer.

the load on wetton (where timescale is) is 0.01. And I think that load comes from top, really.

yvanzo, bitmap: I'm on a bus but so far the wifi works

So if you want to have a meeting and review stuff or whatever, up for it