- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [pharo-project/pharo-core] a813b2: 60138

by stepharo

Ben have a look at the deprecated:with: or transform: it is so great.... it rewrites the code on the fly so now we can deprecate, run code and save updated packages :) Stef Le 7/7/16 Ã 01:47, Ben Coman a Ã©crit : > On Thu, Jul 7, 2016 at 12:52 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >>> On 06 Jul 2016, at 18:16, stepharo <stepharo(a)free.fr> wrote: >>> >>> I always found such kind of changes totally obscure and it would be nice to have a description. >>> >> > The point I took from Stef's question is... not just getting a > followup description here in the mail list, but could this text you've > typed here.... > >> Fixes issues: >> >> - 18450 GT-Tools: "Do not use #ifNotNilDo:ifNil:, #ifNil:ifNotNilDo:, #ifNotNilDo:" >> - 18453 GT-Tools: "do not use #ifEmpty:ifNotEmptyDo: #ifNotEmptyDo: #ifNotEmptyDo:ifEmpty:â >> - 18431 attach glmpopplers shortcut to the textarea instead of the scroll pane >> - Esteban's change to GLMAction > ...in future be added as the Log message instead of just "Moose" so > there is a permanent record in our package history. > >> This was mostly me pushing for getting the trivial things *DONE* and not wait another 3 weeksâ¦ >> >> (I should have just committed slices, the overhead with committing and syncing is to high for >> trivial refactorings) > Sure, buts lets document this. Since anyway we'll just ask for a > followup in the mail list ;) and I presume it takes more effort to go > back and look these up after the fact, than copy-pasting at > integration time. > > cheers -ben >> Marcus > P.S. Not to take your efforts doing the integrations for granted, > thanks for regularly doing this task. > >

July 8, 2016

Re: [Pharo-dev] [pharo-project/pharo-core] a813b2: 60138

by stepharo

Le 6/7/16 Ã 18:52, Marcus Denker a Ã©crit : >> On 06 Jul 2016, at 18:16, stepharo <stepharo(a)free.fr> wrote: >> >> I always found such kind of changes totally obscure and it would be nice to have a description. >> > > Fixes issues: > > - 18450 GT-Tools: "Do not use #ifNotNilDo:ifNil:, #ifNil:ifNotNilDo:, #ifNotNilDo:" > - 18453 GT-Tools: "do not use #ifEmpty:ifNotEmptyDo: #ifNotEmptyDo: #ifNotEmptyDo:ifEmpty:â > - 18431 attach glmpopplers shortcut to the textarea instead of the scroll pane > - Esteban's change to GLMAction > > This was mostly me pushing for getting the trivial things *DONE* and not wait another 3 weeksâ¦ Great. I love this runtime deprecation transform it will really help us to move faster. Tx for building it. I love it. :) > > (I should have just committed slices, the overhead with committing and syncing is to high for > trivial refactorings) Yes :) I hope one day (soon) we will be able to get a lot faster on our pullrequests. > Marcus >

July 8, 2016

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

by Sven Van Caekenberghe

> 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

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

by stepharo

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] [squeak-dev] Time now print24

by Tobias Pape

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: 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/ (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

Re: [Pharo-dev] lineConversion for WriteStream

by monty

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] Having comments for pragma?

by Tudor Girba

