- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] AthensCairoSurface not getting garbage collected

by J.F. Rick

I don't have enough evidence either way, but the signs point to no since the applications that crash are not ones that use form-based paints. I assume they wouldn't be affected by the flush. We did have one crash on a form-based one where it crashed after running for 10 hours. My guess is that one ran out of memory. That crash is probably resolved. But, I'll keep everybody informed as I work more on it. Cheers, Jeff On Thu, Jul 7, 2016 at 3:28 AM Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Jeff, does this flush reduces the amount of crash you are experiencing? > > Alexandre > > > On Jul 6, 2016, at 9:01 PM, J.F. Rick <self(a)je77.com> wrote: > > > > Nicolai, > > > > THANKS! That worked. I no longer have any AthensCairoCanvas hanging > around after executing "CairoBackendCache flush". > > > > Cheers, > > > > Jeff > > > > On Sun, Jul 3, 2016 at 11:58 AM Nicolai Hess <nicolaihess(a)gmail.com> > wrote: > > Hi Jeff, > > > > if you use forms to paint on an AthensCairoCanvas, they are cached in > the CairoBackendCache, > > can you try to flush that cache whith > > CairoBackendCache flush. > > > > > > 2016-06-18 18:36 GMT+02:00 J.F. Rick <self(a)je77.com>: > > I'm using Athens rendering for my multi-touch applications on Pharo5. As > part of that, I create a surface: > > surface := AthensCairoSurface extent: bounds extent asIntegerPoint. > > > > Though the object creating that surface is deleted, the surface sticks > around. So, each time I run the app, I get another instance of > AthensCairoSurface hanging around. That means all the forms stick around as > well. So my image can quickly grow towards the 1GB size. > > > > Is there anything I can do about that? Can I manually get the surface > to delete itself? > > > > Cheers, > > > > Jeff > > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > >

July 8, 2016

[Holidays] 14 days no updates: 14th to end of July

by Marcus Denker

Hi, We just saw that everyone who can press the button for a final integration will be on Holidays from July 14 to the end of the month. This means there will be no update, but the issue tracker will stay open of course, so issues can be submitted, fixed and reviewedâ¦ they will just not end up the downloadable image for that 2 weeks. Marcus

July 8, 2016

Re: [Pharo-dev] [pharo-project/pharo-core] ec7b0e: 60137

by stepharo

