Re: [Pharo-dev] Having comments for pragma?

[Eliot Miranda]

Hi Doru,

> On Jun 30, 2016, at 1:08 PM, Tudor Girba  wrote:
> 
> Hi,
> 
>> On Jun 27, 2016, at 7:55 PM, Eliot Miranda  wrote:
>> 
>> Hi Doru,
>> 
>> On Mon, Jun 27, 2016 at 6:36 AM, Tudor Girba  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"
>>
>> 
>> 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}] {{ . Pragma} . {> 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  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 

[Pharo-dev] [pharo-project/pharo-core]

[GitHub]

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

[Pharo-dev] [pharo-project/pharo-core] fb9425: 60141

[GitHub]

  Branch: refs/heads/6.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: fb9425d70ed5405074e24c43b830fb331cd6c3a0
  
https://github.com/pharo-project/pharo-core/commit/fb9425d70ed5405074e24c43b830fb331cd6c3a0
  Author: Jenkins Build Server 
  Date:   2016-07-07 (Thu, 07 Jul 2016)

  Changed paths:
M Collections-Strings.package/Symbol.class/README.md
M Kernel.package/Deprecation.class/instance/handling/transform.st
M Kernel.package/Object.class/class/documentation/whatIsAPrimitive.st
M OpalCompiler-Tests.package/IRBuilderTest.class/instance/testing - 
blocks/testRemoteTemp.st
M 
OpalCompiler-Tests.package/OCBytecodeDecompilerTest.class/instance/examples/remoteTemp.st
M 
OpalCompiler-Tests.package/OCBytecodeDecompilerTest.class/instance/examples/remoteTempNested.st
R ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
scripts/script60140.st
A ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
scripts/script60141.st
R ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
updates/update60140.st
A ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
updates/update60141.st
M 
ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st

  Log Message:
  ---
  60141
17958 Add examples to the Symbol class comment
https://pharo.fogbugz.com/f/cases/17958

18618 Better additional comment for primitive: 79 error: ec usage
https://pharo.fogbugz.com/f/cases/18618

18697 Automatic deprecation refactoring needs to take traits into account
https://pharo.fogbugz.com/f/cases/18697

18700 SistaV1 bytecode: fix for Opal tests to not crash the image
https://pharo.fogbugz.com/f/cases/18700

http://files.pharo.org/image/60/60141.zip

Re: [Pharo-dev] Time now print24

[Sven Van Caekenberghe]

> On 07 Jul 2016, at 18:33, Eliot Miranda  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/ or D/M/ ?).

Going more in the ISO direction is better (more universal), IMHO.

DateAndTime now rounded => "2016-07-07T18:45:12+02:00"

> So
> 
> Date today mmdd, ' ', 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 mmdd, ' ', (Time now nanos: 0) print24 => MNU
> 
> but there's a seconds accessor, so
> 
> Date today mmdd, ' ', (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

[Pharo-dev] Time now print24

[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 mmdd, ' ', 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 mmdd, ' ', (Time now nanos: 0) print24 => MNU

but there's a seconds accessor, so

Date today mmdd, ' ', (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

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

[Denis Kudriashov]

Hi

2016-07-06 9:00 GMT+02:00 Christophe Demarey :

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

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

[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  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  wrote:
>> 
>> 
>>> On 06 Jul 2016, at 10:12, Sven Van Caekenberghe  wrote:
>>> 
>>> 
 On 06 Jul 2016, at 09:52, GitHub  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
>> 
> 

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

[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  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  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 :
> 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
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.