Hi, Ok, great. I will play with this. Cheers, Doru > On Jul 7, 2016, at 11:19 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi Doru, > >> On Jun 30, 2016, at 1:08 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >> Hi, >> >>> On Jun 27, 2016, at 7:55 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >>> >>> Hi Doru, >>> >>> On Mon, Jun 27, 2016 at 6:36 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>> Hi Eliot, >>> >>> I agree with most things you say (except the conclusion :)), and I think that we are talking about complementary issues. >>> >>> As I mentioned before, there already is a need to distinguish between a plain selector and one that is associated with pragmas. This is what you find in PragmaType in Spotter and Inspector. This is a kind of meta-object and having it adds value. I can search for pragmas âtypeâ (we can also call it a PragmaSelector), and I can distinguish between all occurrences of a pragma âtypeâ and its utilization in computation. But, the current implementation of PragmaType is a mere pseudo-meta-object, given that it has no casual connection to the runtime. >>> >>> What we know from Smalltalk is that the analysis model does not have to differ from the runtime one. The consequence is that every time we do see a difference, we should investigate because we might uncover a hidden need opportunity. >>> >>> I know the VW model, and indeed, we could have something like: >>> >>> MyConcept class>>myPragmaDefinition >>> âa comment about the pragma" >>> <pragma: #selector> >>> >>> However, this only deals with the definition of the pragma type not with the internal representation. There could still well be an object that encapsulates both the selector and the comment. And that object would also allow us to build tools around it. We could call it a PragmaType, PragmaDefinition, or even PragmaSelector. And we could get the Pragma to point to this type either through an inst var or through a query (I would probably prefer an instvar). >>> >>> Well, there already /is/ a meta-object called Pragma, and it gets instantiated when one accesses the compiled method via pragmas: >>> >>> (CompiledMethod allInstances detect: [:m| m pragmas size > 1]) pragmas collect: [:ea| {ea. ea class}] {{<export: true> . Pragma} . {<var: #tablePtr type: 'int *'> . Pragma}} >> >> Yes I know :). An instance of Pragma denotes an concrete annotation of a method. I now would like a meta-object that describes all Pragma instances having the same selector. For example, the protocol on the class side of the Pragma class is actually a query protocol that is better suited for the instance side of a PragmaDescription meta-object. For example: >> >> Pragma class>>allNamed: aSymbol in: aClass >> >> would become >> >> PragmaDescription>>pragmasIn: aClass >> >> and you would use it like: >> >> (PragmaDescription named: aSymbol) pragmasIn: aClass >> >> Creating an instance of PragmaDescription would imply searching the image for the <pragma:> definition. > > I like this. > >> I would also like to have a Flyweight pool per environment such that we always get only one instance of a PragmaDefinition per selector (like it happens with Symbols). > > Yes, good refinement. > >>> So we could add the information you want to Pragma, and have it be lazy. >> >> It does not quite belong to the Pragma. A comment is common to all Pragma instances, and having it duplicated at the instance level is less elegant. >> >> But, looking for the users (all senders of the pragma selector - the methods that use the annotation) of a Pragma would be even less inconvenient to have on the instance side of Pragma. >> >> >>> The Pragma could go search for the defining class-side pragma methods and use the parser to extract the comment(s) when asked. Hence simple access to pragmas, interested only in the selectors for applying, wouldn't have their performance be impacted. >> >> The design sketched above would require no runtime penalty for a Pragma instance. All code that works now would work identically afterwards. We would only have one selector in Pragma to get the corresponding description: >> >> Pragma>>description >> ^ PragmaDescription named: self selector >> >> Alternatively, we could modify the compilation to associate the PragmaDescription in an inst var of a Pragma instance. So, CompiledMethod>>pragmas would always return instances of Pragmas with a PragmaDefinition inst var. >> >> I think I would start with the lazy lookup first, and this would disturb nothing from the current behavior. > > Sounds like a reasonable plan. > >> >> >>> I think that this proposition does not remove from the simplicity of the implementation at all, but allows the new needs to be accommodated nicely. The alternative is to not do anything, in which case we will continue to have an analysis-only-pseudo-meta-object which is not nice at all. I do not think we should jump on this lightly, but I do think we should have a critical look and evaluate the options. >>> >>> This pseudo-meta-object (Pragma) can sty ill be causally connected, in the same way that a MethodReference can be causally connected. The causation is things like "remove", "recompile", but that's dubious. It's essentially a read-only relationship; one wants to be able to locate the method from the pragma, but changing the method from the pragma isn't necessarily a good idea. Would you agree that convenience methods like "remove" on MethodReference are a bad idea and one should stick to the removeSelector: protocol on Behavior and ClassDescription? >>> >>> >>> What do you think? >>> >>> Have I and enough coffee to scramble my thoughts might be a more pertinent question ;-) >> >> :) >> >> Cheers, >> Doru >> >> >>> >>> Cheers, >>> Doru >>> >>> >>>> On Jun 27, 2016, at 2:39 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >>>> >>>> Hi Doru, >>>> >>>>> On Jun 27, 2016, at 3:52 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>>>> >>>>> Hi, >>>>> >>>>> The CompiledMethod already has a way to retrieve Pragma instances: >>>>> >>>>> CompiledMethod>>pragmas. >>>>> >>>>> However, the Pragma instance does not have a meta-object associated with it. So, I would first start from adding that one and linking such a PragmaType to its instances. The important thing here would be that all Pragma instances with a certain selector should reference the same PragmaType. >>>> >>>> Let me express a dissenting opinion. Our pragma system is minimal yet powerful. By using Message instances (with literal arguments) to represent pragmas we get >>>> - executable pragmas that can be applied using perform: or wrappers such as sentTo: >>>> - we can use conventional browsing queries (implementors and senders) to discover which methods are marked by a specific pragma and what pragma-processing tools implement a specific pragma. >>>> - a rich pragma language that can have many, named parameters >>>> - a system which doesn't need its own language, but reuses the existing Smalltalk parsing facilities, and so is easier to learn and to implement >>>> >>>> So its parsimony is an important part of its virtues. It is minimal. >>>> >>>> One thing missing from the Squeak/Pharo implementation is the set of legal pragmas a class accepts. In VisualWorks a class implements the <pragma: #pragma:selector:> (it might be <pragmas: #(pragma:selector:one: pragma:selector:two:)>) to define the legal set of pragmas. [Implementation note, these are /not/ searched for ahead of compilation; instead, the parser delays searching for class-side methods containing pragma: pragmas until it encounters a pragma, and it searches for all class side methods, including in superclasses). >>>> >>>> This scheme allows pragmas to be checked; only pragmas in the set of allowed pragmas are accepted, and it allows collision-free extensibility; any package can add a set of legal pragmas to a class merely by choosing a method selector that won't collide with any other containing pragma: pragmas, eg >>>> kernelPragmas >>>> <pragma: #primitive:> >>>> <pragma: #primitive:error:> >>>> <pragma: #primitive:module:> >>>> <pragma: #primitive:module:error:> >>>> >>>> We're missing this, which means our compilers don't safely check for valid pragmas and can't reject invalid or unrecognized ones, which is error prone. >>>> >>>> If we implemented this then we would have a natural place to comment pragmas in the method that defines a particular pragma, one that would be found using senders. >>>> >>>> None of this requires a meta object. It is perfectly recursive; using itself to implement itself. I find this very elegant (I didn't invent pragma: pragmas; Steve Dahl did, and it's a cool idea). >>>> >>>> So as an inventor of pragmas I'd like to ask for the minimal implementation outlined above. I'd like that we didn't j tricycle a specific meta object, with all the additional tools that implies, and instead stick to the minimalist and parsimony of the original design and use pragmas to comment pragmas. >>>> >>>>> Cheers, >>>>> Doru >>>> >>>> Thanks for reading. >>>> Cheers, Eliot >>>> >>>>>> On Jun 27, 2016, at 12:34 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: >>>>>> >>>>>> >>>>>> 2016-06-27 12:12 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: >>>>>> Hi, >>>>>> >>>>>> That is my proposal as well: introduce a first class entity that describes a Pragma instance. Who would be interested to play with this? >>>>>> >>>>>> How it could be done? >>>>>> Probably compiler could search preferred Pragma class for given selector. And then we will have collection of real pragma instances inside CompiledMethod. What do you think? >>>>> >>>>> -- >>>>> www.tudorgirba.com >>>>> www.feenk.com >>>>> >>>>> "Be rather willing to give than demanding to get." >>> >>> -- >>> www.tudorgirba.com >>> www.feenk.com >>> >>> "When people care, great things can happen." >>> >>> >>> >>> >>> >>> >>> >>> >>> -- >>> _,,,^..^,,,_ >>> best, Eliot >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "Not knowing how to do something is not an argument for how it cannot be done." -- www.tudorgirba.com www.feenk.com "To lead is not to demand things, it is to make them happen."