>>> Do you think professional developers who use Pharo all day like crashes or hangs ? We are all the same here, we want a stable system. >>> >>> It is not certain that the catalog download is the problem. >>> >>> This specific feature that you think should only be enabled by those who want it (you call them pros) is exactly a beginner's feature: a way to discover every external library written. How ironic that you don't care. >> Sven the students we have are not looking for published packages and if they need, they can use the catalog: entering XML and pressing ok >> there is simple enough. It is not a complex ui. Spotter is a lot more confusing than the catalog UI. But dogma says the inverse so I will stop >> arguing. > Well, you won, the feature is gone. No it is not gone. Update your preferences and help fixing the real problem and we will put it back. You see I produce Spotter videos for the mooc. Do you think that I should have spent all this energy for something that I do not like. Now we should be able to critic features. Stef >>> Yes, newcomers hit all kinds of issues that more experienced users subconsciously avoid, being mindful for that is important. I think we all try to do that, by fixing things, not by turning things off. >>> >>> We lack a proper process to decide these kinds of conflicts. >>> >>>> On 08 Jul 2016, at 11:21, stepharo <stepharo(a)free.fr> wrote: >>>> >>>> Again again and again: How many times do you see students having Pharo frozen because the internet connection in the classroom is fleaky. >>>> >>>> Apparently turning off these people is not an issue to you. Perfect but it is one for me. >>>> >>>> For your productivity boost why can't you click on one setting and put it on? >>>> >>>> Tell me I do not understand. In my dev image I have several settings set for my own usage. >>>> >>>> So why you cannot have one extra one? Especially since preferences are loaded automatically. >>>> >>>> >>>> Then when we will find a way to address the real problem we can just turn the setting on. >>>> >>>> I will have spent half of my life showing software to newbies and may I ask you when is the last time >>>> >>>> you show Pharo to a guy that is learning programming? I do that often (may be too often) >>>> >>>> and in bad situation like in Afrika but not only. >>>> >>>> Stef >>>> >>>> >>>> >>>> Le 6/7/16 Ã 20:19, Sven Van Caekenberghe a Ã©crit : >>>>> I'll try once more to explain. >>>>> >>>>> You like the catalog, don't you ? It was your idea in the first place. With this feature you can just type XML, CSV, JSON or whatever and it will suggest a couple of catalog projects that you can install with just one click, no need to open any tool you don't even know. This is especially good for new people. IT IS A FANTASTIC FEATURE, IT IS THE WAY THINGS SHOULD WORK. It leverages all the work put in the catalog. >>>>> >>>>> Is Spotter or any other part of Pharo perfect ? No. >>>>> >>>>> For many people, Spotter make a huge functional difference, we use it every minute. If it would hang or block the image even once a day, any of us would complain loudly. >>>>> >>>>> Conclusion: it works for 99% of the people/cases. >>>>> >>>>> Even in the 1% where there is a problem, it is not 100% sure it is related to the catalog searching. In the last concrete issue reported, the guy tried disabling the catalog searching AND IT MADE NO DIFFERENCE ! >>>>> >>>>> So again, why turn it off ? It is an overreaction, not engineering. >>>>> >>>>> The underlying problem is that in some very rare, hard to reproduce cases we cannot reliably detect that there is no network. That's about it. >>>>> >>>>> Note also that almost every application or app today will do some network calls, this is how the world work - we should be able to do the same with Pharo, not run away and kill every feature that does a network call. >>>>> >>>>>> On 06 Jul 2016, at 18:14, stepharo <stepharo(a)free.fr> wrote: >>>>>> >>>>>> Who vote to put it in? >>>>>> >>>>>> Seriously I think that my main concern is about getting Pharo stable in any occasion and not giving >>>>>> >>>>>> a bad impression of the system. I takes enough time to build traction and such glitches can spoil >>>>>> >>>>>> our effort in no time. "Yes Pharo froze." >>>>>> >>>>>> So it would be nice to care take of such aspect. >>>>>> >>>>>> I do not understand why super users do not manage to put a reference to on in the preferences. >>>>>> >>>>>> Sorry esteban but I do not buy your argument that something off is remove. No it is off. >>>>>> >>>>>> Stef >>>>>>>> On 06 Jul 2016, at 09:52, GitHub <noreply(a)github.com> wrote: >>>>>>>> >>>>>>>> 18674 Turn spotter catalog off by default >>>>>>>> https://pharo.fogbugz.com/f/cases/18674 >>>>>>> We did not agree on this, at all, there was no public discussion, no vote. >>>>>>> >>>>>>> >>> >> > >

July 8, 2016

Re: [Pharo-dev] [pharo-project/pharo-core] ec7b0e: 60137

by Sven Van Caekenberghe

