April 2024 - Pharo-users - lists.pharo.org

[ANN] Pharo 12 Release !

by Esteban Lorenzano

Dear Pharo users and dynamic language lovers: We have released Pharo <https://pharo.org/> version 12! What is Pharo? Pharo is a pure object-oriented programming language and a powerful environment focused on simplicity and immediate feedback. * Simple & powerful language: No constructors, no types declaration, no interfaces, no primitive types. Yet a powerful and elegant language with a full syntax fitting in one postcard! Pharo is objects and messages all the way down. * Live, immersive environment: Immediate feedback at any moment of your development: Developing, testing, debugging. Even in production environments, you will never be stuck in compiling and deploying steps again! * Amazing debugging experience: Pharo environment includes a debugger unlike anything you've seen before. It allows you to step through code, restart the execution of methods, create methods on the fly, and much more! * Pharo is yours: Pharo is made by an incredible community, with more than 100 contributors for the last revision of the platform and hundreds of people constantly contributing with frameworks and libraries. * Fully open-source: Pharo full stack is released under MIT <https://opensource.org/licenses/MIT> License and available on GitHub <https://github.com/pharo-project/pharo> ... more on the Pharo Features page <http://www.pharo.org/features>. In this iteration of Pharo, we continue working on our objectives of improvement, clean-up and modularization. Also, we included a number of usability and speed improvements. A complete list of changes and improvements is available in our Changelog <https://github.com/pharo-project/pharo-changelogs/blob/master/Pharo120Chang…> Some highlights of this amazing version: Highlights New breakpoint system The debug point system is a breakpoint model that supersedes the previous implementation of breakpoints and watchpoints. They are configurable, composable, and extensible. The traditional breakpoints remain available, including conditional breakpoints, one-time breakpoints, and object-centric breakpoints. Additionally, there are new types of breakpoints, such as chained-breakpoints, which condition the activation of certain breakpoints on the triggering of others (e.g., breakpoint B only activates if breakpoint A is hit first). Debug points also feature a dedicated browser and integration options. Tools * Scalable fluid class syntax is now the default one * Preparing the introduction of the Bloc graphic system by migrating more tools to Spec2 widgets * Spec2 UI framework enhancements to support GTK 4 * Leaner version of the Metacello package manager * More robust and strict mode for FFI System * New architecture for refactorings and domain specific transformations * Code loading speed improvement * Fast browsing via fully optimized package tags * Optmized memory usage via optimized method protocols * Compiler simplifications and improvements Virtual machine * Massive image support with permanent space * String/ByteArray comparison speed up Development Effort This new version is the result of 1895 Pull Requests integrated just in the Pharo repository. We have closed 865 issues and received contributions from more than 70 different contributors. We have also a lot of work in the separate projects that are included in each Pharo release: * http://github.com/pharo-spec/NewTools <https://github.com/pharo-spec/NewTools> * http://github.com/pharo-spec/NewTools-DocumentBrowser <https://github.com/pharo-spec/NewTools-DocumentBrowser> * http://github.com/pharo-spec/Spec <https://github.com/pharo-spec/Spec> * http://github.com/pharo-vcs/Iceberg <https://github.com/pharo-vcs/Iceberg> * http://github.com/ObjectProfile/Roassal3 <https://github.com/ObjectProfile/Roassal3> * http://github.com/pillar-markup/Microdown <https://github.com/pillar-markup/Microdown> * http://github.com/pillar-markup/BeautifulComments <https://github.com/pillar-markup/BeautifulComments> * http://github.com/pharo-project/pharo-vm <https://github.com/pharo-project/pharo-vm> Contributors We always say Pharo is yours. It is yours because we made it for you, but most importantly because it is made by the invaluable contributions of our great community (yourself). A large community of people from all around the world contributed to Pharo 12.0 by making pull requests, reporting bugs, participating in discussion threads, providing feedback, and a lot of helpful tasks in all our community channels. Thank you all for your contributions. The Pharo Team Discover Pharo: https://pharo.org/features Try Pharo: http://pharo.org/download <https://pharo.org/download> Learn Pharo: http://pharo.org/documentation <https://pharo.org/documentation>

April 26, 2024

[ANN] docker-pharo-vm v10.1.0-2024-04-25 [v10.1.0 [2024-04-25]] released!

by Buenos Aires Smalltalk

April 25, 2024

Re: [Esug-list] [ANN] Soil release v1

by Tim Mackinnon

