Re: [Pharo-dev] changing compiled byte arrays

[Tudor Girba]

Thanks, indeed!

Doru


> On Jul 10, 2016, at 7:28 PM, stepharo  wrote:
> 
> thanks for all the energy you put in getting non mutable objects. I will 
> bring a nicer system.
> 
> Stef
> 
> Le 10/7/16 à 12:06, Clément Bera a écrit :
>> Allright. But the problem happens for any literal you mutate, not only byte 
>> arrays.
>> 
>> For example this one:
>> 
>> foo
>> #(true nil 10) at: 2 put: 50.
>> ^ #(true nil 10)
>> 
>> Answers... #(true 50 10)
>> 
>> The most common problems are with Array, not ByteArray. 
>> 
>> Even worse, it can happen with LargeIntegers, Floats, ScaledDecimal, etc.
>> 
>> Hopefully read-only objects will solve most of the problems.
>> 
>> 
>> 
>> On Sun, Jul 10, 2016 at 10:51 AM, Peter Uhnák  wrote:
>> Thanks for the explanation!
>> 
>> I've this byte array syntax for the first time and I don't think that I will 
>> be making heavy use of it, so it shouldn't be a too big problem — since now 
>> I understand the behavior, so I can keep it in mind.
>> 
>> Thanks,
>> Peter
>> 
>> On Sun, Jul 10, 2016 at 7:43 AM, Clément Bera  wrote:
>> This is the normal behavior. You are mutating the method's literal, which 
>> becomes different. The instance is per method, so even if you do:
>> 
>> foo
>> #[1 2 3] at: 2 put: 50.
>> ^ #[1 2 3]
>> 
>> You get #[1 50 3], which is easy to understand in this example, but can be 
>> very tricky to understand in some cases.
>> 
>> I've introduced recently "read-only" objects (Object>>#isReadOnlyObject and 
>> co). I am waiting for the VM repo merge which should happen in the next few 
>> weeks to have this feature in the default Pharo VM, then I will be able to 
>> compile method literals "read-only" by default. With this feature, the 
>> #at:put: store will fail telling you that you cannot store into a read-only 
>> object, which will solve the common problem, when one does not mutate a 
>> literal on purpose.
>> 
>> Now as in Pharo everything is reflective, it will always be possible to mark 
>> back the literal as "writable", mutate it, and still have this behavior.
>> 
>> Best,
>> Clement
>> 
>> 
>> On Sat, Jul 9, 2016 at 10:22 PM, Peter Uhnák  wrote:
>> 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
>> 
>> 
>> 
> 

--
www.tudorgirba.com
www.feenk.com

"We cannot reach the flow of things unless we let go."

Re: [Pharo-dev] UDBCSQLite3Statement>>at:putDateTime: and DateAndTime>>readFrom:defaultOffset:

[Sven Van Caekenberghe]

Hi,

Regarding the DateAndTime change.

> On 11 Jul 2016, at 07:52, Alistair Grant  wrote:
> 
> I've finally got this to the point where I think it can be submitted.
> 
> The previous version missed a case (sql between).  To keep backward
> compatibility with earlier versions of UDBC SQLite3 I've sacrificed a
> bit of conformaty and made the representation:
> 
> -MM-DD HH:MM:SS.ss
> 
> (the difference being microseconds instead of millseconds).  My limited
> interoperability testing (Python / Django) suggests this shouldn't be a
> problem.
> 
> The tricky bit is that it affects four different packages:
> 
> 1. UDBC-SQLite-Base (UDBCSQLite3Statement, PierceNg.49)
> 2. Glorp (UDBCSQLite3Platform, AlistairGrant.129)
> 3. Kernel (DateAndTime, TheIntegrator.2293)
> 4. Kernel-Tests (DateAndTimeTest, TheIntegrator.65)
> 
> I assume that I can create a fogbugz issue and submit a single slice
> that will contain the changes to DateAndTime and DateAndTimeTest for
> Pharo 6.

Yes, please create a slice. But first for Pharo 6, then back port to 5.

I assume that your change is adding the default timezone parameter ?

A small remark: in your unit tests, don't compare string output, but objects. 
In the 1st test, compare to Duration zero, in the second to 2 hours.

Sven