> On 08 Jul 2016, at 12:21, stepharo <stepharo(a)free.fr> wrote: > > > > Le 8/7/16 Ã 11:44, Sven Van Caekenberghe a Ã©crit : >> Do you think professional developers who use Pharo all day like crashes or hangs ? We are all the same here, we want a stable system. >> >> It is not certain that the catalog download is the problem. >> >> This specific feature that you think should only be enabled by those who want it (you call them pros) is exactly a beginner's feature: a way to discover every external library written. How ironic that you don't care. > > Sven the students we have are not looking for published packages and if they need, they can use the catalog: entering XML and pressing ok > there is simple enough. It is not a complex ui. Spotter is a lot more confusing than the catalog UI. But dogma says the inverse so I will stop > arguing. Well, you won, the feature is gone. >> >> Yes, newcomers hit all kinds of issues that more experienced users subconsciously avoid, being mindful for that is important. I think we all try to do that, by fixing things, not by turning things off. >> >> We lack a proper process to decide these kinds of conflicts. >> >>> On 08 Jul 2016, at 11:21, stepharo <stepharo(a)free.fr> wrote: >>> >>> Again again and again: How many times do you see students having Pharo frozen because the internet connection in the classroom is fleaky. >>> >>> Apparently turning off these people is not an issue to you. Perfect but it is one for me. >>> >>> For your productivity boost why can't you click on one setting and put it on? >>> >>> Tell me I do not understand. In my dev image I have several settings set for my own usage. >>> >>> So why you cannot have one extra one? Especially since preferences are loaded automatically. >>> >>> >>> Then when we will find a way to address the real problem we can just turn the setting on. >>> >>> I will have spent half of my life showing software to newbies and may I ask you when is the last time >>> >>> you show Pharo to a guy that is learning programming? I do that often (may be too often) >>> >>> and in bad situation like in Afrika but not only. >>> >>> Stef >>> >>> >>> >>> Le 6/7/16 Ã 20:19, Sven Van Caekenberghe a Ã©crit : >>>> I'll try once more to explain. >>>> >>>> You like the catalog, don't you ? It was your idea in the first place. With this feature you can just type XML, CSV, JSON or whatever and it will suggest a couple of catalog projects that you can install with just one click, no need to open any tool you don't even know. This is especially good for new people. IT IS A FANTASTIC FEATURE, IT IS THE WAY THINGS SHOULD WORK. It leverages all the work put in the catalog. >>>> >>>> Is Spotter or any other part of Pharo perfect ? No. >>>> >>>> For many people, Spotter make a huge functional difference, we use it every minute. If it would hang or block the image even once a day, any of us would complain loudly. >>>> >>>> Conclusion: it works for 99% of the people/cases. >>>> >>>> Even in the 1% where there is a problem, it is not 100% sure it is related to the catalog searching. In the last concrete issue reported, the guy tried disabling the catalog searching AND IT MADE NO DIFFERENCE ! >>>> >>>> So again, why turn it off ? It is an overreaction, not engineering. >>>> >>>> The underlying problem is that in some very rare, hard to reproduce cases we cannot reliably detect that there is no network. That's about it. >>>> >>>> Note also that almost every application or app today will do some network calls, this is how the world work - we should be able to do the same with Pharo, not run away and kill every feature that does a network call. >>>> >>>>> On 06 Jul 2016, at 18:14, stepharo <stepharo(a)free.fr> wrote: >>>>> >>>>> Who vote to put it in? >>>>> >>>>> Seriously I think that my main concern is about getting Pharo stable in any occasion and not giving >>>>> >>>>> a bad impression of the system. I takes enough time to build traction and such glitches can spoil >>>>> >>>>> our effort in no time. "Yes Pharo froze." >>>>> >>>>> So it would be nice to care take of such aspect. >>>>> >>>>> I do not understand why super users do not manage to put a reference to on in the preferences. >>>>> >>>>> Sorry esteban but I do not buy your argument that something off is remove. No it is off. >>>>> >>>>> Stef >>>>>>> On 06 Jul 2016, at 09:52, GitHub <noreply(a)github.com> wrote: >>>>>>> >>>>>>> 18674 Turn spotter catalog off by default >>>>>>> https://pharo.fogbugz.com/f/cases/18674 >>>>>> We did not agree on this, at all, there was no public discussion, no vote. >>>>>> >>>>>> >>>> >>> >> >> > >

July 8, 2016

Re: [Pharo-dev] [pharo-project/pharo-core] ec7b0e: 60137

by stepharo

