July 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] lineConversion for WriteStream

by monty

You could silently make all #cr methods write/return LFs instead, but that would break existing code that actually expects messages like Character class>>#cr or Character class>>#lf to use the character they're named after (Smalltalk/X actually does something like this and it's caused me grief). A safer way would be adding a new message like #lineEnding/#newLine defined everywhere #cr and #lf are and change uses of #cr as a line ending (for example, splitting on it, or sending #cr to a write stream) in the image to the new message. > Sent: Friday, July 08, 2016 at 5:43 AM > From: stepharo <stepharo(a)free.fr> > To: pharo-dev(a)lists.pharo.org > Subject: Re: [Pharo-dev] lineConversion for WriteStream > > > > 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 10, 2016

changing compiled byte arrays

by Peter UhnÃ¡k

Is this normal behavior? cls := Object subclass: #Something. cls compile: 'array ^ #[1 2 3 4]'. cls new array. "#[1 2 3 4]" cls new array at: 1 put: 55. cls new array. "#[55 2 3 4]" (cls>>#array) sourceCode "'array ^ #[1 2 3 4]'" So I can permanently change the compiled byte array in the method, which is weird. Shouldn't the behavior be either a) don't change the original byte array or b) change the source code Thanks, Peter

July 9, 2016

Re: [Pharo-dev] inconsistent FileReference

by Sven Van Caekenberghe

> On 09 Jul 2016, at 15:31, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > it is not inconsistent, last option is incorrect and should not be used. yes - I believe as well that we discussed this some time ago ... > what you do there is to declare: directory âtmp', file âa/b/c.txtâ > is casual that it coincides with a real path, but it is not semantically correct, thatâs why x ~= z > > there was an issue around to explicitly forbid to declare a file like that, but I was (and still am) not sure it should be forbiddenâ¦ is not the spirit of smalltalkâ¦ you know, great power/great responsibility thing :) > > but it causes confusions (as this one), so at least needs to be correctly explained somewhere :) > > cheers, > Esteban > >> On 09 Jul 2016, at 13:11, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >> >> Imagine that you have >> >> '/tmp/a/b' folder containing 'c' file >> >> '/tmp/a/b' asFileReference ensureCreateDirectory. >> '/tmp/a/b/c' asFileReference writeStreamDo: [ :s | s nextPutAll: 'contents' ]. >> >> now there are three ways how you can see the contents of the c file >> >> x := '/tmp/a/b/c.txt' asFileReference. >> y := '/tmp' asFileReference / 'a' / 'b' / 'c.txt'. >> z := '/tmp' asFileReference / 'a/b/c.txt'. >> >> They clearly all point to the same file: >> >> x contents = y contents "true" >> x contents = z contents "true" >> >> Yet the last option is different >> >> x = y "true" >> x = z "false" >> >> Why is that? Because the parent is different: >> >> x parent pathString "'/tmp/a/b'" >> y parent pathString "'/tmp/a/b'" >> z parent pathString "'/tmp'" >> >> So the parent is based on how the reference was constructed, not what it is actually pointing to, which is stupid. >> >> Is this a bug? Is this a (nasty) expected behavior? >> >> Peter > >

July 9, 2016

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/60142 Home: https://github.com/pharo-project/pharo-core

July 9, 2016

[pharo-project/pharo-core] 0fe882: 60142

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 0fe8828aed520e8c28699f857272389cd563a56f https://github.com/pharo-project/pharo-core/commit/0fe8828aed520e8c28699f85… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-07-09 (Sat, 09 Jul 2016) Changed paths: M Morphic-Widgets-Basic.package/PluggableButtonMorph.class/instance/initialization/initialize.st R Morphic-Widgets-FastTable.package/FTFilterFunctionWithAction.class/instance/accessing/beExplicite.st A Morphic-Widgets-FastTable.package/FTFilterFunctionWithAction.class/instance/accessing/showWidget.st R Morphic-Widgets-FastTable.package/FTFunction.class/instance/accessing/beExplicite.st A Morphic-Widgets-FastTable.package/FTFunction.class/instance/accessing/showWidget.st R Morphic-Widgets-FastTable.package/FTFunctionWithField.class/instance/accessing/beExplicite.st A Morphic-Widgets-FastTable.package/FTFunctionWithField.class/instance/accessing/showWidget.st R Morphic-Widgets-FastTable.package/FTNilFunction.class/instance/accessing/beExplicite.st A Morphic-Widgets-FastTable.package/FTNilFunction.class/instance/accessing/showWidget.st M Morphic-Widgets-FastTable.package/FTTableMorph.class/class/accessing/defaultBackgroundColor.st M Morphic-Widgets-FastTable.package/FTTableMorph.class/instance/accessing/explicitFunction.st A Polymorph-Widgets.package/ToolDockingBarMorph.class/instance/accessing/gradientRamp.st R Polymorph-Widgets.package/ToolDockingBarMorph.class/instance/as yet unclassified/gradientRamp.st R Polymorph-Widgets.package/ToolDockingBarMorph.class/instance/as yet unclassified/normalFillStyle.st R Polymorph-Widgets.package/ToolDockingBarMorph.class/instance/as yet unclassified/updateColor.st R Polymorph-Widgets.package/ToolDockingBarMorph.class/instance/as yet unclassified/wantsYellowButtonMenu.st A Polymorph-Widgets.package/ToolDockingBarMorph.class/instance/menu/wantsYellowButtonMenu.st A Polymorph-Widgets.package/ToolDockingBarMorph.class/instance/private - layout/updateColor.st A Polymorph-Widgets.package/ToolDockingBarMorph.class/instance/style/normalFillStyle.st A Polymorph-Widgets.package/UITheme.class/instance/accessing colors/listBackgroundColor.st A Polymorph-Widgets.package/UITheme.class/instance/border-styles/buttonBorderStyleFor_.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60141.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60142.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60141.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60142.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 60142 18704 button border should be themable https://pharo.fogbugz.com/f/cases/18704 http://files.pharo.org/image/60/60142.zip