> What's the best way to submit this for Pharo 5?
> 
> The Glorp changes are dependent on the Kernel changes, and the
> UDBC-SQLite-Base changes are dependent on the Glorp changes.
> 
> I guess that for Glorp, the best way is to include the Kernel changes as
> an extension for Pharo 5.
> 
> How is a dependency such as that between UDBC-SQLite-Base and Glorp
> normally handled?
> 
> Thanks!
> Alistair
> 
> 
> 'From Pharo5.0 of 16 April 2015 [Latest update: #50760] on 10 July 2016 at 
> 10:29:14.682983 am'!
> 
> !DateAndTime class methodsFor: 'input' stamp: 'AlistairGrant 6/25/2016 22:55'!
> readFrom: aStream defaultOffset: defaultOffset
>   "Parse and return a new DateAndTime instance from stream, 
>   as a Date, an optional Time and an optional TimeZone offset.
>   The time defaults to midnight, the timezone to defaultOffset"
>   "self readFrom: '2013-03-04T23:47:52.876+01:00' readStream"
> 
>   | date time offset |
>   date := Date readFrom: aStream.
>   [ aStream atEnd or: [ '0123456789Z+-' includes: aStream peek ] ] 
>   whileFalse: [ aStream next ].
>   ('0123456789' includes: aStream peek)
>   ifTrue: [ time := Time readFrom: aStream ]
>   ifFalse: [ time := Time midnight ].
>   aStream skipSeparators.
>   offset := self readTimezoneOffsetFrom: aStream default: defaultOffset.
>   ^ self
>   year: date year
>   month: date monthIndex
>   day: date dayOfMonth
>   hour: time hour
>   minute: time minute
>   second: time second
>   nanoSecond: time nanoSecond
>   offset: offset! !
> 
> !DateAndTime class methodsFor: 'input' stamp: 'AlistairGrant 6/25/2016 22:55'!
> readFrom: aStream
>   "Parse and return a new DateAndTime instance from stream, 
>   as a Date, an optional Time and an optional TimeZone offset.
>   The time defaults to midnight, the timezone to the local offset"
>   "self readFrom: '2013-03-04T23:47:52.876+01:00' readStream"
> 
>   ^self readFrom: aStream defaultOffset: self localOffset.! !
> 
> !DateAndTime class methodsFor: 'input' stamp: 'AlistairGrant 6/25/2016 22:47'!
> readTimezoneOffsetFrom: stream default: defaultOffset
>   "Read and return an optional timezone offset in the form of 
>   [+|-]hh[[separator]mm[[separator]ss]] or Z from stream as a duration.
>   If there is no offset, return the defaultOffset."
> 
>   | sign hour minute second |
>   (stream peekFor: $Z) ifTrue: [ ^ Duration zero ].
>   hour := minute := second := 0.
>   ^ ('+-' includes: stream peek)
>   ifTrue: [
>   sign := stream next = $- ifTrue: [ -1 ] ifFalse: [ 1 ].
>   hour := self readTwoDigitIntegerFrom: stream.
>   (self readOptionalSeparatorFrom: stream)
>   ifNotNil: [ 
>   minute := self readTwoDigitIntegerFrom: 
> stream.
>   (self readOptionalSeparatorFrom: stream)
>   ifNotNil: [ 
>   second := Integer 
> readFrom: stream ] ].
>   Duration seconds: sign * ((hour * 3600) + (minute * 60) 
> + second) ]
>   ifFalse: [ defaultOffset ]! !
> 
> !DateAndTime class methodsFor: 'input' stamp: 'AlistairGrant 6/25/2016 22:47'!
> readTimezoneOffsetFrom: stream
>   "Read and return an optional timezone offset in the form of 
>   [+|-]hh[[separator]mm[[separator]ss]] or Z from stream as a duration.
>   If there is no offset, retu

Re: [Pharo-dev] UDBCSQLite3Statement>>at:putDateTime: and DateAndTime>>readFrom:defaultOffset:

[Alistair Grant]

I've finally got this to the point where I think it can be submitted.

The previous version missed a case (sql between).  To keep backward
compatibility with earlier versions of UDBC SQLite3 I've sacrificed a
bit of conformaty and made the representation:

-MM-DD HH:MM:SS.ss

(the difference being microseconds instead of millseconds).  My limited
interoperability testing (Python / Django) suggests this shouldn't be a
problem.

The tricky bit is that it affects four different packages:

1. UDBC-SQLite-Base (UDBCSQLite3Statement, PierceNg.49)
2. Glorp (UDBCSQLite3Platform, AlistairGrant.129)
3. Kernel (DateAndTime, TheIntegrator.2293)
4. Kernel-Tests (DateAndTimeTest, TheIntegrator.65)

I assume that I can create a fogbugz issue and submit a single slice
that will contain the changes to DateAndTime and DateAndTimeTest for
Pharo 6.

What's the best way to submit this for Pharo 5?

The Glorp changes are dependent on the Kernel changes, and the
UDBC-SQLite-Base changes are dependent on the Glorp changes.

I guess that for Glorp, the best way is to include the Kernel changes as
an extension for Pharo 5.

How is a dependency such as that between UDBC-SQLite-Base and Glorp
normally handled?

Thanks!
Alistair


'From Pharo5.0 of 16 April 2015 [Latest update: #50760] on 10 July 2016 at 
10:29:14.682983 am'!

!DateAndTime class methodsFor: 'input' stamp: 'AlistairGrant 6/25/2016 22:55'!
readFrom: aStream defaultOffset: defaultOffset
"Parse and return a new DateAndTime instance from stream, 
as a Date, an optional Time and an optional TimeZone offset.
The time defaults to midnight, the timezone to defaultOffset"
"self readFrom: '2013-03-04T23:47:52.876+01:00' readStream"

| date time offset |
date := Date readFrom: aStream.
[ aStream atEnd or: [ '0123456789Z+-' includes: aStream peek ] ] 
whileFalse: [ aStream next ].
('0123456789' includes: aStream peek)
ifTrue: [ time := Time readFrom: aStream ]
ifFalse: [ time := Time midnight ].
aStream skipSeparators.
offset := self readTimezoneOffsetFrom: aStream default: defaultOffset.
^ self
year: date year
month: date monthIndex
day: date dayOfMonth
hour: time hour
minute: time minute
second: time second
nanoSecond: time nanoSecond
offset: offset! !

!DateAndTime class methodsFor: 'input' stamp: 'AlistairGrant 6/25/2016 22:55'!
readFrom: aStream
"Parse and return a new DateAndTime instance from stream, 
as a Date, an optional Time and an optional TimeZone offset.
The time defaults to midnight, the timezone to the local offset"
"self readFrom: '2013-03-04T23:47:52.876+01:00' readStream"

^self readFrom: aStream defaultOffset: self localOffset.! !

!DateAndTime class methodsFor: 'input' stamp: 'AlistairGrant 6/25/2016 22:47'!
readTimezoneOffsetFrom: stream default: defaultOffset
"Read and return an optional timezone offset in the form of 
[+|-]hh[[separator]mm[[separator]ss]] or Z from stream as a duration.
If there is no offset, return the defaultOffset."

| sign hour minute second |
(stream peekFor: $Z) ifTrue: [ ^ Duration zero ].
hour := minute := second := 0.
^ ('+-' includes: stream peek)
ifTrue: [
sign := stream next = $- ifTrue: [ -1 ] ifFalse: [ 1 ].
hour := self readTwoDigitIntegerFrom: stream.
(self readOptionalSeparatorFrom: stream)
ifNotNil: [ 
minute := self readTwoDigitIntegerFrom: 
stream.
(self readOptionalSeparatorFrom: stream)
ifNotNil: [ 
second := Integer 
readFrom: stream ] ].
Duration seconds: sign * ((hour * 3600) + (minute * 60) 
+ second) ]
ifFalse: [ defaultOffset ]! !

!DateAndTime class methodsFor: 'input' stamp: 'AlistairGrant 6/25/2016 22:47'!
readTimezoneOffsetFrom: stream
"Read and return an optional timezone offset in the form of 
[+|-]hh[[separator]mm[[separator]ss]] or Z from stream as a duration.
If there is no offset, return the local offset."

^self readTimezoneOffsetFrom: stream default: self localOffset! !


!DateAndTimeTest methodsFor: 'tests - offset' stamp: 'AlistairGrant 7/3/2016 
21:18'!
testReadFromDefaultOffsetNotSpecified
"self debug: #testReadFromDefaultOffsetSpecified"