Le 8/7/16 Ã 11:44, Sven Van Caekenberghe a Ã©crit : > Do you think professional developers who use Pharo all day like crashes or hangs ? We are all the same here, we want a stable system. > > It is not certain that the catalog download is the problem. > > This specific feature that you think should only be enabled by those who want it (you call them pros) is exactly a beginner's feature: a way to discover every external library written. How ironic that you don't care. Sven the students we have are not looking for published packages and if they need, they can use the catalog: entering XML and pressing ok there is simple enough. It is not a complex ui. Spotter is a lot more confusing than the catalog UI. But dogma says the inverse so I will stop arguing. > > Yes, newcomers hit all kinds of issues that more experienced users subconsciously avoid, being mindful for that is important. I think we all try to do that, by fixing things, not by turning things off. > > We lack a proper process to decide these kinds of conflicts. > >> On 08 Jul 2016, at 11:21, stepharo <stepharo(a)free.fr> wrote: >> >> Again again and again: How many times do you see students having Pharo frozen because the internet connection in the classroom is fleaky. >> >> Apparently turning off these people is not an issue to you. Perfect but it is one for me. >> >> For your productivity boost why can't you click on one setting and put it on? >> >> Tell me I do not understand. In my dev image I have several settings set for my own usage. >> >> So why you cannot have one extra one? Especially since preferences are loaded automatically. >> >> >> Then when we will find a way to address the real problem we can just turn the setting on. >> >> I will have spent half of my life showing software to newbies and may I ask you when is the last time >> >> you show Pharo to a guy that is learning programming? I do that often (may be too often) >> >> and in bad situation like in Afrika but not only. >> >> Stef >> >> >> >> Le 6/7/16 Ã 20:19, Sven Van Caekenberghe a Ã©crit : >>> I'll try once more to explain. >>> >>> You like the catalog, don't you ? It was your idea in the first place. With this feature you can just type XML, CSV, JSON or whatever and it will suggest a couple of catalog projects that you can install with just one click, no need to open any tool you don't even know. This is especially good for new people. IT IS A FANTASTIC FEATURE, IT IS THE WAY THINGS SHOULD WORK. It leverages all the work put in the catalog. >>> >>> Is Spotter or any other part of Pharo perfect ? No. >>> >>> For many people, Spotter make a huge functional difference, we use it every minute. If it would hang or block the image even once a day, any of us would complain loudly. >>> >>> Conclusion: it works for 99% of the people/cases. >>> >>> Even in the 1% where there is a problem, it is not 100% sure it is related to the catalog searching. In the last concrete issue reported, the guy tried disabling the catalog searching AND IT MADE NO DIFFERENCE ! >>> >>> So again, why turn it off ? It is an overreaction, not engineering. >>> >>> The underlying problem is that in some very rare, hard to reproduce cases we cannot reliably detect that there is no network. That's about it. >>> >>> Note also that almost every application or app today will do some network calls, this is how the world work - we should be able to do the same with Pharo, not run away and kill every feature that does a network call. >>> >>>> On 06 Jul 2016, at 18:14, stepharo <stepharo(a)free.fr> wrote: >>>> >>>> Who vote to put it in? >>>> >>>> Seriously I think that my main concern is about getting Pharo stable in any occasion and not giving >>>> >>>> a bad impression of the system. I takes enough time to build traction and such glitches can spoil >>>> >>>> our effort in no time. "Yes Pharo froze." >>>> >>>> So it would be nice to care take of such aspect. >>>> >>>> I do not understand why super users do not manage to put a reference to on in the preferences. >>>> >>>> Sorry esteban but I do not buy your argument that something off is remove. No it is off. >>>> >>>> Stef >>>>>> On 06 Jul 2016, at 09:52, GitHub <noreply(a)github.com> wrote: >>>>>> >>>>>> 18674 Turn spotter catalog off by default >>>>>> https://pharo.fogbugz.com/f/cases/18674 >>>>> We did not agree on this, at all, there was no public discussion, no vote. >>>>> >>>>> >>> >> > >

July 8, 2016

Re: [Pharo-dev] [pharo-project/pharo-core] ec7b0e: 60137

by Sven Van Caekenberghe