July 8, 2016

Re: [Pharo-dev] Time now print24

by Eliot Miranda

Hi All, > On Jul 7, 2016, at 9:33 AM, 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 > > 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. Let me be more explicit, and ask for permission to fix this. One basic bug is the asymmetry between seconds, an accessor that answers seconds mod 60, and seconds: that doesn't set seconds mod 60. But seconds: is private and could be replaced by eg setTotalSeconds:, presumably without breaking clients, allowing seconds: to be redefined to do the right thing. I note that the historic bug of changing the semantics of Time now to answer something with finer resolution than one second could have been avoided by adding eg exactlyNow or preciselyNow. The problem with nanos (apart from the horrible abbreviation) is that it presumes a maximum precision that isn't well chosen. Microseconds work out much better. And I hope we change the internal representation accordingly. But there needs to be done accessor that rounds to the nearest second without revealing the internal precision. Time now toTheNearestSecond or Time theNearestSecondNow or...? > > 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

Re: [Pharo-dev] Time now print24

by Cyril Ferlicot D.

Le 07/07/2016 Ã 18:33, Eliot Miranda a Ã©crit : > Hi All, > > how does one produce a nice timestamp, simply date and time as in > > 7/7/2016 09:19:38 > > Trivial, right? Hi Eliot, At synectique, for a simple solution, we added a class extension: `DateAndTime>>asSynectiqueFormat ^ '{1} {2}' format: {(self asDate mmddyyyy). (self asTime print24 first: 8)}` But it's true that a user will not need the milliseconds most of the time. It would be nice to have this kind of methods directly inside Pharo/Squeak. > > 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 -- Cyril Ferlicot http://www.synectique.eu 165 Avenue Bretagne Lille 59000 France

July 7, 2016

Re: [Pharo-dev] Time now print24

by Eliot Miranda

Hi Sven, > On Jul 7, 2016, at 9:47 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > >> On 07 Jul 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 >> >> Trivial, right? > > I understand that you want it 'nice and clean', but the above is not precise (no TZ) and confusing (is it M/D/YYYY or D/M/YYYY ?). > > Going more in the ISO direction is better (more universal), IMHO. > > DateAndTime now rounded => "2016-07-07T18:45:12+02:00" My use case is providing a human-readable time stamp on a benchmark output so something really simple is what's best and the full tu stamp you give above exactly opposite to what I want; verbose and hard to read. > >> 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 7, 2016