self assert: (DateAndTime readFrom: '2016-07-03T21:16:16.708241' 
readStream defaultOffset: Duration zero) offset printString equals: 
'0:00:00:00'.
! !

!DateAndTimeTest methodsFor: 'tests - offset' stamp: 'Alistair

Re: [Pharo-dev] SessionManager and SystemSettings?

[Yuriy Tymchuk]

Settings should work now

> On 26 Jun 2016, at 04:56, Juraj Kubelka  wrote:
> 
> Thanks Yuriy!
> 
> Last time, there was a problem on Jenkins. I do not have access to check it 
> or change it.
> It is necessary that cleanUp process is called as a last command on Jenkins.
> 
> The other thing is to find out another solution. The current solution expects 
> that an instance variable is unset in a fresh (downloaded) image. And this 
> variable is set when the image is opened. 
> 
> Cheers,
> Juraj
> 
>> On Jun 25, 2016, at 17:25, Yuriy Tymchuk > > wrote:
>> 
>> cc Juraj
>> 
>>> On 25 Jun 2016, at 22:28, Nicolai Hess >> > wrote:
>>> 
>>> 
>>> 
>>> 2016-06-23 15:32 GMT+02:00 Esteban Lorenzano >> >:
>>> 
>>> > On 23 Jun 2016, at 15:29, Cyril Ferlicot Delbecque 
>>> > mailto:cyril.ferli...@gmail.com>> wrote:
>>> >
>>> >
>>> >
>>> > On 23/06/2016 15:07, Christophe Demarey wrote:
>>> >> What happens if you execute
>>> >> 'SystemSettingsPersistence resumeSystemSettings’ in a 60103 image?
>>> >> If nothing happens, it could be that 'SystemSettingsPersistence
>>> >> instVarNamed: ‘alreadyResumed’’ is true
>>> >>
>>> >> I checked the startupList and PharoCommandLineHandler>>#runPreferences
>>> >> but nothing changed there.
>>> >>
>>> >>
>>> >
>>> >
>>> > I think I read something about a script esteban added to clear the
>>> > ever-growing stack. Couldn't it be that? Maybe it open the image and the
>>> 
>>> > system setting think he already loaded the settings.
>>> 
>>> no it shouldn’t… and *my* preferences are correctly loaded :)
>>> 
>>> Can we please fix this.
>>> I work a lot with fresh images, and now every time a start a new image and 
>>> trying to access a repository I have to remmember
>>> to set the network proxy settings.
>>>  
>>> 
>>> >
>>> >>
>>> >
>>> > --
>>> > Cyril Ferlicot
>>> >
>>> > http://www.synectique.eu 
>>> >
>>> > 165 Avenue Bretagne
>>> > Lille 59000 France
>>> >
>> 
> 

Re: [Pharo-dev] Athens Font Rendering Bug

[J.F. Rick]

Interesting. Why is it then correct in BitBlt rendering and not correct in
Athens rendering? Does this mean it can be fixed at the Smalltalk level? If
so, give me a hint of where to look and I'll see if I can find a solution.

Cheers,

Jeff

On Sun, Jul 10, 2016 at 1:12 PM Aliaksei Syrel  wrote:

> Hi
>
> Actually it is not Athens bug. Problem is in string extent measurement
> done by text morph. Athens (Cairo in the end) only renders string glyphs
> created by FreeType2 on positions specified by someone else (morphic in
> this case).
>
> Cheers
> Alex
> On Jul 10, 2016 6:16 PM, "J.F. Rick"  wrote:
>
>> Perhaps other people have already reported this for Bloc but something is
>> wrong with the font rendering of Athens. Here's the code and how it is
>> rendered in Athens vs how it is rendered in BitBlt. It seems like Athens
>> adds more space between letters than is supposed to be there.
>>
>> tMorph := TextMorph new.
>> font1 := TextFontReference toFont: (LogicalFont familyName: 'Arial'
>> fallbackFamilyNames: nil pointSize: 28 stretchValue: 5 weightValue: 400
>> slantValue: 0).
>> font2 := (TextFontReference toFont: (StrikeFont familyName: 'Atlanta'
>> size: 11)).
>> t1 := 'this is font1' asText addAttribute: font1.
>> t2 := ' and this is font2' asText addAttribute: font2.
>> tMorph contents: (t1,t2).
>>
>> Cheers,
>>
>> Jeff
>>
>