Do you think professional developers who use Pharo all day like crashes or hangs ? We are all the same here, we want a stable system. It is not certain that the catalog download is the problem. This specific feature that you think should only be enabled by those who want it (you call them pros) is exactly a beginner's feature: a way to discover every external library written. How ironic that you don't care. Yes, newcomers hit all kinds of issues that more experienced users subconsciously avoid, being mindful for that is important. I think we all try to do that, by fixing things, not by turning things off. We lack a proper process to decide these kinds of conflicts. > On 08 Jul 2016, at 11:21, stepharo <stepharo(a)free.fr> wrote: > > Again again and again: How many times do you see students having Pharo frozen because the internet connection in the classroom is fleaky. > > Apparently turning off these people is not an issue to you. Perfect but it is one for me. > > For your productivity boost why can't you click on one setting and put it on? > > Tell me I do not understand. In my dev image I have several settings set for my own usage. > > So why you cannot have one extra one? Especially since preferences are loaded automatically. > > > Then when we will find a way to address the real problem we can just turn the setting on. > > I will have spent half of my life showing software to newbies and may I ask you when is the last time > > you show Pharo to a guy that is learning programming? I do that often (may be too often) > > and in bad situation like in Afrika but not only. > > Stef > > > > Le 6/7/16 Ã 20:19, Sven Van Caekenberghe a Ã©crit : >> I'll try once more to explain. >> >> You like the catalog, don't you ? It was your idea in the first place. With this feature you can just type XML, CSV, JSON or whatever and it will suggest a couple of catalog projects that you can install with just one click, no need to open any tool you don't even know. This is especially good for new people. IT IS A FANTASTIC FEATURE, IT IS THE WAY THINGS SHOULD WORK. It leverages all the work put in the catalog. >> >> Is Spotter or any other part of Pharo perfect ? No. >> >> For many people, Spotter make a huge functional difference, we use it every minute. If it would hang or block the image even once a day, any of us would complain loudly. >> >> Conclusion: it works for 99% of the people/cases. >> >> Even in the 1% where there is a problem, it is not 100% sure it is related to the catalog searching. In the last concrete issue reported, the guy tried disabling the catalog searching AND IT MADE NO DIFFERENCE ! >> >> So again, why turn it off ? It is an overreaction, not engineering. >> >> The underlying problem is that in some very rare, hard to reproduce cases we cannot reliably detect that there is no network. That's about it. >> >> Note also that almost every application or app today will do some network calls, this is how the world work - we should be able to do the same with Pharo, not run away and kill every feature that does a network call. >> >>> On 06 Jul 2016, at 18:14, stepharo <stepharo(a)free.fr> wrote: >>> >>> Who vote to put it in? >>> >>> Seriously I think that my main concern is about getting Pharo stable in any occasion and not giving >>> >>> a bad impression of the system. I takes enough time to build traction and such glitches can spoil >>> >>> our effort in no time. "Yes Pharo froze." >>> >>> So it would be nice to care take of such aspect. >>> >>> I do not understand why super users do not manage to put a reference to on in the preferences. >>> >>> Sorry esteban but I do not buy your argument that something off is remove. No it is off. >>> >>> Stef >>>>> On 06 Jul 2016, at 09:52, GitHub <noreply(a)github.com> wrote: >>>>> >>>>> 18674 Turn spotter catalog off by default >>>>> https://pharo.fogbugz.com/f/cases/18674 >>>> We did not agree on this, at all, there was no public discussion, no vote. >>>> >>>> >>> >> >> > >

July 8, 2016

Re: [Pharo-dev] lineConversion for WriteStream

by stepharo

Tx monty this is cool! Le 8/7/16 Ã 09:44, monty a Ã©crit : > If you upgrade XMLParser, the DOM file printing methods like printToFileNamed: now automatically use your OS's linebreak, and XMLWriter, which always allowed setting the linebreak, now has an option to detect your OS's linebreak and use that. > > Sent: Thursday, May 26, 2016 at 2:20 PM > From: "Peter UhnÃ¡k" <i.uhnak(a)gmail.com> > To: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > Subject: Re: [Pharo-dev] lineConversion for WriteStream > > Well I was saving e.g. STON or XML fileâ¦ but some apps outside didn't particularly like itâ¦ even `cat` doesn't like CR. > Anyway; this is not system-breaking problem, just annoying. > > Peter > > On Thu, May 26, 2016 at 2:50 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> On 26 May 2016, at 14:06, Peter UhnÃ¡k <i.uhnak@gmail.com[i.uhnak@gmail.com]> wrote: >> >> >> >> On Thu, May 26, 2016 at 1:40 PM, Sven Van Caekenberghe <sven@stfx.eu[sven@stfx.eu]> wrote: >> >>> On 26 May 2016, at 13:29, Peter UhnÃ¡k <i.uhnak@gmail.com[i.uhnak@gmail.com]> wrote: >>> >>>> In general I would say that you should write either something platform specific or you write something specific >>> Except that I cannot do that because the system doesn't support neither. >>> And the fact that the default line ending is CR is just bullshitâ¦ it's 2016, not 1986. >> Yes, that CR is from days long gone ;-) >> >>> or #cr #lf or #crlf as needed, and/or make that last one a parameter (OSPlatform current lineEnding). >> I am piping unknown content into the file, thus the need for `lineEndConvention:` and the reason of this entire thread. So as I said, the system doesn't support it. >> I know I can use #lf or whatnot, but I am not creating the content, I am saving it. >> >> Peter > Well, maybe I don't understand your use case, but if you do not know what is inside, why not save it as is, binary even, not doing any conversions ? > > > >

