- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] build 50588 strange font failure?

by Nicolai Hess

2016-02-18 15:12 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > Not sure if this is a once-off, but just reporting since its a bit strange. > > Into a newly minted 50588 image I had recently loaded > Slice-Issue-17373...BenComan.12.mcz > which however only introduces new code with no modification to > existing code (except minor re-factoring of some tests) > > I was happily editing a method in the Browser when the problem > occured. Its okay if I type within an existing word, but with space > either side of the cursor, typing cause a primitive failure per the > stack below. "....." notes some values. > > This occurs even from a new Browser window, on any method. > > In system settings, unticking and reticking [Use Free type...] > causes red-pane-of-death on the problematic code panes with similar > stack as below, > but the problem is fixed in newly opened Browser windows. (btw the > font had changed) > > Array class(Object)>>primitiveFailed: > Array class(Object)>>primitiveFailed > Array class(Behavior)>>basicNew: > Array class>>new: > .....sizeRequested --> nil > FreeTypeFace(FT2Face)>>charmaps > .....numCharmaps --> nil > FreeTypeFont>>getLinearWidthOf: > .....self face charmaps --> a FreeTypeFace with numCharmaps --> nil > I see this issue quite often, not related to any special image version (happens since spur/ffi changes). Happens randomly, most of the time it is enough to reopen the image (of course, you lost all changes). > [ self getLinearWidthOf: aCharacter ] in FreeTypeFont>>linearWidthOf: > in Block: [ self getLinearWidthOf: aCharacter ] > FreeTypeCache>>atFont:charCode:type:ifAbsentPut: > FreeTypeFont>>linearWidthOf: > FreeTypeFont>>widthOf: > LogicalFont>>widthOf: > RubCompositionScanner(RubCharacterScanner)>>setFont > RubCompositionScanner>>setFont > RubCompositionScanner>>setStopConditions > RubCompositionScanner>>endOfRun > > RubCompositionScanner>>composeFrom:inRectangle:firstLine:leftSide:rightSide: > RubTextComposer>>composeEachRectangleIn: > RubTextComposer>>composeAllRectangles: > RubTextComposer>>composeOneLine > RubTextComposer>>composeAllLines > > RubTextComposer>>composeLinesFrom:to:delta:into:priorLines:atY:textStyle:text:container: > RubTextComposer>>composeLinesFrom:to:delta:into:priorLines:atY: > RubTextComposer>>recomposeFrom:to:delta: > [ self composer recomposeFrom: start to: stop delta: delta ] in > RubParagraph>>recomposeFrom:to:delta: in Block: [ self composer > recomposeFrom: start to: stop delt...etc... > RubParagraph>>disableDrawingWhile: > RubParagraph>>recomposeFrom:to:delta: > Message>>sendTo: > [ aMessage sendTo: next ] in > > RubOpeningClosingDelimiterDecorator(RubParagraphDecorator)>>doesNotUnderstand: > #recomposeFrom:to:delta: in Block: [ aMessage sendTo: next ] > BlockClosure>>on:do: > > RubOpeningClosingDelimiterDecorator(RubParagraphDecorator)>>doesNotUnderstand: > #recomposeFrom:to:delta: > > In case its useful, I uploaded a fuel dump of the stack here... > http://wikisend.com/download/365684/fuel.zip > expires in 7 days, zip password = pharo > > /home/ben/.local/share/Pharo/VMs/spur/pharo-vm/pharo > CoInterpreter VMMaker.oscog-eem.1630 uuid: > 2ed025ea-f400-4440-8e8b-5aa46d06c9ab Jan 14 2016 > StackToRegisterMappingCogit VMMaker.oscog-eem.1630 uuid: > 2ed025ea-f400-4440-8e8b-5aa46d06c9ab Jan 14 2016 > https://github.com/estebanlm/pharo-vm.git Commit: > 21ec004cce7d26010c18d357c805a0e1a4ffe376 Date: 2016-01-14 11:42:33 > +0100 By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #498 > > cheers -ben > >

Feb. 18, 2016

CI Slaves ?

by Sven Van Caekenberghe

The CI build slaves seem to be in a bad state, nothing much is happening, many are down ...

Feb. 18, 2016

build 50588 strange font failure?

by Ben Coman

Not sure if this is a once-off, but just reporting since its a bit strange. Into a newly minted 50588 image I had recently loaded Slice-Issue-17373...BenComan.12.mcz which however only introduces new code with no modification to existing code (except minor re-factoring of some tests) I was happily editing a method in the Browser when the problem occured. Its okay if I type within an existing word, but with space either side of the cursor, typing cause a primitive failure per the stack below. "....." notes some values. This occurs even from a new Browser window, on any method. In system settings, unticking and reticking [Use Free type...] causes red-pane-of-death on the problematic code panes with similar stack as below, but the problem is fixed in newly opened Browser windows. (btw the font had changed) Array class(Object)>>primitiveFailed: Array class(Object)>>primitiveFailed Array class(Behavior)>>basicNew: Array class>>new: .....sizeRequested --> nil FreeTypeFace(FT2Face)>>charmaps .....numCharmaps --> nil FreeTypeFont>>getLinearWidthOf: .....self face charmaps --> a FreeTypeFace with numCharmaps --> nil [ self getLinearWidthOf: aCharacter ] in FreeTypeFont>>linearWidthOf: in Block: [ self getLinearWidthOf: aCharacter ] FreeTypeCache>>atFont:charCode:type:ifAbsentPut: FreeTypeFont>>linearWidthOf: FreeTypeFont>>widthOf: LogicalFont>>widthOf: RubCompositionScanner(RubCharacterScanner)>>setFont RubCompositionScanner>>setFont RubCompositionScanner>>setStopConditions RubCompositionScanner>>endOfRun RubCompositionScanner>>composeFrom:inRectangle:firstLine:leftSide:rightSide: RubTextComposer>>composeEachRectangleIn: RubTextComposer>>composeAllRectangles: RubTextComposer>>composeOneLine RubTextComposer>>composeAllLines RubTextComposer>>composeLinesFrom:to:delta:into:priorLines:atY:textStyle:text:container: RubTextComposer>>composeLinesFrom:to:delta:into:priorLines:atY: RubTextComposer>>recomposeFrom:to:delta: [ self composer recomposeFrom: start to: stop delta: delta ] in RubParagraph>>recomposeFrom:to:delta: in Block: [ self composer recomposeFrom: start to: stop delt...etc... RubParagraph>>disableDrawingWhile: RubParagraph>>recomposeFrom:to:delta: Message>>sendTo: [ aMessage sendTo: next ] in RubOpeningClosingDelimiterDecorator(RubParagraphDecorator)>>doesNotUnderstand: #recomposeFrom:to:delta: in Block: [ aMessage sendTo: next ] BlockClosure>>on:do: RubOpeningClosingDelimiterDecorator(RubParagraphDecorator)>>doesNotUnderstand: #recomposeFrom:to:delta: In case its useful, I uploaded a fuel dump of the stack here... http://wikisend.com/download/365684/fuel.zip expires in 7 days, zip password = pharo /home/ben/.local/share/Pharo/VMs/spur/pharo-vm/pharo CoInterpreter VMMaker.oscog-eem.1630 uuid: 2ed025ea-f400-4440-8e8b-5aa46d06c9ab Jan 14 2016 StackToRegisterMappingCogit VMMaker.oscog-eem.1630 uuid: 2ed025ea-f400-4440-8e8b-5aa46d06c9ab Jan 14 2016 https://github.com/estebanlm/pharo-vm.git Commit: 21ec004cce7d26010c18d357c805a0e1a4ffe376 Date: 2016-01-14 11:42:33 +0100 By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #498 cheers -ben

Feb. 18, 2016

Re: [Pharo-dev] FFI BoxedFloat64 bug?

by ClÃ©ment Bera

I don't understand. In 32 bits in C, there are 32 bits float called "float" or "single precision float" but its usage is very uncommon. People always use "double" as every 32 bits processors supports 64 bits float nowadays. When I look at the Cairo reference manual, only double are used, so I don't understand why you need to cast BoxedFloat64 to single precision float for FFI. The ThreadedIA32FFIPlugin has both #ffiPushDoubleFloat:in: and ffiPushSingleFloat:in: so all the support seems to be available. Can you explain why by default you reduce the precision of float to 32 bits ? Is it because the library used expects a single precision float to be passed ? 2016-02-18 11:57 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > but in C (32bits) floats are 4 bytes, so when you do: > > ByteArray new > floatAt: 1 put: somePharoFloat; > > it will cast it to 4 bytes (if it fits which is most of the cases). > > but as I saidâ¦ it is an error I need to fix :) > > Esteban > > > On 12 Feb 2016, at 20:50, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > I don't understand. All BoxedFloat have 8 bytes, that's why they are > called BoxedFloat64. There are no 4-bytes floats in Pharo. Even in 32 bits. > > 2016-02-12 18:06 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > >> >> On 12 Feb 2016, at 17:50, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: >> >> On Fri, Feb 12, 2016 at 5:45 PM, Esteban Lorenzano <estebanlm(a)gmail.com> >> wrote: >> >>> Float>>#pointer >>> ^ (ByteArray new: FFIExternalType pointerSize) >>> floatAt: 1 put: self; >>> yourself >>> >> >> Yes it does the trick :) Thanks! >> >> >> yes and no (I made a mistake): that works because incidentally pointers >> and floats have same size (4 bytes)â¦ but can happen that it is not (doubles >> have 8 bytes)â¦ but is ok for now :) >> I will fix it correctly next week. >> >> Esteban >> > > >

Feb. 18, 2016

Re: [Pharo-dev] FFI BoxedFloat64 bug?

by Alexandre Bergel

Thanks Esteban! Alexandre > On Feb 18, 2016, at 8:11 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > >> On 17 Feb 2016, at 19:35, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >> >>> I don't understand. All BoxedFloat have 8 bytes, that's why they are called BoxedFloat64. There are no 4-bytes floats in Pharo. Even in 32 bits. >> >> I have some code that involve FFI and floats that was working before Spur. >> I got the error mentioned by Alex. >> Defining this pointer method gives a weird behavior. >> >> It would be great to have this fixed. > > probably because of what I just describedâ¦ I will commit a fix. > >> >> Alexandre >> >>> >>> 2016-02-12 18:06 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com>: >>> >>>> On 12 Feb 2016, at 17:50, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: >>>> >>>> On Fri, Feb 12, 2016 at 5:45 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>>> Float>>#pointer >>>> ^ (ByteArray new: FFIExternalType pointerSize) >>>> floatAt: 1 put: self; >>>> yourself >>>> >>>> Yes it does the trick :) Thanks! >>> >>> yes and no (I made a mistake): that works because incidentally pointers and floats have same size (4 bytes)â¦ but can happen that it is not (doubles have 8 bytes)â¦ but is ok for now :) >>> I will fix it correctly next week. >>> >>> Esteban >>> >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Feb. 18, 2016

Re: [Pharo-dev] Spotter suggestion

by Guille Polito

On 02/18/2016 01:40 PM, Tudor Girba wrote: > Hi, > > Please, letâs be reasonable. Wait, I do not see why I or my suggestion wouldn't be reasonable. I understand spotter as a tool to look for objects, that looks strongly designed to be used with the keyboard. However, to discover how to use it i have to use the mouse. Am I correct? So I did a suggestion of how I think the situation could be improved. Adding an explicit action in the list of found results, and shortcuts at the right, like in menu items. > We are talking about 5 actions. talking? taking? > Here is what we have now: > - You now have a help describing them using the central help system (btw, that is not used by other tools except for the Settings Browser). Which is great btw :) > - All actions are visibly clickable through some button. I stress all because this was a design goal. Well, to discern what is a button from what is not you should click... because there is no hover, border, background change... Item icons look like buttons but they are not, still the visual metaphore is the same, which is strange... > - The shortcuts are shown in the popup for each button. Yeah, now I see them. But I did not want to use the mouse at all... > - The popups appear faster and are larger than for the regular morphic tools so that you actually have a chance of using them and learning from them. But, I have to use the mouse, in a tool that is supposed to be used quick with just keyboard. Or am I wrong? > - If you press Shift you see all clickable buttons. This does not work in linux... > > I am not saying that we cannot do better. I know, perfection is of course the worse of evils. Ok, only after Cthulu. > I am simply saying that we should be reasonable. But I do not see why I wouldn't be reasonable. Was it an unreasonable suggestion? > > Cheers, > Doru > > >> On Feb 18, 2016, at 1:31 PM, Guille Polito <guillermopolito(a)gmail.com> wrote: >> >> Yeap, but it kind of kills the workflow... Why showing the shortcut in the tool is not an option? >> >> On 02/18/2016 01:18 PM, Tudor Girba wrote: >>> Hi, >>> >>> Spotter from the latest Pharo has a help button with shortcuts explained. >>> >>> Cheers, >>> Doru >>> >>> >>>> On Feb 18, 2016, at 12:14 PM, Guille Polito <guillermopolito(a)gmail.com> wrote: >>>> >>>> Hi Doru et al! >>>> >>>> I was here having difficulties to see how to use spotter, and how to dive into, and show more results, because the shortcuts are hidden if you don't know them by heart. >>>> >>>> So I thought, why the spotter ui does not >>>> - propose the shortcuts to dive at the right of the list? >>>> - propose some extra items for e.g., show all items? >>>> >>>> Something like the attached picture... >>>> >>>> What do you think? >>>> >>>> Guille >>>> <spotter.png> >>> -- >>> 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 > > "In a world where everything is moving ever faster, > one might have better chances to win by moving slower." > > > >

Feb. 18, 2016

Re: [Pharo-dev] How was BoxedFloat64 integrated into the image ?

by Ben Coman

On Thu, Feb 18, 2016 at 8:52 PM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > Beware, most client code should only refer to the visible faÃ§ade Float and > its API. > BoxedFloat64 is an implementation detail and is VM dependent. > We don't want client code to be VM dependent, do we? > I hope those references to BoxedFloat64 are rare. Should there be a Quality Assistant rule for this? cheers -ben > > 2016-02-18 11:47 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: >> >> Because we have compiled methods with BoxedFloat64 associations in the >> methods literals, but the source code still shows only "Float". >> >> 17638 Browsing calls on BoxedFloat64 shows methods with reference to >> BoxedFloat64 in the code >> >> >> >

Feb. 18, 2016

Re: [Pharo-dev] How was BoxedFloat64 integrated into the image ?

by Nicolas Cellier

Beware, most client code should only refer to the visible faÃ§ade Float and its API. BoxedFloat64 is an implementation detail and is VM dependent. We don't want client code to be VM dependent, do we? I hope those references to BoxedFloat64 are rare. 2016-02-18 11:47 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: > Because we have compiled methods with BoxedFloat64 associations in the > methods literals, but the source code still shows only "Float". > > 17638 > <https://pharo.fogbugz.com/f/cases/17638/Browsing-calls-on-BoxedFloat64-show…> > Browsing calls on BoxedFloat64 shows methods with reference to BoxedFloat64 > in the code > > > >

Feb. 18, 2016

Re: [Pharo-dev] Spotter suggestion

by Tudor Girba

Hi, Please, letâs be reasonable. We are talking about 5 actions. Here is what we have now: - You now have a help describing them using the central help system (btw, that is not used by other tools except for the Settings Browser). - All actions are visibly clickable through some button. I stress all because this was a design goal. - The shortcuts are shown in the popup for each button. - The popups appear faster and are larger than for the regular morphic tools so that you actually have a chance of using them and learning from them. - If you press Shift you see all clickable buttons. I am not saying that we cannot do better. I am simply saying that we should be reasonable. Cheers, Doru > On Feb 18, 2016, at 1:31 PM, Guille Polito <guillermopolito(a)gmail.com> wrote: > > Yeap, but it kind of kills the workflow... Why showing the shortcut in the tool is not an option? > > On 02/18/2016 01:18 PM, Tudor Girba wrote: >> Hi, >> >> Spotter from the latest Pharo has a help button with shortcuts explained. >> >> Cheers, >> Doru >> >> >>> On Feb 18, 2016, at 12:14 PM, Guille Polito <guillermopolito(a)gmail.com> wrote: >>> >>> Hi Doru et al! >>> >>> I was here having difficulties to see how to use spotter, and how to dive into, and show more results, because the shortcuts are hidden if you don't know them by heart. >>> >>> So I thought, why the spotter ui does not >>> - propose the shortcuts to dive at the right of the list? >>> - propose some extra items for e.g., show all items? >>> >>> Something like the attached picture... >>> >>> What do you think? >>> >>> Guille >>> <spotter.png> >> -- >> 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 "In a world where everything is moving ever faster, one might have better chances to win by moving slower."

Feb. 18, 2016

Re: [Pharo-dev] Spotter suggestion

by Peter UhnÃ¡k

Or have a shortcut that when held down will show the shortcuts. :) On Thu, Feb 18, 2016 at 1:31 PM, Guille Polito <guillermopolito(a)gmail.com> wrote: > Yeap, but it kind of kills the workflow... Why showing the shortcut in the > tool is not an option? > > > On 02/18/2016 01:18 PM, Tudor Girba wrote: > >> Hi, >> >> Spotter from the latest Pharo has a help button with shortcuts explained. >> >> Cheers, >> Doru >> >> >> On Feb 18, 2016, at 12:14 PM, Guille Polito <guillermopolito(a)gmail.com> >>> wrote: >>> >>> Hi Doru et al! >>> >>> I was here having difficulties to see how to use spotter, and how to >>> dive into, and show more results, because the shortcuts are hidden if you >>> don't know them by heart. >>> >>> So I thought, why the spotter ui does not >>> - propose the shortcuts to dive at the right of the list? >>> - propose some extra items for e.g., show all items? >>> >>> Something like the attached picture... >>> >>> What do you think? >>> >>> Guille >>> <spotter.png> >>> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "Not knowing how to do something is not an argument for how it cannot be >> done." >> >> >> > >

Feb. 18, 2016