Re: [Pharo-dev] changing compiled byte arrays

[stepharo]

thanks for all the energy you put in getting non mutable objects. I will 
bring a nicer system.


Stef


Le 10/7/16 à 12:06, Clément Bera a écrit :
Allright. But the problem happens for any literal you mutate, not only 
byte arrays.


For example this one:

foo
#(true nil 10) at: 2 put: 50.
^#(true nil 10)

Answers... #(true 50 10)

The most common problems are with Array, not ByteArray.

Even worse, it can happen with LargeIntegers, Floats, ScaledDecimal, etc.

Hopefully read-only objects will solve most of the problems.



On Sun, Jul 10, 2016 at 10:51 AM, Peter Uhnák > wrote:


Thanks for the explanation!

I've this byte array syntax for the first time and I don't think
that I will be making heavy use of it, so it shouldn't be a too
big problem — since now I understand the behavior, so I can keep
it in mind.

Thanks,
Peter

On Sun, Jul 10, 2016 at 7:43 AM, Clément Bera
mailto:bera.clem...@gmail.com>> wrote:

This is the normal behavior. You are mutating the method's
literal, which becomes different. The instance is per method,
so even if you do:

foo
#[1 2 3] at: 2 put: 50.
^ #[1 2 3]

You get #[1 50 3], which is easy to understand in this
example, but can be very tricky to understand in some cases.