July 8, 2016

Re: [Pharo-dev] lineConversion for WriteStream

by stepharo

> So it looks to me like LF wins! > It may take a while and some effort, but can we agree on a three point strategy? > 1. Default CR line ending must change! > 2. Change it to LF. > 3. Default auto-conversion of "text" input to LF? Would be so nice :) > > [1] https://en.wikipedia.org/wiki/Newline#History > [2] https://blog.codinghorror.com/the-great-newline-schism/ > [3] http://www.zdnet.com/article/microsoft-and-canonical-partner-to-bring-ubunt… > [4] https://insights.ubuntu.com/2016/03/30/ubuntu-on-windows-the-ubuntu-userspa… > > cheers -ben > >>> Anyway; this is not system-breaking problem, just annoying. >>> >>> Peter >>> >>> On Thu, May 26, 2016 at 2:50 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> >>>> On 26 May 2016, at 14:06, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >>>> >>>> >>>> >>>> On Thu, May 26, 2016 at 1:40 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>> >>>>> On 26 May 2016, at 13:29, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >>>>> >>>>>> In general I would say that you should write either something platform specific or you write something specific >>>>> Except that I cannot do that because the system doesn't support neither. >>>>> And the fact that the default line ending is CR is just bullshitâ¦ it's 2016, not 1986. >>>> Yes, that CR is from days long gone ;-) >>>> >>>>> or #cr #lf or #crlf as needed, and/or make that last one a parameter (OSPlatform current lineEnding). >>>> I am piping unknown content into the file, thus the need for `lineEndConvention:` and the reason of this entire thread. So as I said, the system doesn't support it. >>>> I know I can use #lf or whatnot, but I am not creating the content, I am saving it. >>>> >>>> Peter >>> Well, maybe I don't understand your use case, but if you do not know what is inside, why not save it as is, binary even, not doing any conversions ? >>> >>> >>> >> >

July 8, 2016

Re: [Pharo-dev] lineConversion for WriteStream

by stepharo

Le 26/5/16 Ã 13:29, Peter UhnÃ¡k a Ã©crit : > > In general I would say that you should write either something > platform specific or you write something specific > > Except that I cannot do that because the system doesn't support neither. > And the fact that the default line ending is CR is just bullshitâ¦ it's > 2016, not 1986. + 1 now the strategy to switch smootly is not clear to me. In addition I would love to kill all the stream hierarchy. > > On Thu, May 26, 2016 at 12:37 PM, Sven Van Caekenberghe <sven(a)stfx.eu > <mailto:sven@stfx.eu>> wrote: > > MultiByteFileStream is terrible (too complex) because it does too > much (at once). Let's keep WriteStream simple (and even simplify > it). You do not want characters that change magically. > > That being said, line end conventions can be a pain. In general I > would say that you should write either something platform specific > (you can fetch the EOL terminator somewhere), or you write > something specific (say CRLF for web stuff), while during reading > you should accept anything (that is easy to do). You know: be > strict in what you produce, liberal in what you accept. > > > On 26 May 2016, at 11:39, Peter UhnÃ¡k <i.uhnak(a)gmail.com > <mailto:i.uhnak@gmail.com>> wrote: > > > > Is there a reason why only MultiByteFileStream provides > lineEndConvention: and not WriteStream? > > > > The problem is that if I use MemoryStore in tests it breaks, > because DiskStore and MemoryStore return different write streams. > > > > '/tmp/test.txt' asFileReference writeStream ==> > "MultiByteFileStream: '/tmp/test.txt'". > > (FileSystem memory / 'test.txt') writeStream ==> "a WriteStream" > > > > Can we either: > > > > a) have `lineEndConvention:` directly in the WriteStream, or > > b) have MemoryStore return MultiByteFileStream, or > > c) both? > > > > Thanks, > > Peter > > >

July 8, 2016

Re: [Pharo-dev] [squeak-dev] Time now print24

by stepharo

