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

Time now print24

by Eliot Miranda

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. 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

Re: [Pharo-dev] confused about the "image opening session"

by Denis Kudriashov

Hi 2016-07-06 9:00 GMT+02:00 Christophe Demarey <christophe.demarey(a)inria.fr>: > yes, what is bad now is that there is âno crash detectorâ. > If you quit an image without saving, you will get the epicea browser. I do > not want it in this case. When I do not save, it is on purpose. > Maybe a flag should be set when you quit the image (by saving or not). > This way, if the flag is not present at image startup, you could guess a > crash. > We could introduce special Epicea event "Image Shutdown". In this case current detector will not detect lost changes. Right now it analyses that last event is about code change. I guess it is not difficult to do and there is existing example: "image snapshot" event.

July 7, 2016

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

by Esteban Lorenzano

I have to add hereâ¦ solution is bad, because now projects are not shown EVEN if I activate it in settings :( > On 06 Jul 2016, at 12:28, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > yes, I do not agree either but is true there where problems. > but IMO this would be solved just by putting a timeout in 1-2s (and then run in background, and cache results) > not turning it off. > in for my experience, turning something off is equivalent to remove the feature (but then is worst, because it becomes dead code inside image). > > Anyway, any taker, to solve this in a proper way? > > Esteban > >> On 06 Jul 2016, at 12:13, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> >>> On 06 Jul 2016, at 10:12, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> >>> >>>> 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. >>> >> >> I only know that there where problems. >> >> Marcus >> >

July 7, 2016

[pharo-project/pharo-core]

by GitHub

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

July 7, 2016

[pharo-project/pharo-core] b6f7fb: 60140

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: b6f7fb4f49a031aac861ae87409687c3ac80f744 https://github.com/pharo-project/pharo-core/commit/b6f7fb4f49a031aac861ae87… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-07-07 (Thu, 07 Jul 2016) Changed paths: M FileSystem-Smalltalk.package/extension/CompiledMethod/instance/fileSize.st M GT-InspectorExtensions-Core.package/extension/CompiledMethod/instance/gtInspectorSourceIn_.st M GT-SpotterExtensions-Core.package/extension/CompiledMethod/instance/spotterPreviewCodeIn_.st M Glamour-Examples.package/GLMBasicExamples.class/instance/others/watcher.st M Glamour-Morphic-Brick.package/GLMCompositeBrick.class/class/examples/gtExamplePharoMethod.st M Kernel.package/CompiledMethod.class/instance/source code management/getSource.st M Network-Mail.package/MailAddressTokenizer.class/class/initialization/initialize.st M Network-Tests.package/MailAddressParserTest.class/instance/tests/testAddressesIn.st A Network-Tests.package/MailAddressParserTest.class/instance/tests/testAmpersand.st M OpalCompiler-Tests.package/OCBytecodeDecompilerTest.class/instance/examples/pushClosureCopyNoCopied.st M OpalCompiler-Tests.package/OCBytecodeDecompilerTest.class/instance/examples/pushClosureCopyNoCopiedArg.st M OpalCompiler-Tests.package/OCBytecodeDecompilerTest.class/instance/examples/pushClosureCopyOneCopiedArg.st M OpalCompiler-Tests.package/OCBytecodeDecompilerTest.class/instance/examples/remoteTemp.st M OpalCompiler-Tests.package/OCBytecodeDecompilerTest.class/instance/examples/remoteTempNested.st M OpalCompiler-Tests.package/OCBytecodeDecompilerTest.class/instance/tests - blocks/testPushClosureCopyNoCopied.st M OpalCompiler-Tests.package/OCBytecodeDecompilerTest.class/instance/tests - blocks/testPushClosureCopyNoCopiedArg.st M OpalCompiler-Tests.package/OCBytecodeDecompilerTest.class/instance/tests - blocks/testPushClosureCopyOneCopiedArg.st M OpalCompiler-Tests.package/OCBytecodeDecompilerTest.class/instance/tests - blocks/testPushClosureCopyOneCopiedTemp.st M OpalCompiler-Tests.package/OCBytecodeDecompilerTest.class/instance/tests - examples/testDecompileBytecodeDecompilerTestClass.st M OpalCompiler-Tests.package/OCBytecodeDecompilerTest.class/instance/tests - examples/testDecompileBytecodeGeneratorTest.st M OpalCompiler-Tests.package/OCBytecodeDecompilerTest.class/instance/tests - examples/testDecompileIRBuilderTestClass.st M OpalCompiler-Tests.package/OCBytecodeDecompilerTest.class/instance/tests/testBugOffset.st M OpalCompiler-Tests.package/OCBytecodeDecompilerTest.class/instance/tests/testDup.st M OpalCompiler-Tests.package/OCBytecodeDecompilerTest.class/instance/tests/testInstVar.st M OpalCompiler-Tests.package/OCBytecodeDecompilerTest.class/instance/tests/testJumpAheadTo.st M OpalCompiler-Tests.package/OCBytecodeDecompilerTest.class/instance/tests/testJumpAheadToIf.st M OpalCompiler-Tests.package/OCBytecodeDecompilerTest.class/instance/tests/testJumpBackTo.st M OpalCompiler-Tests.package/OCBytecodeDecompilerTest.class/instance/tests/testLiteralArray.st M OpalCompiler-Tests.package/OCBytecodeDecompilerTest.class/instance/tests/testLiteralBoolean.st M OpalCompiler-Tests.package/OCBytecodeDecompilerTest.class/instance/tests/testLiteralCharacter.st M OpalCompiler-Tests.package/OCBytecodeDecompilerTest.class/instance/tests/testLiteralFloat.st M OpalCompiler-Tests.package/OCBytecodeDecompilerTest.class/instance/tests/testLiteralInteger.st M OpalCompiler-Tests.package/OCBytecodeDecompilerTest.class/instance/tests/testLiteralNil.st M OpalCompiler-Tests.package/OCBytecodeDecompilerTest.class/instance/tests/testLiteralString.st M OpalCompiler-Tests.package/OCBytecodeDecompilerTest.class/instance/tests/testLiteralSymbol.st M OpalCompiler-Tests.package/OCBytecodeDecompilerTest.class/instance/tests/testLiteralVariableClass.st M OpalCompiler-Tests.package/OCBytecodeDecompilerTest.class/instance/tests/testLiteralVariableClassVariable.st M OpalCompiler-Tests.package/OCBytecodeDecompilerTest.class/instance/tests/testLiteralVariableGlobale.st M OpalCompiler-Tests.package/OCBytecodeDecompilerTest.class/instance/tests/testPopTop.st M OpalCompiler-Tests.package/OCBytecodeDecompilerTest.class/instance/tests/testPushConsArray.st M OpalCompiler-Tests.package/OCBytecodeDecompilerTest.class/instance/tests/testPushConsArray2.st M OpalCompiler-Tests.package/OCBytecodeDecompilerTest.class/instance/tests/testPushSelf.st M OpalCompiler-Tests.package/OCBytecodeDecompilerTest.class/instance/tests/testPushTempArgument.st M OpalCompiler-Tests.package/OCBytecodeDecompilerTest.class/instance/tests/testPushTempTemp.st M OpalCompiler-Tests.package/OCBytecodeDecompilerTest.class/instance/tests/testPushThisContext.st M OpalCompiler-Tests.package/OCBytecodeDecompilerTest.class/instance/tests/testRemoteTemp.st M OpalCompiler-Tests.package/OCBytecodeDecompilerTest.class/instance/tests/testRemoteTempNested.st M OpalCompiler-Tests.package/OCBytecodeDecompilerTest.class/instance/tests/testReturnTop.st M OpalCompiler-Tests.package/OCBytecodeDecompilerTest.class/instance/tests/testSendSuper.st M OpalCompiler-Tests.package/OCBytecodeDecompilerTest.class/instance/tests/testStoreIntoVariable.st M OpalCompiler-Tests.package/OCBytecodeDecompilerTest.class/instance/tests/testStoreTemp.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60139.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60140.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60139.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60140.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 60140 18696 some cleanup for OCBytecodeDecompilerTest for new Bytecode set https://pharo.fogbugz.com/f/cases/18696 18680 Forward port 18676 Endless loop parsing e-mail addresses containing an ampersand https://pharo.fogbugz.com/f/cases/18680 18694 deprecate #getSource https://pharo.fogbugz.com/f/cases/18694 http://files.pharo.org/image/60/60140.zip

July 7, 2016

ShortArray, DoubleArray & influence of 64bit

by Thibault Raffaillac

> I copy the comment of Behavior>>instSpec I had missed this one, thanks! > It depends. > > ByteArray is a good name and ShortArray is good name, self-explanatory, > there is no discussion here. > > Then it depends, at some place we use WordArray and DoubleWordArray, in > other we use LongArray and SixtyFourBitsIndexableArray... I'd go for > WordArray and DoubleWordArray, but I don't mind if one decides otherwise. > > For Float, we changed the representation to be "SmallFloat64" and > "BoxedFloat64". We have no proper support for single precision float in > Pharo. We could consider renaming FloatArray to DoubleArray, Float64Array, > or something similar. I don't know. I am still confused with WordArray in Pharo terminology: 32bit or native register size? For the naming I like the Java convention: byte(8), short(16), int(32), long(64). Ideally that would make: ByteArray(8), ShortArray(16), IntegerArray(32), LongArray(64), WordArray(native), DoubleWordArray(native*2) As for floats, one arithmetic on 64bit double is fine, but I think we need both 32bit & 64bit loads/stores, that is having FloatArray(32) and DoubleArray(64). That would make UFFI code consistent among 32bit & 64bit machines . Also in x86 all architectures do IEEE 64bit double arithmetic, so no need for a "native" register size. Thibault

July 7, 2016

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

by Alexandre Bergel

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 7, 2016

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

by Eliot Miranda

Hi Ben, On Wed, Jul 6, 2016 at 5:16 PM, Ben Coman <btc(a)openinworld.com> wrote: > On Thu, Jul 7, 2016 at 2:19 AM, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > > 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. > > If the root cause is a blocking system call e.g.... > "NetNameResolver class>>#addressForName: sometimes hangs when there is > no network" > https://pharo.fogbugz.com/default.asp?18281& > > this seems very hard to fix at the Image level, except maybe doing > in-Image name resolution instead of relying on the system library. I > found this... > http://forum.world.st/ANN-DnsClient-More-protocol-fun-td2303225.html It'll be child's play when we have the threaded FFI. > > > and... > http://www.squeaksource.com/dnsclient.html > http://www.squeaksource.com/ar.html > > cheers -ben > > > > > 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. > >>> > >>> > >> > >> > > > > > > -- _,,,^..^,,,_ best, Eliot

July 7, 2016

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

by Ben Coman

On Thu, Jul 7, 2016 at 2:19 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > 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. If the root cause is a blocking system call e.g.... "NetNameResolver class>>#addressForName: sometimes hangs when there is no network" https://pharo.fogbugz.com/default.asp?18281& this seems very hard to fix at the Image level, except maybe doing in-Image name resolution instead of relying on the system library. I found this... http://forum.world.st/ANN-DnsClient-More-protocol-fun-td2303225.html and... http://www.squeaksource.com/dnsclient.html http://www.squeaksource.com/ar.html cheers -ben > > 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 7, 2016

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

by Ben Coman

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 6, 2016