I've introduced recently "read-only" objects
(Object>>#isReadOnlyObject and co). I am waiting for the VM
repo merge which should happen in the next few weeks to have
this feature in the default Pharo VM, then I will be able to
compile method literals "read-only" by default. With this
feature, the #at:put: store will fail telling you that you
cannot store into a read-only object, which will solve the
common problem, when one does not mutate a literal on purpose.

Now as in Pharo everything is reflective, it will always be
possible to mark back the literal as "writable", mutate it,
and still have this behavior.

Best,
Clement


On Sat, Jul 9, 2016 at 10:22 PM, Peter Uhnák
mailto:i.uh...@gmail.com>> wrote:

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

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

[GitHub]

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

[Pharo-dev] [pharo-project/pharo-core] 050429: 60143

[GitHub]

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

  Changed paths:
M AST-Core.package/RBParser.class/definition.st
M AST-Core.package/RBParser.class/instance/private-parsing/parseMethod.st
M HelpSystem-Core.package/ClassAPIHelpBuilder.class/definition.st
A 
HelpSystem-Core.package/ClassAPIHelpBuilder.class/instance/accessing/addMethodsWithoutComment.st
A 
HelpSystem-Core.package/ClassAPIHelpBuilder.class/instance/accessing/addMethodsWithoutComment_.st
M 
HelpSystem-Core.package/ClassAPIHelpBuilder.class/instance/initialization/initialize.st
M HelpSystem-Core.package/ClassAPIHelpBuilder.class/instance/private 
building/buildMethodTopicsOn_for_.st
A 
HelpSystem-Core.package/CustomHelp.class/class/accessing/bookDescription.st
M 
HelpSystem-Core.package/CustomHelpHelpBuilder.class/instance/private/createTopicFrom_.st
M 
HelpSystem-Core.package/HelpHowToHelpTopicsFromCode.class/class/pages/step2.st
A Network-Tests.package/NeoUUIDGeneratorTests.class/README.md
A Network-Tests.package/NeoUUIDGeneratorTests.class/definition.st
A 
Network-Tests.package/NeoUUIDGeneratorTests.class/instance/private/timeFromUUID_.st
A Network-Tests.package/NeoUUIDGeneratorTests.class/instance/setup/setUp.st
A 
Network-Tests.package/NeoUUIDGeneratorTests.class/instance/testing/testDefault.st
A 
Network-Tests.package/NeoUUIDGeneratorTests.class/instance/testing/testOne.st
A 
Network-Tests.package/NeoUUIDGeneratorTests.class/instance/testing/testSpeed.st
A 
Network-Tests.package/NeoUUIDGeneratorTests.class/instance/testing/testTwoDifferentGenerator.st
A 
Network-Tests.package/NeoUUIDGeneratorTests.class/instance/testing/testTwoSameGenerator.st
A 
Network-Tests.package/NeoUUIDGeneratorTests.class/instance/testing/testUniqueness.st
A Network-UUID.package/NeoUUIDGenerator.class/README.md
A Network-UUID.package/NeoUUIDGenerator.class/class/accessing/default.st
A Network-UUID.package/NeoUUIDGenerator.class/class/accessing/next.st
A 
Network-UUID.package/NeoUUIDGenerator.class/class/initialization/initialize.st
A Network-UUID.package/NeoUUIDGenerator.class/class/system 
startup/startUp.st
A Network-UUID.package/NeoUUIDGenerator.class/definition.st
A Network-UUID.package/NeoUUIDGenerator.class/instance/accessing/next.st
A 
Network-UUID.package/NeoUUIDGenerator.class/instance/accessing/placeFields_.st
A 
Network-UUID.package/NeoUUIDGenerator.class/instance/accessing/randomGenerator.st
A 
Network-UUID.package/NeoUUIDGenerator.class/instance/initialize/initialize.st
A Network-UUID.package/NeoUUIDGenerator.class/instance/private/clockOn_.st
A 
Network-UUID.package/NeoUUIDGenerator.class/instance/private/computeNodeIdentifier.st
A 
Network-UUID.package/NeoUUIDGenerator.class/instance/private/nextCounter16.st
A 
Network-UUID.package/NeoUUIDGenerator.class/instance/private/nextRandom16.st
A 
Network-UUID.package/NeoUUIDGenerator.class/instance/private/setVariantAndVersion_.st
M OpalCompiler-Core.package/IRBytecodeDecompiler.class/instance/quick 
methods/quickMethod.st
M 
OpalCompiler-Core.package/IRBytecodeGenerator.class/instance/private/quickMethodPrim.st
R 
OpalCompiler-Core.package/IRBytecodeGenerator.class/instance/private/quickPrimSpecialConstants.st
A OpalCompiler-Core.package/OpalEncoder.class/class/bytecode 
decoding/quickPrimSpecialConstants.st
M 
OpalCompiler-Tests.package/IRPrinterTest.class/instance/testing/testRemoteTemp.st
M 
OpalCompiler-Tests.package/OCBytecodeDecompilerTest.class/instance/examples/remoteTemp.st
M 
OpalCompiler-Tests.package/OCCompiledMethodIntegrityTests.class/instance/test/testBlockTemps.st
M 
OpalCompiler-Tests.package/OCCompiledMethodIntegrityTests.class/instance/test/testNotUsedArgument.st
M 
OpalCompiler-Tests.package/OCCompiledMethodIntegrityTests.class/instance/test/testPragmas.st
M 
OpalCompiler-Tests.package/OCCompiledMethodIntegrityTests.class/instance/test/testPrimitive.st
M 
OpalCompiler-Tests.package/OCCompiledMethodIntegrityTests.class/instance/test/testRemoteTempInVector.st
M 
OpalCompiler-Tests.package/OCCompilerNotifyingTest.class/instance/testing-byteCode
 limits/testTooManyLiterals.st
R ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
scripts/script60142.st
A ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
scripts/script60143.st
R ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
updates/update60142.st
A ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
updates/update60143.st
M 
ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st
M 
System-Changes.package/ChangeSet.cla

Re: [Pharo-dev] Athens Font Rendering Bug

[Aliaksei Syrel]

Hi

Actually it is not Athens bug. Problem is in string extent measurement done
by text morph. Athens (Cairo in the end) only renders string glyphs created
by FreeType2 on positions specified by someone else (morphic in this case).

Cheers
Alex
On Jul 10, 2016 6:16 PM, "J.F. Rick"  wrote:

> Perhaps other people have already reported this for Bloc but something is
> wrong with the font rendering of Athens. Here's the code and how it is
> rendered in Athens vs how it is rendered in BitBlt. It seems like Athens
> adds more space between letters than is supposed to be there.
>
> tMorph := TextMorph new.
> font1 := TextFontReference toFont: (LogicalFont familyName: 'Arial'
> fallbackFamilyNames: nil pointSize: 28 stretchValue: 5 weightValue: 400
> slantValue: 0).
> font2 := (TextFontReference toFont: (StrikeFont familyName: 'Atlanta'
> size: 11)).
> t1 := 'this is font1' asText addAttribute: font1.
> t2 := ' and this is font2' asText addAttribute: font2.
> tMorph contents: (t1,t2).
>
> Cheers,
>
> Jeff
>

[Pharo-dev] Athens Font Rendering Bug

[J.F. Rick]

Perhaps other people have already reported this for Bloc but something is
wrong with the font rendering of Athens. Here's the code and how it is
rendered in Athens vs how it is rendered in BitBlt. It seems like Athens
adds more space between letters than is supposed to be there.

tMorph := TextMorph new.
font1 := TextFontReference toFont: (LogicalFont familyName: 'Arial'
fallbackFamilyNames: nil pointSize: 28 stretchValue: 5 weightValue: 400
slantValue: 0).
font2 := (TextFontReference toFont: (StrikeFont familyName: 'Atlanta' size:
11)).
t1 := 'this is font1' asText addAttribute: font1.
t2 := ' and this is font2' asText addAttribute: font2.
tMorph contents: (t1,t2).

Cheers,

Jeff

Re: [Pharo-dev] changing compiled byte arrays

[Clément Bera]

Allright. But the problem happens for any literal you mutate, not only byte
arrays.

For example this one:

foo
#(true nil 10) at: 2 put: 50.
^ #(true nil 10)

Answers... #(true 50 10)

The most common problems are with Array, not ByteArray.

Even worse, it can happen with LargeIntegers, Floats, ScaledDecimal, etc.

Hopefully read-only objects will solve most of the problems.



On Sun, Jul 10, 2016 at 10:51 AM, Peter Uhnák  wrote:

> Thanks for the explanation!
>
> I've this byte array syntax for the first time and I don't think that I
> will be making heavy use of it, so it shouldn't be a too big problem —
> since now I understand the behavior, so I can keep it in mind.
>
> Thanks,
> Peter
>
> On Sun, Jul 10, 2016 at 7:43 AM, Clément Bera 
> wrote:
>
>> This is the normal behavior. You are mutating the method's literal, which
>> becomes different. The instance is per method, so even if you do:
>>
>> foo
>> #[1 2 3] at: 2 put: 50.
>> ^ #[1 2 3]
>>
>> You get #[1 50 3], which is easy to understand in this example, but can
>> be very tricky to understand in some cases.
>>
>> I've introduced recently "read-only" objects (Object>>#isReadOnlyObject
>> and co). I am waiting for the VM repo merge which should happen in the next
>> few weeks to have this feature in the default Pharo VM, then I will be able
>> to compile method literals "read-only" by default. With this feature, the
>> #at:put: store will fail telling you that you cannot store into a read-only
>> object, which will solve the common problem, when one does not mutate a
>> literal on purpose.
>>
>> Now as in Pharo everything is reflective, it will always be possible to
>> mark back the literal as "writable", mutate it, and still have this
>> behavior.
>>
>> Best,
>> Clement
>>
>>
>> On Sat, Jul 9, 2016 at 10:22 PM, Peter Uhnák  wrote:
>>
>>> 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
>>>
>>
>>
>