July 9, 2016

Re: [Pharo-dev] inconsistent FileReference

by Esteban Lorenzano

it is not inconsistent, last option is incorrect and should not be used. what you do there is to declare: directory âtmp', file âa/b/c.txtâ is casual that it coincides with a real path, but it is not semantically correct, thatâs why x ~= z there was an issue around to explicitly forbid to declare a file like that, but I was (and still am) not sure it should be forbiddenâ¦ is not the spirit of smalltalkâ¦ you know, great power/great responsibility thing :) but it causes confusions (as this one), so at least needs to be correctly explained somewhere :) cheers, Esteban > On 09 Jul 2016, at 13:11, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > Imagine that you have > > '/tmp/a/b' folder containing 'c' file > > '/tmp/a/b' asFileReference ensureCreateDirectory. > '/tmp/a/b/c' asFileReference writeStreamDo: [ :s | s nextPutAll: 'contents' ]. > > now there are three ways how you can see the contents of the c file > > x := '/tmp/a/b/c.txt' asFileReference. > y := '/tmp' asFileReference / 'a' / 'b' / 'c.txt'. > z := '/tmp' asFileReference / 'a/b/c.txt'. > > They clearly all point to the same file: > > x contents = y contents "true" > x contents = z contents "true" > > Yet the last option is different > > x = y "true" > x = z "false" > > Why is that? Because the parent is different: > > x parent pathString "'/tmp/a/b'" > y parent pathString "'/tmp/a/b'" > z parent pathString "'/tmp'" > > So the parent is based on how the reference was constructed, not what it is actually pointing to, which is stupid. > > Is this a bug? Is this a (nasty) expected behavior? > > Peter

July 9, 2016

inconsistent FileReference

by Peter UhnÃ¡k

Imagine that you have '/tmp/a/b' folder containing 'c' file '/tmp/a/b' asFileReference ensureCreateDirectory. '/tmp/a/b/c' asFileReference writeStreamDo: [ :s | s nextPutAll: 'contents' ]. now there are three ways how you can see the contents of the c file x := '/tmp/a/b/c.txt' asFileReference. y := '/tmp' asFileReference / 'a' / 'b' / 'c.txt'. z := '/tmp' asFileReference / 'a/b/c.txt'. They clearly all point to the same file: x contents = y contents "true" x contents = z contents "true" Yet the last option is different x = y "true" x = z "false" Why is that? Because the parent is different: x parent pathString "'/tmp/a/b'" y parent pathString "'/tmp/a/b'" z parent pathString "'/tmp'" So the parent is based on how the reference was constructed, not what it is actually pointing to, which is stupid. Is this a bug? Is this a (nasty) expected behavior? Peter

July 9, 2016

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

by stepharo

I like the idea of Go to have a separate date-printer. 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 9, 2016

Re: [Pharo-dev] Spec Tutorial First chapter

by Sven Van Caekenberghe

> On 08 Jul 2016, at 19:50, stepharo <stepharo(a)free.fr> wrote: > > Hi > > Johan Fabry is writing a great tutorial (and this is cool to see all the material I gathered or wrote with him in the past) > > to take such great form. > > I attached the first chapter. I will post the chapter one by one once I review them (so far I have nothing to do - great feeling). > > Well done Johan! > > Stef > > <FirstContact.pdf> Great work, thank you ! Books make a lot of difference, even today.

July 9, 2016

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

by Igor Stasenko

If problem in ever-growing cache - try using identical object(s) as keys for cache, not newly-created-unique one, each time you adding new entry to cache :) or.. maybe cache is broken and does not releasing garbage anymore. On 8 July 2016 at 16:54, J.F. Rick <self(a)je77.com> wrote: > 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 >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> -- Best regards, Igor Stasenko.

July 9, 2016