That's really exciting news... appreciate you sharing it with the wider community (I know when you mentioned its existence a while back I went and watched the Esug recordings to get more info, and looked at some of the extensive test cases to get a feel on what it looked like - its neat). Having multiple options for persisting data (from simple Fuel up to Soil and Glorp and Gemstone) is very useful. Tim On Wed, 24 Apr 2024, at 12:52 PM, Norbert Hartl wrote: > ...we said at last ESUG that there will be a release soonish but as usual it doesn't go that fast. > > But now we are very happy to announce that Soil has a first public release v1. So what is soil? > > Soil is an object oriented database in pharo <http://pharo.org/>. It is transaction based having ACID transactions. It has binary search capabilities with SkipList and BTree+ indexes. It aims to be a simple yet powerful database making it easy to develop with, easy to debug with, easy to inspect, ... > > More details at https://github.com/ApptiveGrid/Soil > > This release is still considered early stage because > > â¢ although in ApptiveGrid there are over 4000 instances of it and there are other users there isn't a wider range of use cases, yet. So it is not fully battle tested. This just as reminder when you start compaining I need somewhere to point my finger to and say "I told you!" ;) > â¢ there are few things missing that you might expect like garbage collection, etc. > > So but it is definetely usable and awaiting the brave ones of you to try. > > Hopy you enjoy it! > > Norbert & Marcus > _______________________________________________ > Esug-list mailing list -- esug-list(a)lists.esug.org > To unsubscribe send an email to esug-list-leave(a)lists.esug.org >

April 24, 2024

[ANN] Soil release v1

by Norbert Hartl

...we said at last ESUG that there will be a release soonish but as usual it doesn't go that fast. But now we are very happy to announce that Soil has a first public release v1. So what is soil? Soil is an object oriented database in pharo <http://pharo.org/>. It is transaction based having ACID transactions. It has binary search capabilities with SkipList and BTree+ indexes. It aims to be a simple yet powerful database making it easy to develop with, easy to debug with, easy to inspect, ... More details at https://github.com/ApptiveGrid/Soil This release is still considered early stage because although in ApptiveGrid there are over 4000 instances of it and there are other users there isn't a wider range of use cases, yet. So it is not fully battle tested. This just as reminder when you start compaining I need somewhere to point my finger to and say "I told you!" ;) there are few things missing that you might expect like garbage collection, etc. So but it is definetely usable and awaiting the brave ones of you to try. Hopy you enjoy it! Norbert & Marcus

April 24, 2024

This week (16/2024) on the Pharo Issue Tracker

by Marcus Denker

# Bugs - Fix bug while adding a trait to a class without trait #16473 https://github.com/pharo-project/pharo/pull/16473 - Restore fileIn button in File Browser #16470 https://github.com/pharo-project/pharo/pull/16470 - Do not select the # in symbol selection #16469 https://github.com/pharo-project/pharo/pull/16469 - 16447-Dropping-window-outside-of-Pharo-window-borders-closes-the-window #16467 https://github.com/pharo-project/pharo/pull/16467 - 16355-Wrong-class-definition-creates-strange-DNUs #16466 https://github.com/pharo-project/pharo/pull/16466 - Fix: PullUpClassVar was not checking breaking change preconditions #16464 https://github.com/pharo-project/pharo/pull/16464 - fix access to false positive in Renraku #16457 https://github.com/pharo-project/pharo/pull/16457 - Fix #visitBehaviorRepackagedChange: on EpHasImpactVisitor to send #not instead of #y #16449 https://github.com/pharo-project/pharo/pull/16449 - 16365 Add subclass can create trait subclasses #16442 https://github.com/pharo-project/pharo/pull/16442 - Clean package generation of "Jump to test class" #16434 https://github.com/pharo-project/pharo/pull/16434 - Add LibTTY providing access to the VM library for spawning a process connected to a pseudo-terminal #16427 https://github.com/pharo-project/pharo/pull/16427 - fix: Socket>>#waitForSendDoneFor: does not return a boolean (but ZdcSocketStream expects it to) #16425 https://github.com/pharo-project/pharo/pull/16425 - Update the Playground shortcut #16422 https://github.com/pharo-project/pharo/pull/16422 - Fix code highlighting in debug points browser, for debug points set on AST node #726 https://github.com/pharo-spec/NewTools/pull/726 - fix layouts #1539 https://github.com/pharo-spec/Spec/pull/1539 - Adding textChanged notification to SpStringTableColumn #1360 https://github.com/pharo-spec/Spec/pull/1360 # Cleanup - Removing old object-centric breakpoint's integration to the inspector #733 https://github.com/pharo-spec/NewTools/pull/733 - Changed protocol for displayStringOn: to displaying #737 https://github.com/pharo-spec/NewTools/pull/737 - Change superclass of StDebuggerTest from TestCase to SpBaseTest #740 https://github.com/pharo-spec/NewTools/pull/740 - Removing old breakpoint system's integration to Calypso #16397 https://github.com/pharo-project/pharo/pull/16397 - reuse of #isFalsePositive:forRuleId:versionId: in #falsePositiveOf: #16475 https://github.com/pharo-project/pharo/pull/16475