Re: [Pharo-dev] changing compiled byte arrays

[Peter Uhnák]

Thanks for the explanation!

I've this byte array syntax for the first time and I don't think that I
will be making heavy use of it, so it shouldn't be a too big problem —
since now I understand the behavior, so I can keep it in mind.

Thanks,
Peter

On Sun, Jul 10, 2016 at 7:43 AM, Clément Bera 
wrote:

> This is the normal behavior. You are mutating the method's literal, which
> becomes different. The instance is per method, so even if you do:
>
> foo
> #[1 2 3] at: 2 put: 50.
> ^ #[1 2 3]
>
> You get #[1 50 3], which is easy to understand in this example, but can
> be very tricky to understand in some cases.
>
> I've introduced recently "read-only" objects (Object>>#isReadOnlyObject
> and co). I am waiting for the VM repo merge which should happen in the next
> few weeks to have this feature in the default Pharo VM, then I will be able
> to compile method literals "read-only" by default. With this feature, the
> #at:put: store will fail telling you that you cannot store into a read-only
> object, which will solve the common problem, when one does not mutate a
> literal on purpose.
>
> Now as in Pharo everything is reflective, it will always be possible to
> mark back the literal as "writable", mutate it, and still have this
> behavior.
>
> Best,
> Clement
>
>
> On Sat, Jul 9, 2016 at 10:22 PM, Peter Uhnák  wrote:
>
>> 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
>>
>
>