+ 1 Iso is really good. Because in France the format is the inverse than in english so months and days are really confusing. In addition Iso works really well for sorting files. Stef Le 8/7/16 Ã 11:23, Sven Van Caekenberghe a Ã©crit : >> On 08 Jul 2016, at 10:49, Tobias Pape <Das.Linux(a)gmx.de> wrote: >> >> >> On 07.07.2016, at 18:33, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> >>> Hi All, >>> >>> how does one produce a nice timestamp, simply date and time as in >>> >>> 7/7/2016 09:19:38 >> What's with 'TimeStamp now' (prints '8 July 2016 10:34:36 am') >> >> or this one: >> >> TimeStamp now in: [:t | >> String streamContents: [:s | >> t asDate printOn: s format: #(2 1 3 $/ 1 1 2). >> s space. >> t asTime print24: true showSeconds: true on: s]] >> >> Too bad TimeStamp is deprecated in Pharo4, so this works in pharo: > Yes, it is gone. It was a subclass whose only feature was a different print representation. It was also confusing, why choose it or DateAndTime. > > We folded TimeStamp's functionality into DateAndTime (see #printSeparateDateAndTimeOn: and #readSeparateDateAndTimeFrom:) > >> DateAndTime now rounded in: [:t | >> String streamContents: [:s | >> t asDate printOn: s format: #(2 1 3 $/ 1 1 2). >> s space. >> t asTime print24: true showSeconds: true on: s]] >> >> But DateAndTime knows no #rounded in Squeak, buuut: >> >>> ======================= >> This works for both: >> >> >> DateAndTime now in: [:t | >> String streamContents: [:s | >> t asDate printOn: s format: #(2 1 3 $/ 1 1 2). >> s space. >> t printHMSOn: s]] >> >> ===== >> >> Best regards >> -Tobias >> >> PS: I'd prefer ISO, nonetheless: https://xkcd.com/1179/ > Yes, that was my point exactly. Thanks for the cool link! > > In the same line, the AM/PM don't make sense, and the timezone (or Z) is required. > > https://en.wikipedia.org/wiki/ISO_8601 > > Something like 2016-07-08 08:41:52 Z or 2016-07-08 08:41:52 +00:00 is perfectly readable. > > BTW, these are unambigiously parseable as well (for example, using ZTimestamp). > > ZTimestamp readFromString: '2016-07-08 08:41:52 Z'. > > "2016-07-08T08:41:52Z" > > ZTimestamp readFromString: '2016-07-08 08:41:52 +00:00'. > > "2016-07-08T08:41:52Z" > > Using ZTimestampFormat, which is an example based formatter/parser, like Go's, you can easily produce this slightly more human friendly format. > > (ZTimestampFormat fromString: '2001-02-03 16:05:06 +00:00') format: DateAndTime now. > > "'2016-07-08 11:16:54 +02:00'" > > And the reverse (obviously you share/predefine/cache the specific format object). > > (ZTimestampFormat fromString: '2001-02-03 16:05:06 +00:00') createDateAndTime; parse: '2016-07-08 11:16:54 +02:00'. > > "2016-07-08T11:16:54+02:00" > >> (or the German way: 25.12.2015 :P) >> >> >> >>> Trivial, right? >>> >>> So >>> >>> Date today mmddyyyy, ' ', Time now print24 '7/7/2016 09:22:40.914' >>> >>> .914, ah, nanos. How useful. Let's get rid of them. No nanos: accessor so >>> >>> Date today mmddyyyy, ' ', (Time now nanos: 0) print24 => MNU >>> >>> but there's a seconds accessor, so >>> >>> Date today mmddyyyy, ' ', (Time now seconds: Time now seconds; print24) '7/7/2016 00:00:41 >>> >>> ?? So seconds: is private, and isn't the dual of Time seconds: >>> >>> Time seconds >>> ^ self second >>> Time second >>> ^ self asDuration seconds >>> Duration seconds >>> "Answer the number of seconds the receiver represents." >>> ^seconds rem: SecondsInMinute >>> >>> Looks broken to me. >>> >>> Personally I think print24 should not print sub seconds. >>> >>> cc'ing to Pharo because I want this timestamp to be the same in both dialects for a profiling tool we want to use in both dialects. >>> _,,,^..^,,,_ >>> best, Eliot >> >> > >

July 8, 2016