April 23, 2024

UKSTUG meeting - Tudor GÃ®rba: What exactly is Glamorous Toolkit? - 24 April 2024

by UK Smalltalk

To some people Glamorous Toolkit is a Pharo environment. To others itâs a knowledge management system. Others might see a code analysis platform, a data visualization or an API browsing tool. Yet others see the graphical stack with its interactive editors. Glamorous Toolkit is all of these. But itâs really also none of these. These are merely examples of the many forms the environment can be molded to. And there can be many more. Glamorous Toolkit is primarily an environment that makes it possible to create many experiences seamlessly and contextually. This then leads to a new way of programming that we call Moldable Development. Tudor GÃ®rba is a software environmentalist and the CEO of feenk.com ( http://feenk.com/ ) where he works with an amazing team to make the inside of systems explainable. Much of the work is embodied in Glamorous Toolkit ( gtoolkit.com) a novel environment that enables moldable development. This will be an online meeting from home. If you'd like to join us, please sign up in advance on the meeting's Meetup page ( https://www.meetup.com/ukstug/events/300575234/ ) to receive the meeting details. Donât forget to bring your laptop and drinks!

April 22, 2024

Re: How to log pharo output to stdio safely?

by Tim＠testit.works

Hey Guillermo what Iâve notice is that if you need to guarantee a line of text is output (as you do for logging before a critical operation) then you : Transcript show: âsome log stringâ; cr Doesnât show output when piped to stdio (as when headless mode running on a server). If non critical then Iâm sure you can wait for a full buffer, but to get guaranteed output the magic line (and I notice that the BA Bell library does the same ) is: Transcript show: âsome log stringâ; cr; flush You need the cr AND the flush - the image comment mentions sync - BUT this give a prim failure on Ubuntu Linux - for which I will raise an issue (although Richard says itâs a grey area anyway). Given the prevalent use of âcr; show:â in the image, I had hoped we could flush a line without a cr, but that doesnât work (and probably doesnât make sense in the wider world where log tools want a guaranteed line to parse into log format). If we want Pharo to play nicely in server environments we should discourage crTrace writing in the image and adopt traceCr writing OR better still have some log writing interface we all use (with some common logfmt conventions like error level) that maps to the transcript but has indirection to map to another log provider. This said - Beacon works well, and tools generating events do let you easily plug in your own and easily write show:ââ;cr conventions yourself. This was the case with Zinc which was nice. Tim > On 19 Apr 2024, at 08:17, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > ï»¿Hi Tim, > > In general, doing a flush should suffice. > Generally, the buffer is flushed automatically when full. > You generally donât need to flush manually unless you are in a special case (like, youâre about to quit the process and you want to flush the buffer before quitting). > > About the comment, would you mind opening an issue with the exact information, I donât really get the issue from the blob of text :) > > G > >> El 18 abr 2024, a las 5:16â¯p. m., Tim Mackinnon <tim(a)testit.works> escribiÃ³: >> >> 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(a)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

April 20, 2024

Re: How to log pharo output to stdio safely?

by Richard O'Keefe

In the C world, - flush forces data from user-space buffers to OS buffers - sync forces data from OS buffers to devices - there is no standard documented way to force devices to move data from buffers to persistent storage even when the device has such an operation and the OS knows how to use it. Is it the same in Pharo? On Fri, 19 Apr 2024 at 19:16, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > Hi Tim, > > In general, doing a flush should suffice. > Generally, the buffer is flushed automatically when full. > You generally donât need to flush manually unless you are in a special case (like, youâre about to quit the process and you want to flush the buffer before quitting). > > About the comment, would you mind opening an issue with the exact information, I donât really get the issue from the blob of text :) > > G > > El 18 abr 2024, a las 5:16â¯p. m., Tim Mackinnon <tim(a)testit.works> escribiÃ³: > > 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(a)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 - 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 > >

April 19, 2024

Re: How to log pharo output to stdio safely?

by Guillermo Polito

Hi Tim, In general, doing a flush should suffice. Generally, the buffer is flushed automatically when full. You generally donât need to flush manually unless you are in a special case (like, youâre about to quit the process and you want to flush the buffer before quitting). About the comment, would you mind opening an issue with the exact information, I donât really get the issue from the blob of text :) G > El 18 abr 2024, a las 5:16â¯p. m., Tim Mackinnon <tim(a)testit.works> escribiÃ³: > > 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(a)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 <http://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

April 19, 2024

[ANN] docker-pharo-runtime v11.0.0-2024-04-18 [v11.0.0 [2024-04-18]] released!

by Buenos Aires Smalltalk

April 18, 2024