Oh let's talk about joblogs

bonjour,

You can put everything in “try” and try as you might
, but I’ll let the users have a look, so it’s no fun.

mon translteur deepl but it played tricks on me

I did a lot of work on dates (unpublished), I paid for a lot of reading, a lot of discussions with the AI about disagreements, I got kicked out, I took out a subscription… there’s a difference between finding a number and answering a problem.

All that to say that following up when there’s material, for the AI doc great, but how do you keep a history, sometimes so valuable.

Do you have any ideas? A real history saves you so much time; I really liked the IBM AS400 one.

I tried not to be a robot and to laugh a bit.

Everything in “unreachable”, sure of your shot, a closed program, but it’s not every day, and still 3 years later ???.

There’s the one that makes @panic messages with @SRC, but do we have to put them everywhere often, we have a routine heinnnn , I’ll skip the details,

there’s the scoped, houin for debug ok after too much blabla not readable program, I did not say the message.

I like the linux journal, but unless you’ve really worked on it, it’s not much fun, and your friend GREP has his limits.

But I’ve also thought of a mini-server that would write to an SQLite database if it’s ready,
where you’d have the user, date, time, error level (numeric), first-level text (the preview) and second-level text (the constituent), the server just writes, it’s studious, it doesn’t answer :wink:
it cut grrr it mixed snif


Hello, I have been looking into ways to have logs.

I can’t bring myself to put “try,” “unreachable” everywhere.

Using “@panic” is useful, but it doesn’t solve everything.

The log_scoped option is interesting, but it’s difficult to handle the history (thought about the server, too many files).

So, I reminded myself how IBM manages the joblog on OS400.

To adapt it to the PC world,

I thought of a mini-server that would handle archiving, for example in an SQLite database, with a structure that allows quickly tracking a user, the error level, the primary message, and then the secondary message if applicable.

It should not normally be heavily used for operational applications.

deepl pas à la hauteur pour du courrier là j’ai pris Mistral

Bonjour, hônettement j’ai pas compris c’est que vous avez écrit.

Aussi, je vous conseil deepl pour traduir, personellement je trouve c’est mieux de google translate.

Hi @JPL,

Whatever you use to translate your messages, maybe try a different translator, or rephrase your message, because it currently is undecipherable what you are actually talking about.

3 Likes