Just as a comment on this - I tried using #sync as an experiment and I get a primFailed on an Ubuntu docker image - so I think that comment in the image is misleading (or its a bug, or unfinished work)
On Thu, 18 Apr 2024, at 11:15 AM, Tim Mackinnon wrote: > Hi Stef - I was aware of that class - but a good reminder to re-read it for > any extra info, but I don't see anything in particular mentioned about how > data is flushed - and I think this is one of those black arts from in the > field. > > It looks like stdio uses an Stdiostream - and I did note an interesting > comment in #flush which mention #sync and > "When writing, this syncs any written/flushed data still in the kernel file > system buffers to disk. This should generally be used after #flush, but on > Windows they do the same thing." > > I've never heard of #sync before - and I wonder if the trick to getting > output without the cr is to do a "flush; sync" operation? > > But even then, I am thinking that a server based logging tool is going to > need a cr on a log line to know how to interpret it and parse it into syslog > format, so perhaps I can't escape moving the a trailing cr policy - and just > try to make sure most of my logging adopts that standard (and just accept the > odd corruption when other libraries write out crTrace?). > > I'm just curious how others handle this kind of stuff in the wild - maybe I > should ask on a Seaside list as they are more likely to delve into this (or > maybe the Gemstone guys). > > Its a world you don't normally pay attention to until you try and run > something on a server and want to use the modern tools available in that > world. > > Tim > > On Thu, 18 Apr 2024, at 6:43 AM, stephane ducasse wrote: >> just out of my mind and before breakfast :) >> >> did you see Stdio ? >> >> S >> >>> On 18 Apr 2024, at 01:31, Tim Mackinnon <tim@testit.works> wrote: >>> >>> Hi - I've been messing around with deploying a hobby pharo app to the web.. >>> which has become a lot simpler over the years, although the tech keeps >>> changing and you have to relearn things. >>> >>> Anyway, I have my image in one of the wonderful BA Docker containers, and >>> it runs well - and the host I'm using will show the logs for you, so you >>> can figure out what is going on... well that is if your logs come out >>> properly (and of course, if it gets really hairy then you can get a VNC >>> session onto the image and figure stuff out) >>> >>> So logs are handy, and pharo these days has a nice headless mode that >>> redirects the Transcript to stdout - and there are also a few decent >>> logging frameworks as well. >>> >>> But as most things go to the Transcript, and that goes to stdout - it >>> should be good. >>> >>> HOWEVER - flushing is the killer, as if things happen and the last thing >>> goes wrong, but the output isn't flushed, then you aren't going to see it. >>> >>> So my question is how to properly flush? And I'm sure I've read something >>> about this before, but I can't find it. >>> >>> From memory, you often need to have a Transcript cr. to flush your last >>> line. >>> >>> BUT, most things in the image seem to use "self crTrace:" these days, >>> which is a cr to ensure the previous msg is separated from what you want to >>> write, and then you write your line out. However, as there is now cr - you >>> might not see it. >>> >>> So I tried changing my stuff to use "self traceCr:" (which is in the >>> image), and that still didn't seem to work - the last failing line wasn't >>> being output. Worse still, its confusing, as many things in the image are >>> using crTrace: and so you get intermingled messages, which are hard to >>> decipher. >>> >>> So I tried: Transcript cr; show: msg; flush >>> >>> But that didn't seem to work (which I don't understand) >>> >>> Eventually I did: Transcript show: msg; cr; flush >>> >>> And this seems to ensure things do reliably get outputted - but I'm >>> wondering if anyone can shed light on this areas? >>> >>> Ideally I want to use: Transcript cr'; show: msg; flush >>> >>> As this plays much better with everything that is in the image - but is >>> there some way to do this? And indeed, will log tools the Bettersatack or >>> papertail play ball with output like this (as I guess they operate on >>> complete lines to interpret log levels etc), >>> >>> Anyway - I'm curious if anyone else has done work in this area to shed >>> light? >>> >>> Thanks, >>> >>> Tim >>> >>> >>> As an aside - for deployment - several years ago I came across dockerize.io >>> - which lets you upload a Docker image to a host, and it will run it for >>> you. Sadly that service didn't survive... but there are quite a few like it >>> now, and so I'm trying Render.com <http://render.com/> - which is similar, >>> but the twist is you need to store a Docker image in a registry somewhere >>> (I use gitlab from my CI pipeline), and then it will retrieve it and run it >>> for you (for either free in 40 minute chunks, or for $7/m - which is pretty >>> good, and possibly bit simpler than Digital Ocean). Its pretty cool, and >>> maybe I will write up about it sometime >> >> Stéphane Ducasse >> http://stephane.ducasse.free.fr >> 06 30 93 66 73 >> >> "If you knew today was your last day on earth, what would you do >> differently? ....ESPECIALLY if, by doing something different, today might >> not be your last day on earth.” Calvin & Hobbes >> >> >
