Re: [Pharo-dev] athens dead code?

[Igor Stasenko]

On 27 January 2017 at 09:17, stepharong  wrote:

> On Fri, 27 Jan 2017 00:31:11 +0100, Igor Stasenko 
> wrote:
>
>
>
> On 27 January 2017 at 00:06, stepharong  wrote:
>
>>
>> accept: aVisitor
>> ^ aVisitor lineSegment: self
>> accept: aVisitor
>> ^ aVisitor closeSegment: self
>> accept: aVisitor
>> ^ aVisitor moveSegment: self
>>
>> seems to invoke methods that do not exit
>> I check AthensLIneSegment is used so I do not understand why the methods
>> are broken.
>>
>> this is a part of visitor api for path segments.
>
>
> I know but where is the visitor?
>
> if you remove it, then users cannot use it
> for iterating trough path segments for converting them etc etc..
> of course, it may be nit used by Athens itself.. but it doesn't means it
> is useless.
>
>
> Where is the visitor? Why accept: are not packaged with it? Does it use
> DNU trick?
> In my imagine there is no implementor of moveSegment: closeSegment:
>
>
> why there should be any, if nobody using this feature, yet? so you don't
have a single visitor.
you could add a test case for coverage, so it won't bother you that there's
no implementors of
given selector in image :)

iirc, i used it for path transformation(s) code.. which then get removed.


-- 
Best regards,
Igor Stasenko.

Re: [Pharo-dev] [bloc] addressing the moz2d issue

[stepharong]

Thanks for this analysis

I call it the reality principle
Who will pay for it?
How many engineers can community afford?
Do you know how much other systems invest in graphical frameworks?
It is not a science project, isn't it?
There is always a tension between what we can achieve and the goal.
Now give 10 M Euros and I have no problem with your vision.

Now can you reply to Ronie's email.

Stef



On Thu, 26 Jan 2017 23:45:17 +0100, Aliaksei Syrel   
wrote:



Hi

(My previous email was not a joke, I don't try to troll anyone. Let  
tolls do their job in other places)
Let's forget Moz2D for a moment :) Imagine that it does not exist. It  
was done just for fun and is even not in pharo repo.  
(https://github.com/syrel/Moz2D). We needed something that works >and it  
was made investing just a few months of time of a single anonymous  
student during summer exams session and vacations.


I would like to start maybe one of the most important discussion that  
will influence Pharo and will dictate how system will look like in a few  
years. I invite everyone to join this discussion, >especially board and  
consortium members. Because here is where business starts.


There are some real questions:
Do we need Bloc or Morphic2 or %name your favourite framework%?
How advanced and modern do you want it to be?
What technology stack do we want to use for our new graphical framework?
What platforms and operating systems do we want to support?
How flexible technology stack should be? (some parts may change in the  
future)

Who will pay for it?
How many engineers can community afford?
Do you know how much other systems invest in graphical frameworks?
It is not a science project, isn't it?
Let me first put my two cents in.

Low-level UI framework (without widgets) consists of multiple parts:
Vector graphics library to render shapes (fill, stroke, path builder,  
composition and blending operators)
Font service library (to support different font formats and collect  
information about local fonts installed in the system)
Text layout engine (this is where glyph positioning magic happens, link  
above too)
Text shaping engine (for high quality text rendering, to understand the  
problem => http://behdad.org/text/)
Complex script library (to support ligatures, split glyphs and other  
UTF8 stuff, remember  
https://github.com/minimaxir/big-list-of-naughty-strings)
Image processing library (for various image effects, like gaussian blur,  
morphology filter, gamma, displacement map, just to name a few)
Hardware acceleration. Software rendering is nice, however, modern UIs  
are full of fancy stuff that require hardware acceleration.
Window and Event management library. With support of borderless and  
semi-transparent windows + good support of touchpad.
Custom written "Glue" library that allows all components to work  
together. Since modern libs are implemented in C++ we would need to  
implement C wrapper and a lot of integration >tests.

Make the whole beast cross platform.

Did I miss something?

Here are some modern technologies commonly used for mentioned parts:
Skia, Direct2D, CoreGraphics, Cairo
Fontconfig, Freetype2
HarfBuzz
Pango, OpenType
Graphite2, FriBidi
Imagemagic, SVG filters libraries
Vulkan, OpenGL
wxWidgets, QT, GTK, SDL2
todo
todo
Luckily Pango covers bullets 2 - 5. It indeed sounds like a great idea!

Let's assume that we stop on Cairo + Pango. According to pango.com

The integration of Pango with Cairo (http://cairographics.org/)  
provides a complete solution with high quality text handling and  
graphics rendering.


According to the this potential technology stack we will have:
Cairo for vector graphics and rendering of basic shapes
Pango for text rendering
SDL2 for window and events management
What we will not get:
Support of filters; Cairo does not support gaussian blur. 3D  
transformations, we will not be able to not implement card flip  
animation. Never reach the same performance if using platform >native  
frameworks (e.g. Direct2D on windows). Cairo will not die, but there is  
zero progress.
Vulkan support. Never with cairo. Pure OpenGL too (try to compile  
cairo-gl on mac, good luck!) There is a way to compile it with quartz  
support. As of version 2.7.9, XQuartz does not >provide support for  
high-resolution Retina displays to X11 apps, which run in pixel-doubled  
mode on high-resolution displays.  
(https://bugs.freedesktop.org/show_bug.cgi?id=92777).
Borderless or transparent window with SDL2. Also, did you notice that  
sdl2 window turns black/white while resizing? There is no way to get a  
continuous window resize event with SDL2  
>(https://bugzilla.libsdl.org/show_bug.cgi?id=2077). The issue is that  
events stop firing while user is resizing a window because main thread  
is blocked. Bug is already 3 years >old. Indeed SDL2 is used for games,  
however how often do gamers resize game window?
Stateless API. Must have for a graphical framework like Bloc 

Re: [Pharo-dev] athens dead code?

[stepharong]

On Fri, 27 Jan 2017 00:31:11 +0100, Igor Stasenko   
wrote:





On 27 January 2017 at 00:06, stepharong  wrote:


accept: aVisitor
   ^ aVisitor lineSegment: self
accept: aVisitor
   ^ aVisitor closeSegment: self
accept: aVisitor
   ^ aVisitor moveSegment: self

seems to invoke methods that do not exit
I check AthensLIneSegment is used so I do not understand why the  
methods are broken.



this is a part of visitor api for path segments.


I know but where is the visitor?


if you remove it, then users cannot use it
for iterating trough path segments for converting them etc etc..
of course, it may be nit used by Athens itself.. but it doesn't means it  
is useless.


Where is the visitor? Why accept: are not packaged with it? Does it use  
DNU trick?

In my imagine there is no implementor of moveSegment: closeSegment:







--

Using Opera's mail client: http://www.opera.com/mail/





--Best regards,
Igor Stasenko.




--
Using Opera's mail client: http://www.opera.com/mail/

Re: [Pharo-dev] HandMorph>>#processEvents

[stepharong]

Probably a bug.
I started to clean this part 4 years ago and my changes got killed by SDL  
+ OS Window and

now apparently SDL 20 is not good enough.
May be in 3 years from now it will be cleaned, who knows.

Stef


Why do we have this twice in processEvents?

self mouseOverHandler processMouseOver: lastMouseEvent

?

Well, maybe that is not there that things happen but if you spy on  
mouseEnter and mouseLeave events, you will notice that they are both  
sent **twice** all the time.


I think that this happens so often that we would benefit from getting  
rid of that twice enter/leave thing (and it is really annoying to have  
to deal with these two events when you expect only one. I >am not  
"entering entering" a rectangle).




processEvents
"Process user input events from the local input devices."

| evt evtBuf type hadAny |
	ActiveEvent ifNotNil:			["Meaning that we were invoked from within an  
event response.

Make sure z-order is up to date"

self mouseOverHandler processMouseOver: lastMouseEvent].
hadAny := false.
	[(evtBuf := Sensor nextEvent) isNil] whileFalse:			[evt := nil.	"for  
unknown event types"

type := evtBuf first.
			type = EventTypeMouse ifTrue: [recentModifiers := evtBuf sixth. evt  
:= self generateMouseEvent: evtBuf].
			type = EventTypeKeyboardifTrue: [recentModifiers := evtBuf fifth.  
evt := self generateKeyboardEvent: evtBuf].
			type = EventTypeDragDropFilesifTrue: [evt := self  
generateDropFilesEvent: evtBuf].

type = EventTypeWindow
ifTrue:[evt := self generateWindowEvent: 
evtBuf].   
"All other events are ignored"
(type ~= EventTypeDragDropFiles and: [evt isNil]) 
ifTrue: [^self].
evt isNil   ifFalse:  
  ["Finally, handle it"

self handleEvent: evt.
hadAny := true.

	"For better user feedback, return immediately after a mouse event  
has been processed."

(evt isMouse and: [evt isMouseWheel 
not]) ifTrue: [^self]]].
"note: if we come here we didn't have any mouse events"
	mouseClickState notNil		ifTrue:			["No mouse events during this cycle.  
Make sure click states time out accordingly"


mouseClickState handleEvent: lastMouseEvent asMouseMove 
from: self].
hadAny  ifFalse:["No pending events. Make 
sure z-order is up to date"

self mouseOverHandler processMouseOver: lastMouseEvent]

Clues?

Phil




--
Using Opera's mail client: http://www.opera.com/mail/

Re: [Pharo-dev] memoized vs once

[philippe.b...@highoctane.be]

Le 27 janv. 2017 05:55, "Ben Coman"  a écrit :

On Fri, Jan 27, 2017 at 4:32 AM, Eliot Miranda 
wrote:
>
>
> Now, descending to the implementations, I understand that Ben's memorize...
>

btw, I feel a bit of an impostor having it called "my" memorize.  It was
Torsten's initiative based on gist by John Cromartie.
https://pharo.fogbugz.com/f/cases/14458/Add-BlockClosure-memoized


Thx for the link.

So, multi arg blocks someone?

Phil


cheers -ben

>

Re: [Pharo-dev] memoized vs once

[Ben Coman]

On Fri, Jan 27, 2017 at 4:32 AM, Eliot Miranda 
wrote:
>
>
> Now, descending to the implementations, I understand that Ben's memorize...
>

btw, I feel a bit of an impostor having it called "my" memorize.  It was
Torsten's initiative based on gist by John Cromartie.
https://pharo.fogbugz.com/f/cases/14458/Add-BlockClosure-memoized

cheers -ben

>

Re: [Pharo-dev] memoized vs once

[Igor Stasenko]

On 27 January 2017 at 03:45, Igor Stasenko  wrote:

>
>
> On 27 January 2017 at 02:28, Ben Coman  wrote:
>
>> On Fri, Jan 27, 2017 at 7:35 AM, Igor Stasenko 
>> wrote:
>> >
>> >
>> > On 27 January 2017 at 01:30, Ben Coman  wrote:
>> >>
>> >> On Fri, Jan 27, 2017 at 6:02 AM, stepharong 
>> wrote:
>> >> > On Thu, 26 Jan 2017 20:38:49 +0100, Torsten Bergmann > >
>> >> > wrote:
>> >> >
>> >> >> stepharong wrote:
>> >> >>>
>> >> >>> can we rename this selector?
>> >> >>> asMethodConst should be at least be renamed to asConstantMethod
>> >> >>
>> >> >>
>> >> >> When you use "as {something}" then "something" depicts the result of
>> >> >> the
>> >> >> conversion message sent to an object.
>> >> >>
>> >> >> Like in #asNumber or #asString which shows to what the receiver
>> will be
>> >> >> converted.
>> >> >
>> >> >
>> >> > Yes I thought that it was doing that.
>> >> >>
>> >> >>
>> >> >>
>> >> >> My understanding is that in the case discussed the receiver object
>> is
>> >> >> NOT converted to a constant unchangeable method, so
>> #asConstantMethod
>> >> >> would
>> >> >> not fit as a selector.
>> >> >>
>> >> >> Instead it is sent to an object that afterwards is a constant
>> within a
>> >> >> method
>> >> >> (so it will not be evaluated later at runtime again) so IMHO
>> >> >> #asMethodConstant
>> >> >> instead of #asMethodConst would be better.
>> >> >
>> >> >
>> >> > I do not understand any of them.
>> >>
>> >> method constant = constant of a method
>>
>>
>> >> constant method = method that does not change
>> >>
>> > are you sure?
>>
>> pretty sure. 'method' is the subject. 'constant' is the adjective that
>> modifies the subject.
>> Its a bit hard to explain that intrinsic feeling of what is right,
>> but maybe If the adjective follows the subject its usually
>> separated by little joining words.
>> http://www.grammar-monster.com/glossary/adjective_definition.htm
>>
>> > maybe it is
>> > constant method = method that returns constant?
>>
>> For me this does not compute.
>> But I understand rules differ in other languages and its hard to avoid
>> subtle influences from your primary language.
>>
>
> heh.. you see my pain! right now i have to deal with C++
> and seeing all these
> const Type & foo const..
> and cannot parse it..
> :)
>
> And still, it could just be my personal bias.
>> So if you & Stef find it ambiguous, it may be for others and we should
>> aim to avoid that.
>>
>> Well, we have more general term for objects that do not change over their
> lifetime - immutable. And it is moare precise,
>
(or if not general, but well settled)


> if we're talking in smalltalk context.
> So, why borrowing rather alien term into our ecosystem, because i barely
> heard that anyone
> were using it, and saying something like 'constant object' or something
> like this, when talking smalltalk context.
>
> Because when you open this 'can' of constant method, what does it means
> being a constant?
> Is is that method's properties won't change, or all object(s) it is
> pointing to never change as well?
>
>
>> cheers -ben
>>
>> >
>> > apparently, that's why 'constant' term doesn't fits there, because
>> there's
>> > so many confusion about it. what are the constant in dynamic system,
>> after
>> > all?
>>
>>
>
>
> --
> Best regards,
> Igor Stasenko.
>



-- 
Best regards,
Igor Stasenko.

Re: [Pharo-dev] memoized vs once

[Igor Stasenko]

On 27 January 2017 at 02:28, Ben Coman  wrote:

> On Fri, Jan 27, 2017 at 7:35 AM, Igor Stasenko  wrote:
> >
> >
> > On 27 January 2017 at 01:30, Ben Coman  wrote:
> >>
> >> On Fri, Jan 27, 2017 at 6:02 AM, stepharong  wrote:
> >> > On Thu, 26 Jan 2017 20:38:49 +0100, Torsten Bergmann 
> >> > wrote:
> >> >
> >> >> stepharong wrote:
> >> >>>
> >> >>> can we rename this selector?
> >> >>> asMethodConst should be at least be renamed to asConstantMethod
> >> >>
> >> >>
> >> >> When you use "as {something}" then "something" depicts the result of
> >> >> the
> >> >> conversion message sent to an object.
> >> >>
> >> >> Like in #asNumber or #asString which shows to what the receiver will
> be
> >> >> converted.
> >> >
> >> >
> >> > Yes I thought that it was doing that.
> >> >>
> >> >>
> >> >>
> >> >> My understanding is that in the case discussed the receiver object is
> >> >> NOT converted to a constant unchangeable method, so #asConstantMethod
> >> >> would
> >> >> not fit as a selector.
> >> >>
> >> >> Instead it is sent to an object that afterwards is a constant within
> a
> >> >> method
> >> >> (so it will not be evaluated later at runtime again) so IMHO
> >> >> #asMethodConstant
> >> >> instead of #asMethodConst would be better.
> >> >
> >> >
> >> > I do not understand any of them.
> >>
> >> method constant = constant of a method
>
>
> >> constant method = method that does not change
> >>
> > are you sure?
>
> pretty sure. 'method' is the subject. 'constant' is the adjective that
> modifies the subject.
> Its a bit hard to explain that intrinsic feeling of what is right,
> but maybe If the adjective follows the subject its usually
> separated by little joining words.
> http://www.grammar-monster.com/glossary/adjective_definition.htm
>
> > maybe it is
> > constant method = method that returns constant?
>
> For me this does not compute.
> But I understand rules differ in other languages and its hard to avoid
> subtle influences from your primary language.
>

heh.. you see my pain! right now i have to deal with C++
and seeing all these
const Type & foo const..
and cannot parse it..
:)

And still, it could just be my personal bias.
> So if you & Stef find it ambiguous, it may be for others and we should
> aim to avoid that.
>
> Well, we have more general term for objects that do not change over their
lifetime - immutable. And it is moare precise,
if we're talking in smalltalk context.
So, why borrowing rather alien term into our ecosystem, because i barely
heard that anyone
were using it, and saying something like 'constant object' or something
like this, when talking smalltalk context.

Because when you open this 'can' of constant method, what does it means
being a constant?
Is is that method's properties won't change, or all object(s) it is
pointing to never change as well?


> cheers -ben
>
> >
> > apparently, that's why 'constant' term doesn't fits there, because
> there's
> > so many confusion about it. what are the constant in dynamic system,
> after
> > all?
>
>


-- 
Best regards,
Igor Stasenko.

Re: [Pharo-dev] Odd (and wrong) implementation of Float>>sign

[Martin McClure]

On 01/26/2017 05:12 PM, Nicolas Cellier wrote:
> -0.0 sign is answering -1 at least since 1998, so we might have get used
> to it ;)
> I've done the job on Squeak trunk, the answer is we need to revise some
> senders

Thanks for looking into it. I'm afraid I don't have time to dig into
this one further. A GemStone user noticed the difference between Pharo
and GemStone behavior, and in this case it looked like it was the Pharo
behavior that made less sense.

Regards,

-Martin

Re: [Pharo-dev] Odd (and wrong) implementation of Float>>sign

[Nicolas Cellier]

2017-01-27 0:15 GMT+01:00 Martin McClure :

> On 01/26/2017 12:47 PM, Nicolas Cellier wrote:
> >
> >
> > 2017-01-26 21:22 GMT+01:00 Martin McClure  > >:
>
> [...]
>
> > The current implementation of #sign is
> >
> > self > 0 ifTrue: [^ 1].
> > (self < 0 or: [((self at: 1) bitShift: -31) = 1]) ifTrue: [^ -1].
> > ^ 0
> >
> > I'd propose factoring this into two simpler methods:
> >
> > sign
> > self > 0 ifTrue: [^ 1].
> > self < 0 ifTrue: [^ -1].
> > ^ 0
> >
> >
> > maybe self isNan ifTrue [^-1 raisedTo: self signBit], or the standard
> > tells it should be 0 too?
>
> This addition makes sense to me.
>
> The standards help a *little* and suggest on alternative.
>
> ANSI Smalltalk acts like NaNs don't exist (basically, it lets
> implementers do what they want for those values).
>
> ANSI Smalltalk relies on ISO/IEC 10967 of 1994 for numerics (even when
> it *cannot* rely on 10967, it does, sigh). That spec only defines a
> "sign" operation for floats with a definite numeric value, and says that
> operations are *permitted* to accept infinities and NaNs, but does not
> require this, nor say what the answer should be.
>
> The 2007 update of 10967 is somewhat more helpful. It replaces the
> "sign" operation with one called "signum" which returns 1, -1, or NaN.
> It returns 1 for positive zero and positive infinity, and -1 for
> negative zero and negative infinity. If given a qNaN, it returns a qNaN.
> If given a signaling NaN, it returns a qNaN but notifies the application
> of an "invalid" situation.
>
> If we extend this to Smalltalk, I *think* this would have us answer qNaN
> for qNaN, and for a sNaN signal a resumable exception (a Notification,
> perhaps?) that if resumed would answer qNaN. This also seems to make
> some sense -- NaNs are supposed to propagate, and asking the just plain
> "sign" (as opposed to signBit or isSignMinus) of a NaN is more or less
> nonsense. But if you prefer (-1 raisedTo: self signBit) I won't complain.
>
> I'm OK with answering NaN, it was just a question.
An incomplete specification is an open door to useless differences


> >
> > That means that we'd have to refactor most (all?) senders of sign...
> >
>
> Certainly should audit senders of sign, but I'd expect that most senders
> don't really care about what the sign of -0.0 or NaNs are. The answer
> would remain the same for all other receivers.
>
> Regards,
>
> -Martin
>
>
-0.0 sign is answering -1 at least since 1998, so we might have get used to
it ;)
I've done the job on Squeak trunk, the answer is we need to revise some
senders

Re: [Pharo-dev] [Ann] Calypso update: method browser and better UI

[Ben Coman]

On Fri, Jan 27, 2017 at 5:33 AM, Denis Kudriashov  wrote:
>
> 2017-01-26 21:09 GMT+01:00 Bernhard Pieber :
>>
>> > - no Spec text model anymore. Rubric widgets are used directly. It
>> > improves speed of building text editors
>> This is really great. I love the Method Browser.
>
>
> I also forgot to show in demo that it is possible to drag window tab to get
> normal separate window (just drag it to free space in World).
> I hope it will be enough because to my mind tabs are most suitable approach
> but when you really need separate window you will just drag tab out.

Cool! This should be intuitive enough from peoples experience with web browsers.
cheers -ben

Re: [Pharo-dev] [bloc] addressing the moz2d issue

[Ronie Salgado]

Hi,

Vulkan support. Never with cairo. Pure OpenGL too (try to compile cairo-gl
> on mac, good luck!) There is a way to compile it with quartz support. As of
> version 2.7.9, *XQuartz does not provide support for high-resolution
> Retina displays to X11 apps*, which run in pixel-doubled mode on
> high-resolution displays. (https://bugs.freedesktop.org/
> show_bug.cgi?id=92777).

Do not rely on Vulkan for core libraries now. It is very green and it has
lot of issues. For making Woden 2 with Vulkan on Linux, I had to fix and
debug the Intel Vulkan driver myself. Anyway, Athens over Vulkan it is also
not a problem, because I did an (incomplete) Athens backend using Woden 2.
I have an abstraction for Vulkan(Linux and Windows, probably never
available on apple machines), Metal(OS X and iOS) and D3D 12 (Windows, XBox
One devkit). Right now I am working on getting Woden 2 working with Metal,
which only works on 64 bits mode.

Low-level UI framework (without widgets) consists of multiple parts:
>
>1. Vector graphics library to render shapes (fill, stroke, path
>builder, composition and blending operators)
>2. Font service library (to support different font formats and collect
>information about local fonts installed in the system)
>3. Text layout engine (this is where glyph positioning magic happens,
>link above too)
>4. Text shaping engine (for high quality text rendering, to understand
>the problem => http://behdad.org/text/)
>5. Complex script library (to support ligatures, split glyphs and
>other UTF8 stuff, remember https://github.com/mi
>nimaxir/big-list-of-naughty-strings
>)
>6. Image processing library (for various image effects, like gaussian
>blur, morphology filter, gamma, displacement map, just to name a few)
>7. Hardware acceleration. Software rendering is nice, however, modern
>UIs are full of fancy stuff that require hardware acceleration.
>8. Window and Event management library. With support of borderless and
>semi-transparent windows + good support of touchpad.
>9. Custom written "Glue" library that allows all components to work
>together. Since modern libs are implemented in C++ we would need to
>implement C wrapper and a lot of integration tests.
>10. Make the whole beast cross platform.
>
>
> Did I miss something?
>
You cannot have SVG style vectorial graphics and high performance graphics
in the same time. SVG style paths are really hard to implement, and they
cannot be implemented efficiently on hardware. Path filling and stroking
are global operations that are best implemented using a serial software
scanliner. GPUs are only able to rasterize points, lines, triangles and
quads (usually decomposed in triangles). The primitives supported by GPUs
only require local information, so they are very efficient to render.

I do not understand why are you trying to copy the whole web rendering
architecture, which is awful in terms of performance. I think that it is a
far better idea to design a 2D graphics API, with the basic rendering
primitives that are required for implementing a Widget toolkit, and then
leave the SVG style vectorial graphics for some very special cases, such as
drawing an actual SVG. This minimalistic graphics API could be implemented
using Athens in the first place, then porting to OpenGL 2.0 ES for getting
a performance boost, and then when there is a volunteer, it could be
implemented with whatever bleeding edge or platform specific graphics API
is available. The basics graphics primitives that I have in mind are the
following:

- Points
- Lines (with width or without it)
- Triangles
- Convex polygons

- Rounded rectangle
- Circle / Ellipses

- Render into a texture ( required for doing filtering)
- Textured primitive
- Some 2D filters, with the ability of making them optional

- Text/Glyph drawing

The graphics API should be explicit in terms that they could be two
different memory spaces (CPU memory vs dedicated GPU memory), and that
transferring resource such as textures can be very expensive. This kind of
2D graphics API could be also useful for developing 2D games using Pharo
and OSWindow, an area where I am bit interested because it is far easier
than a full 3D renderer.

The API could be made partially stateless by passing the full description
of how to render the primitives (colored or not, textured or not, 1 or 10
pixel wide lines, etc). It is impossible to make the API completely
stateless, because the framebuffer where the rendering is happening by
definition is not stateless ;)

Best regards,
Ronei

2017-01-26 20:36 GMT-03:00 Martin McClure :

> On 01/26/2017 02:45 PM, Aliaksei Syrel wrote:
> > There are some real questions:
> >
> >  1. Do we need Bloc or Morphic2 or %name your favourite framework%?
> >  2. How advanced and modern do you want it to be?
> >  3. What technology stack do we want to use 

Re: [Pharo-dev] memoized vs once

[Ben Coman]

On Fri, Jan 27, 2017 at 7:35 AM, Igor Stasenko  wrote:
>
>
> On 27 January 2017 at 01:30, Ben Coman  wrote:
>>
>> On Fri, Jan 27, 2017 at 6:02 AM, stepharong  wrote:
>> > On Thu, 26 Jan 2017 20:38:49 +0100, Torsten Bergmann 
>> > wrote:
>> >
>> >> stepharong wrote:
>> >>>
>> >>> can we rename this selector?
>> >>> asMethodConst should be at least be renamed to asConstantMethod
>> >>
>> >>
>> >> When you use "as {something}" then "something" depicts the result of
>> >> the
>> >> conversion message sent to an object.
>> >>
>> >> Like in #asNumber or #asString which shows to what the receiver will be
>> >> converted.
>> >
>> >
>> > Yes I thought that it was doing that.
>> >>
>> >>
>> >>
>> >> My understanding is that in the case discussed the receiver object is
>> >> NOT converted to a constant unchangeable method, so #asConstantMethod
>> >> would
>> >> not fit as a selector.
>> >>
>> >> Instead it is sent to an object that afterwards is a constant within a
>> >> method
>> >> (so it will not be evaluated later at runtime again) so IMHO
>> >> #asMethodConstant
>> >> instead of #asMethodConst would be better.
>> >
>> >
>> > I do not understand any of them.
>>
>> method constant = constant of a method


>> constant method = method that does not change
>>
> are you sure?

pretty sure. 'method' is the subject. 'constant' is the adjective that
modifies the subject.
Its a bit hard to explain that intrinsic feeling of what is right,
but maybe If the adjective follows the subject its usually
separated by little joining words.
http://www.grammar-monster.com/glossary/adjective_definition.htm

> maybe it is
> constant method = method that returns constant?

For me this does not compute.
But I understand rules differ in other languages and its hard to avoid
subtle influences from your primary language.
And still, it could just be my personal bias.
So if you & Stef find it ambiguous, it may be for others and we should
aim to avoid that.

cheers -ben

>
> apparently, that's why 'constant' term doesn't fits there, because there's
> so many confusion about it. what are the constant in dynamic system, after
> all?

Re: [Pharo-dev] [bloc] addressing the moz2d issue

[Martin McClure]

On 01/26/2017 02:45 PM, Aliaksei Syrel wrote:
> There are some real questions:
> 
>  1. Do we need Bloc or Morphic2 or %name your favourite framework%?
>  2. How advanced and modern do you want it to be?
>  3. What technology stack do we want to use for our new graphical framework?
>  4. What platforms and operating systems do we want to support?
>  5. How flexible technology stack should be? (some parts may change in
> the future)
>  6. Who will pay for it?
>  7. How many engineers can community afford?
>  8. Do you know how much other systems invest in graphical frameworks?
>  9. It is not a science project, isn't it?
> 

[...]

Thanks for the analysis, Alex. It sounds like using Moz2d saves a lot of
work...

-Martin

Re: [Pharo-dev] memoized vs once

[Igor Stasenko]

On 27 January 2017 at 01:30, Ben Coman  wrote:

> On Fri, Jan 27, 2017 at 6:02 AM, stepharong  wrote:
> > On Thu, 26 Jan 2017 20:38:49 +0100, Torsten Bergmann 
> wrote:
> >
> >> stepharong wrote:
> >>>
> >>> can we rename this selector?
> >>> asMethodConst should be at least be renamed to asConstantMethod
> >>
> >>
> >> When you use "as {something}" then "something" depicts the result of the
> >> conversion message sent to an object.
> >>
> >> Like in #asNumber or #asString which shows to what the receiver will be
> >> converted.
> >
> >
> > Yes I thought that it was doing that.
> >>
> >>
> >>
> >> My understanding is that in the case discussed the receiver object is
> >> NOT converted to a constant unchangeable method, so #asConstantMethod
> >> would
> >> not fit as a selector.
> >>
> >> Instead it is sent to an object that afterwards is a constant within a
> >> method
> >> (so it will not be evaluated later at runtime again) so IMHO
> >> #asMethodConstant
> >> instead of #asMethodConst would be better.
> >
> >
> > I do not understand any of them.
>
> method constant = constant of a method
> constant method = method that does not change
>
> are you sure?
maybe it is
constant method = method that returns constant?

apparently, that's why 'constant' term doesn't fits there, because there's
so many confusion about it. what are the constant in dynamic system, after
all?

HTH, cheers -ben
>
>


-- 
Best regards,
Igor Stasenko.

Re: [Pharo-dev] athens dead code?

[Igor Stasenko]

On 27 January 2017 at 00:06, stepharong  wrote:

>
> accept: aVisitor
> ^ aVisitor lineSegment: self
> accept: aVisitor
> ^ aVisitor closeSegment: self
> accept: aVisitor
> ^ aVisitor moveSegment: self
>
> seems to invoke methods that do not exit
> I check AthensLIneSegment is used so I do not understand why the methods
> are broken.
>
> this is a part of visitor api for path segments. if you remove it, then
users cannot use it
for iterating trough path segments for converting them etc etc..
of course, it may be nit used by Athens itself.. but it doesn't means it is
useless.


>
> --
> Using Opera's mail client: http://www.opera.com/mail/
>
>


-- 
Best regards,
Igor Stasenko.

Re: [Pharo-dev] memoized vs once

[Ben Coman]

On Fri, Jan 27, 2017 at 6:02 AM, stepharong  wrote:
> On Thu, 26 Jan 2017 20:38:49 +0100, Torsten Bergmann  wrote:
>
>> stepharong wrote:
>>>
>>> can we rename this selector?
>>> asMethodConst should be at least be renamed to asConstantMethod
>>
>>
>> When you use "as {something}" then "something" depicts the result of the
>> conversion message sent to an object.
>>
>> Like in #asNumber or #asString which shows to what the receiver will be
>> converted.
>
>
> Yes I thought that it was doing that.
>>
>>
>>
>> My understanding is that in the case discussed the receiver object is
>> NOT converted to a constant unchangeable method, so #asConstantMethod
>> would
>> not fit as a selector.
>>
>> Instead it is sent to an object that afterwards is a constant within a
>> method
>> (so it will not be evaluated later at runtime again) so IMHO
>> #asMethodConstant
>> instead of #asMethodConst would be better.
>
>
> I do not understand any of them.

method constant = constant of a method
constant method = method that does not change

HTH, cheers -ben

Re: [Pharo-dev] memoized vs once

[Igor Stasenko]

On 27 January 2017 at 00:28, Chris Cunningham 
wrote:

> On Thu, Jan 26, 2017 at 2:02 PM, stepharong  wrote:
>
>> On Thu, 26 Jan 2017 20:38:49 +0100, Torsten Bergmann 
>> wrote:
>>
>> ...
>>
>>
>>> Instead it is sent to an object that afterwards is a constant within a
>>> method
>>> (so it will not be evaluated later at runtime again) so IMHO
>>> #asMethodConstant
>>> instead of #asMethodConst would be better.
>>>
>>
>> I do not understand any of them.
>>
>> In other words, this is creating a constant inside the method
> (#asMethodConstant) instead of making the method return a constant (which
> would be your #asConstantMethod).
> If I have that right.
> In any case, not having the contracted 'Const' would be nice.
>
> ah.. that sounds similar to what i proposed for computed literals, that
has been computed at compilation time and placed in method's literal frame,
a simple catch by reserving special selector for it, i.e..:


mymethod
 ^ (something that should be computed , and takes a loong time)
asMethodLiteral


but that, of course, won't work if you would want to cache results based on
method's input parameters.


> -cbc
>
>> --
>> Using Opera's mail client: http://www.opera.com/mail/
>>
>>
>


-- 
Best regards,
Igor Stasenko.

Re: [Pharo-dev] [bloc] addressing the moz2d issue

[Aliaksei Syrel]

Hi

*According to conclusion above, we will plan how to migrate to Cairo.*
We will need help with Pango.

Cheers,
Alex

On 26 January 2017 at 23:45, Aliaksei Syrel  wrote:

> Hi
>
> (My previous email was not a joke, I don't try to troll anyone. Let tolls
> do their job in other places)
> *Let's forget Moz2D for a moment :) Imagine that it does not exist. *It
> was done just for fun and is even not in pharo repo. (
> https://github.com/syrel/Moz2D). We needed something that works and it
> was made investing just a few months of time of a single anonymous student
> during summer exams session and vacations.
>
> I would like to start maybe one of the most important discussion that will
> influence Pharo and will dictate how system will look like in a few years.
> I invite everyone to join this discussion, especially board and consortium
> members. Because here is where business starts.
>
> There are some real questions:
>
>1. Do we need Bloc or Morphic2 or %name your favourite framework%?
>2. How advanced and modern do you want it to be?
>3. What technology stack do we want to use for our new graphical
>framework?
>4. What platforms and operating systems do we want to support?
>5. How flexible technology stack should be? (some parts may change in
>the future)
>6. Who will pay for it?
>7. How many engineers can community afford?
>8. Do you know how much other systems invest in graphical frameworks?
>9. It is not a science project, isn't it?
>
> Let me first put my two cents in.
>
> Low-level UI framework (without widgets) consists of multiple parts:
>
>1. Vector graphics library to render shapes (fill, stroke, path
>builder, composition and blending operators)
>2. Font service library (to support different font formats and collect
>information about local fonts installed in the system)
>3. Text layout engine (this is where glyph positioning magic happens,
>link above too)
>4. Text shaping engine (for high quality text rendering, to understand
>the problem => http://behdad.org/text/)
>5. Complex script library (to support ligatures, split glyphs and
>other UTF8 stuff, remember https://github.com/mi
>nimaxir/big-list-of-naughty-strings
>)
>6. Image processing library (for various image effects, like gaussian
>blur, morphology filter, gamma, displacement map, just to name a few)
>7. Hardware acceleration. Software rendering is nice, however, modern
>UIs are full of fancy stuff that require hardware acceleration.
>8. Window and Event management library. With support of borderless and
>semi-transparent windows + good support of touchpad.
>9. Custom written "Glue" library that allows all components to work
>together. Since modern libs are implemented in C++ we would need to
>implement C wrapper and a lot of integration tests.
>10. Make the whole beast cross platform.
>
>
> Did I miss something?
>
> Here are some modern technologies commonly used for mentioned parts:
>
>1. Skia, Direct2D, CoreGraphics, Cairo
>2. Fontconfig, Freetype2
>3. HarfBuzz
>4. Pango, OpenType
>5. Graphite2, FriBidi
>6. Imagemagic, SVG filters libraries
>7. Vulkan, OpenGL
>8. wxWidgets, QT, GTK, SDL2
>9. todo
>10. todo
>
> Luckily Pango covers bullets 2 - 5. It indeed sounds like a great idea!
>
> Let's assume that we stop on Cairo + Pango. According to pango.com
>
> The integration of Pango with Cairo (http://cairographics.org/) provides
>> a complete solution with high quality text handling and graphics rendering.
>
>
> According to the this potential technology stack we will have:
>
>- Cairo for vector graphics and rendering of basic shapes
>- Pango for text rendering
>- SDL2 for window and events management
>
> What we will not get:
>
>- Support of filters; Cairo does not support gaussian blur. 3D
>transformations, we will not be able to not implement card flip animation.
>Never reach the same performance if using platform native frameworks (e.g.
>Direct2D on windows). Cairo will not die, but there is zero progress.
>- Vulkan support. Never with cairo. Pure OpenGL too (try to compile
>cairo-gl on mac, good luck!) There is a way to compile it with quartz
>support. As of version 2.7.9, *XQuartz does not provide support for
>high-resolution Retina displays to X11 apps*, which run in
>pixel-doubled mode on high-resolution displays. (
>https://bugs.freedesktop.org/show_bug.cgi?id=92777
>).
>- Borderless or transparent window with SDL2. Also, did you notice
>that sdl2 window turns black/white while resizing? There is no way to get a
>continuous window resize event with SDL2 (https://bugzilla.libsdl.org/s
>how_bug.cgi?id=2077). The issue is that events stop firing while user
> 

Re: [Pharo-dev] Odd (and wrong) implementation of Float>>sign

[Martin McClure]

On 01/26/2017 12:47 PM, Nicolas Cellier wrote:
> 
> 
> 2017-01-26 21:22 GMT+01:00 Martin McClure  >:

[...]

> The current implementation of #sign is
> 
> self > 0 ifTrue: [^ 1].
> (self < 0 or: [((self at: 1) bitShift: -31) = 1]) ifTrue: [^ -1].
> ^ 0
> 
> I'd propose factoring this into two simpler methods:
> 
> sign
> self > 0 ifTrue: [^ 1].
> self < 0 ifTrue: [^ -1].
> ^ 0
> 
> 
> maybe self isNan ifTrue [^-1 raisedTo: self signBit], or the standard
> tells it should be 0 too?

This addition makes sense to me.

The standards help a *little* and suggest on alternative.

ANSI Smalltalk acts like NaNs don't exist (basically, it lets
implementers do what they want for those values).

ANSI Smalltalk relies on ISO/IEC 10967 of 1994 for numerics (even when
it *cannot* rely on 10967, it does, sigh). That spec only defines a
"sign" operation for floats with a definite numeric value, and says that
operations are *permitted* to accept infinities and NaNs, but does not
require this, nor say what the answer should be.

The 2007 update of 10967 is somewhat more helpful. It replaces the
"sign" operation with one called "signum" which returns 1, -1, or NaN.
It returns 1 for positive zero and positive infinity, and -1 for
negative zero and negative infinity. If given a qNaN, it returns a qNaN.
If given a signaling NaN, it returns a qNaN but notifies the application
of an "invalid" situation.

If we extend this to Smalltalk, I *think* this would have us answer qNaN
for qNaN, and for a sNaN signal a resumable exception (a Notification,
perhaps?) that if resumed would answer qNaN. This also seems to make
some sense -- NaNs are supposed to propagate, and asking the just plain
"sign" (as opposed to signBit or isSignMinus) of a NaN is more or less
nonsense. But if you prefer (-1 raisedTo: self signBit) I won't complain.

> 
> That means that we'd have to refactor most (all?) senders of sign...
> 

Certainly should audit senders of sign, but I'd expect that most senders
don't really care about what the sign of -0.0 or NaNs are. The answer
would remain the same for all other receivers.

Regards,

-Martin

[Pharo-dev] HandMorph>>#processEvents

[p...@highoctane.be]

Why do we have this twice in processEvents?

self mouseOverHandler processMouseOver: lastMouseEvent

?

Well, maybe that is not there that things happen but if you spy on
mouseEnter and mouseLeave events, you will notice that they are both sent
**twice** all the time.

I think that this happens so often that we would benefit from getting rid
of that twice enter/leave thing (and it is really annoying to have to deal
with these two events when you expect only one. I am not "entering
entering" a rectangle).



processEvents
"Process user input events from the local input devices."

| evt evtBuf type hadAny |
ActiveEvent ifNotNil:
["Meaning that we were invoked from within an event response.
Make sure z-order is up to date"

self mouseOverHandler processMouseOver: lastMouseEvent].
hadAny := false.
[(evtBuf := Sensor nextEvent) isNil] whileFalse:
[evt := nil. "for unknown event types"
type := evtBuf first.
type = EventTypeMouse ifTrue: [recentModifiers := evtBuf sixth. evt := self
generateMouseEvent: evtBuf].
type = EventTypeKeyboard
ifTrue: [recentModifiers := evtBuf fifth. evt := self
generateKeyboardEvent: evtBuf].
type = EventTypeDragDropFiles
ifTrue: [evt := self generateDropFilesEvent: evtBuf].
type = EventTypeWindow
ifTrue:[evt := self generateWindowEvent: evtBuf].
"All other events are ignored"
(type ~= EventTypeDragDropFiles and: [evt isNil]) ifTrue: [^self].
evt isNil
ifFalse:
["Finally, handle it"

self handleEvent: evt.
hadAny := true.

"For better user feedback, return immediately after a mouse event has been
processed."
(evt isMouse and: [evt isMouseWheel not]) ifTrue: [^self]]].
"note: if we come here we didn't have any mouse events"
mouseClickState notNil
ifTrue:
["No mouse events during this cycle. Make sure click states time out
accordingly"

mouseClickState handleEvent: lastMouseEvent asMouseMove from: self].
hadAny
ifFalse:
["No pending events. Make sure z-order is up to date"

self mouseOverHandler processMouseOver: lastMouseEvent]

Clues?

Phil

Re: [Pharo-dev] [bloc] addressing the moz2d issue

[Aliaksei Syrel]

Hi

(My previous email was not a joke, I don't try to troll anyone. Let tolls
do their job in other places)
*Let's forget Moz2D for a moment :) Imagine that it does not exist. *It was
done just for fun and is even not in pharo repo. (
https://github.com/syrel/Moz2D). We needed something that works and it was
made investing just a few months of time of a single anonymous student
during summer exams session and vacations.

I would like to start maybe one of the most important discussion that will
influence Pharo and will dictate how system will look like in a few years.
I invite everyone to join this discussion, especially board and consortium
members. Because here is where business starts.

There are some real questions:

   1. Do we need Bloc or Morphic2 or %name your favourite framework%?
   2. How advanced and modern do you want it to be?
   3. What technology stack do we want to use for our new graphical
   framework?
   4. What platforms and operating systems do we want to support?
   5. How flexible technology stack should be? (some parts may change in
   the future)
   6. Who will pay for it?
   7. How many engineers can community afford?
   8. Do you know how much other systems invest in graphical frameworks?
   9. It is not a science project, isn't it?

Let me first put my two cents in.

Low-level UI framework (without widgets) consists of multiple parts:

   1. Vector graphics library to render shapes (fill, stroke, path builder,
   composition and blending operators)
   2. Font service library (to support different font formats and collect
   information about local fonts installed in the system)
   3. Text layout engine (this is where glyph positioning magic happens,
   link above too)
   4. Text shaping engine (for high quality text rendering, to understand
   the problem => http://behdad.org/text/)
   5. Complex script library (to support ligatures, split glyphs and other
   UTF8 stuff, remember https://github.com/minimaxir/big-list-of-naughty-st
   rings)
   6. Image processing library (for various image effects, like gaussian
   blur, morphology filter, gamma, displacement map, just to name a few)
   7. Hardware acceleration. Software rendering is nice, however, modern
   UIs are full of fancy stuff that require hardware acceleration.
   8. Window and Event management library. With support of borderless and
   semi-transparent windows + good support of touchpad.
   9. Custom written "Glue" library that allows all components to work
   together. Since modern libs are implemented in C++ we would need to
   implement C wrapper and a lot of integration tests.
   10. Make the whole beast cross platform.


Did I miss something?

Here are some modern technologies commonly used for mentioned parts:

   1. Skia, Direct2D, CoreGraphics, Cairo
   2. Fontconfig, Freetype2
   3. HarfBuzz
   4. Pango, OpenType
   5. Graphite2, FriBidi
   6. Imagemagic, SVG filters libraries
   7. Vulkan, OpenGL
   8. wxWidgets, QT, GTK, SDL2
   9. todo
   10. todo

Luckily Pango covers bullets 2 - 5. It indeed sounds like a great idea!

Let's assume that we stop on Cairo + Pango. According to pango.com

The integration of Pango with Cairo (http://cairographics.org/) provides a
> complete solution with high quality text handling and graphics rendering.


According to the this potential technology stack we will have:

   - Cairo for vector graphics and rendering of basic shapes
   - Pango for text rendering
   - SDL2 for window and events management

What we will not get:

   - Support of filters; Cairo does not support gaussian blur. 3D
   transformations, we will not be able to not implement card flip animation.
   Never reach the same performance if using platform native frameworks (e.g.
   Direct2D on windows). Cairo will not die, but there is zero progress.
   - Vulkan support. Never with cairo. Pure OpenGL too (try to compile
   cairo-gl on mac, good luck!) There is a way to compile it with quartz
   support. As of version 2.7.9, *XQuartz does not provide support for
   high-resolution Retina displays to X11 apps*, which run in pixel-doubled
   mode on high-resolution displays. (https://bugs.freedesktop.org/
   show_bug.cgi?id=92777).
   - Borderless or transparent window with SDL2. Also, did you notice that
   sdl2 window turns black/white while resizing? There is no way to get a
   continuous window resize event with SDL2 (https://bugzilla.libsdl.org/s
   how_bug.cgi?id=2077). The issue is that events stop firing while user is
   resizing a window because main thread is blocked. *Bug is already 3
   years old. *Indeed SDL2 is used for games, however how often do gamers
   resize game window?
   - Stateless API. Must have for a graphical framework like Bloc where
   canvas state is not shared between visual elements. It means that while
   rendering users must not clean the state of a canvas after every draw call.

Bloc is not my or Glenn's or Doru's personal property. We suggest, you
decide. It would be great if 

Re: [Pharo-dev] memoized vs once

[Chris Cunningham]

On Thu, Jan 26, 2017 at 2:02 PM, stepharong  wrote:

> On Thu, 26 Jan 2017 20:38:49 +0100, Torsten Bergmann 
> wrote:
>
> ...
>
>
>> Instead it is sent to an object that afterwards is a constant within a
>> method
>> (so it will not be evaluated later at runtime again) so IMHO
>> #asMethodConstant
>> instead of #asMethodConst would be better.
>>
>
> I do not understand any of them.
>
> In other words, this is creating a constant inside the method
(#asMethodConstant) instead of making the method return a constant (which
would be your #asConstantMethod).
If I have that right.
In any case, not having the contracted 'Const' would be nice.

-cbc

> --
> Using Opera's mail client: http://www.opera.com/mail/
>
>

[Pharo-dev] athens dead code?

[stepharong]

accept: aVisitor
^ aVisitor lineSegment: self
accept: aVisitor
^ aVisitor closeSegment: self
accept: aVisitor
^ aVisitor moveSegment: self

seems to invoke methods that do not exit
I check AthensLIneSegment is used so I do not understand why the methods  
are broken.



--
Using Opera's mail client: http://www.opera.com/mail/

Re: [Pharo-dev] memoized vs once

[stepharong]

On Thu, 26 Jan 2017 20:38:49 +0100, Torsten Bergmann   
wrote:



stepharong wrote:

can we rename this selector?
asMethodConst should be at least be renamed to asConstantMethod


When you use "as {something}" then "something" depicts the result of the
conversion message sent to an object.

Like in #asNumber or #asString which shows to what the receiver will be  
converted.


Yes I thought that it was doing that.



My understanding is that in the case discussed the receiver object is
NOT converted to a constant unchangeable method, so #asConstantMethod  
would

not fit as a selector.

Instead it is sent to an object that afterwards is a constant within a  
method
(so it will not be evaluated later at runtime again) so IMHO  
#asMethodConstant

instead of #asMethodConst would be better.


I do not understand any of them.



Finding good names is really hardest part in programming...

Thanks
T.




--
Using Opera's mail client: http://www.opera.com/mail/

Re: [Pharo-dev] [bloc] addressing the moz2d issue

[stepharong]

My last mail on that topic

Esteban told me that we should recompile the cairo lib with acceleration  
enabled.


Now probably Mozz2d is the coolest techno right now.
We read about Azure when Igor started to build athens. Athens was designed  
to make sure that

when Cairo dies we do not have to rewritte everything.

Stef



On Thu, 26 Jan 2017 22:55:25 +0100, p...@highoctane.be  
 wrote:



Moz2D looks pretty great and the stateless argument makes sense.

Furthermore there is an isolation layer.
Interesting reads:
https://blog.mozilla.org/joe/2011/04/26/introducing-the-azure-project/

http://robert.ocallahan.org/2011/09/graphics-api-design.html

https://wiki.mozilla.org/Platform/GFX/Moz2D

https://dxr.mozilla.org/mozilla-central/source/gfx/2d/2D.h

Having browser grade speed views in a OSWindow is enabling.

Cairo is not going to give us super speedy UIs, sorry, just check the  
demos we have in the image, they are sluggish.


Phil



On Thu, Jan 26, 2017 at 10:27 PM, stepharong  wrote:




Hi,

Then we will need Cairo + SDL2 (that does not work for us)


I do not get why SDL20 would not work for us while it is used by gaming  
engines. Are we that special?
We built interactive applications for Thales with complex event touch  
and now suddenly "it does not work for us" TM.
I have the impression that each time I see Bloc we need something more  
special (now this is Gtk)
To me it looks like it is a systematic "fuite en avant" with even more  
Mb consumption each time.
Personally I do not care of blur and effects, or color max filters.  
Right now you do not even have a single example of something that is  
not a littledemo.


Why we cannot have a tk/tcl or red-language like working system? I mean  
working now and not relyingon multiple MB of code extracted from an  
existing project?


+ Freetype2 (for fonts) + Graphite (glyphs shaping technology in order  
to use them within vector graphics engine) + cross platform OpenGL /  
Vulkan context/device provider for hardware >>>acceleration +  
implement Filters for effects (blur, lights, color matrix filters,  
etc...).


Without all those technologies bloc WILL progress, from 80's to 00's.  
Still decades behind :)


Well I would prefer to have something from the 00 working now that from  
2016 not working.
Because now what I will do is continuing to work on Morphic because  
this is what I have.You see I removed graphics from my future books.  
You probably do not care.In the future I will concentrate on anything  
else than graphics and widgets like that I will have no frustration.
Hacking the compiler finally should be a lot nicer.You see next week I  
go to visit alain and I will not discuss nor work on such topics like  
that no frustration.
Finally I will not comment anymore on Bloc anymore. I should not have. 
You do not seem to understand my point so I will shut up but years will  
pass before Bloc will be integrated in Pharo, becauseintegrated means  
maintained by us in case the guys behind bloc/brick get hired by  
anybody else on earth.


You seem to underestimate that part.
Ok you are super right and I'm super wrong.
Stef









--
Using Opera's mail client: http://www.opera.com/mail/

Re: [Pharo-dev] [bloc] addressing the moz2d issue

[stepharong]

On Thu, 26 Jan 2017 22:36:47 +0100, Tudor Girba   
wrote:



Hi Stef,

There was a misunderstanding. Alex was just listing the need of  
underlying technologies for the features that Bloc already supports.


Let’s restart this conversation. He will send an explanatory email.


I understood it correctly.
I just took a maintenance cost evaluation position and to me this is not  
sustainable.


Stef

Re: [Pharo-dev] Odd (and wrong) implementation of Float>>sign

[werner kassens]

Hi,
i wonder what is the reasoning that "Float nan sign" returns anything 
else than Float nan?

werner

On 01/26/2017 09:47 PM, Nicolas Cellier wrote:



2017-01-26 21:22 GMT+01:00 Martin McClure >:


Pharo's implementation of Float>>sign is very odd, and rather
disturbing.

It answers 1 for positive, -1 for negative, and 0 for zero. Except for
negative zero, for which it answers -1. This is asymmetric -- positive
zero gets 0 but negative 0 gets -1? This does not seem correct.

Both the ANSI Smalltalk spec and the ISO/IEC 10967 portable numerics
spec say that "sign" should just answer 0 for zero -- positive or
negative. I don't always agree with the spec, but in this case I do.

OK, I think you are right

The IEEE 754 floating-point spec doesn't have a "sign" operation,
but it
does have an operation called "isSignMinus" which can be used to
distinguish negative from positive zero (and negative from
positive NaN).

The current implementation of #sign is

self > 0 ifTrue: [^ 1].
(self < 0 or: [((self at: 1) bitShift: -31) = 1]) ifTrue: [^ -1].
^ 0

I'd propose factoring this into two simpler methods:

sign
self > 0 ifTrue: [^ 1].
self < 0 ifTrue: [^ -1].
^ 0


maybe self isNan ifTrue [^-1 raisedTo: self signBit], or the standard 
tells it should be 0 too?



isSignMinus
^((self at: 1) bitShift: -31) = 1

Which would restore symmetry, as well as conforming to all the
relevant
specs.

-Martin


Or just

signBit
^(self at: 1) bitShift: -31)

That means that we'd have to refactor most (all?) senders of sign...

Re: [Pharo-dev] [bloc] addressing the moz2d issue

[p...@highoctane.be]

Moz2D looks pretty great and the stateless argument makes sense.

Furthermore there is an isolation layer.

Interesting reads:

https://blog.mozilla.org/joe/2011/04/26/introducing-the-azure-project/

http://robert.ocallahan.org/2011/09/graphics-api-design.html

https://wiki.mozilla.org/Platform/GFX/Moz2D

https://dxr.mozilla.org/mozilla-central/source/gfx/2d/2D.h

Having browser grade speed views in a OSWindow is enabling.

Cairo is not going to give us super speedy UIs, sorry, just check the demos
we have in the image, they are sluggish.

Phil



On Thu, Jan 26, 2017 at 10:27 PM, stepharong  wrote:

>
>
> Hi,
>
> Then we will need Cairo + SDL2 (that does not work for us)
>
>
> I do not get why SDL20 would not work for us while it is used by gaming
> engines. Are we that special?
> We built interactive applications for Thales with complex event touch and
> now suddenly "it does not work for us" TM.
> I have the impression that each time I see Bloc we need something more
> special (now this is Gtk)
> To me it looks like it is a systematic "fuite en avant" with even more Mb
> consumption each time.
>
> Personally I do not care of blur and effects, or color max filters. Right
> now you do not even have a single example of something that is not a little
> demo.
>
> Why we cannot have a tk/tcl or red-language like working system? I mean
> working now and not relying
> on multiple MB of code extracted from an existing project?
>
> + Freetype2 (for fonts) + Graphite (glyphs shaping technology in order to
> use them within vector graphics engine) + cross platform OpenGL / Vulkan
> context/device provider for hardware acceleration + implement Filters for
> effects (blur, lights, color matrix filters, etc...).
>
> Without all those technologies bloc WILL progress, from 80's to 00's.
> Still decades behind :)
>
>
> Well I would prefer to have something from the 00 working now that from
> 2016 not working.
>
> Because now what I will do is continuing to work on Morphic because this
> is what I have.
> You see I removed graphics from my future books. You probably do not care.
> In the future I will concentrate on anything else than graphics and
> widgets like that I will have no frustration.
> Hacking the compiler finally should be a lot nicer.
> You see next week I go to visit alain and I will not discuss nor work on
> such topics like that no frustration.
>
> Finally I will not comment anymore on Bloc anymore. I should not have.
> You do not seem to understand my point so I will shut up but years will
> pass before Bloc will be integrated in Pharo, because
> integrated means maintained by us in case the guys behind bloc/brick get
> hired by anybody else on earth.
>
>
> You seem to underestimate that part.
> Ok you are super right and I'm super wrong.
>
> Stef
>
>
>
>

Re: [Pharo-dev] Immutability support

[p...@highoctane.be]

Guess the method is wrong given the comment.

Shouldn't it be [param anyMask: 1] instead of [param anyMask: 2] ?

Phil

On Wed, Jan 25, 2017 at 2:14 PM, Clément Bera 
wrote:

> I introduced the method #supportsWriteBarrier in Pharo 6.
>
> You can backport it if you want:
>
> VirtualMachine>>#supportsWriteBarrier
> "Answer whether the VM observes the per-object read-only flag and
> consequently
> aborts writes to inst vars of, and fails primitives that attempt to write,
> to read-only objects."
>
> ^(self parameterAt: 65)
> ifNil: [false]
> ifNotNil:
> [:param| "In older VMs this is a boolean reflecting MULTIPLE_BYTECODE_SETS"
> param isInteger "In newer VMs it is a set of integer flags, bit 1 of which
> is IMMUTABILITY"
> ifTrue: [param anyMask: 2]
> ifFalse: [false]]
>
>
>
> On Wed, Jan 25, 2017 at 2:06 PM, p...@highoctane.be 
> wrote:
>
>> The "latest" Windows VM I do use has no such method.
>>
>> Virtual Machine
>> ---
>> C:\Users\Philippe\Dropbox\Sibelga\JiraAutomation\Pharo5.0\
>> latestvm\pharo.exe
>> CoInterpreter * VMMaker.oscog-eem.2090 uuid:
>> 63a161b9-17e1-4911-a89a-1687d9ba9a1a Jan 15 2017
>> StackToRegisterMappingCogit * VMMaker.oscog-eem.2090 uuid:
>> 63a161b9-17e1-4911-a89a-1687d9ba9a1a Jan 15 2017
>> VM: 201701151442 https://github.com/pharo-project/pharo-vm.git $ Date:
>> Sun Jan 15 15:42:39 2017 +0100 $ Plugins: 201701151442
>> https://github.com/pharo-project/pharo-vm.git $
>>
>> Win32 built on Jan 15 2017 15:59:52 CUT Compiler: 5.4.0
>> VMMaker versionString VM: 201701151442 https://github.com/pharo-proje
>> ct/pharo-vm.git $ Date: Sun Jan 15 15:42:39 2017 +0100 $ Plugins:
>> 201701151442 https://github.com/pharo-project/pharo-vm.git $
>> CoInterpreter * VMMaker.oscog-eem.2090 uuid:
>> 63a161b9-17e1-4911-a89a-1687d9ba9a1a Jan 15 2017
>> StackToRegisterMappingCogit * VMMaker.oscog-eem.2090 uuid:
>> 63a161b9-17e1-4911-a89a-1687d9ba9a1a Jan 15 2017
>>
>> [image: Inline image 1]
>>
>>
>> On Wed, Jan 25, 2017 at 1:54 PM, Clément Bera 
>> wrote:
>>
>>>
>>>
>>> On Wed, Jan 25, 2017 at 11:35 AM, Norbert Hartl 
>>> wrote:
>>>
 Does anyone know the state of immutability support in vm and image? The
 latest vm downloadable is compiled with

 IMMUTABILITY=1

 (Esteban said that). When I open a pharo6 image with this VM and do:

 ASUser new
 setIsReadOnlyObject: true;
 name: 'foo'

 with

 ASUser>>#name: arg1
 name := arg1

 I don't get an exception. Is there something missing or am I not
 understanding?

>>>
>>> Hi Norbert,
>>>
>>> Thank you very much for looking read-only objects.
>>>
>>> When mutating an instance variable, the VM triggers a call-back that by
>>> default does nothing. In your case, running your code does not raise an
>>> exception but the object should not be modified either. If you want an
>>> exception, you need to change the call-back code, i.e., the method
>>> Object>>#attemptToAssign: value withIndex: index. For example, you could
>>> write:
>>>
>>> Object>>#attemptToAssign: value withIndex: index
>>> | process |
>>> self notify: 'object changed !'.
>>> process := Processor activeProcess.
>>> [ process suspendedContext: process suspendedContext sender ] forkAt:
>>> Processor activePriority + 1.
>>> Processor yield.
>>>
>>> Then, your code should open a notification window with 'object changed',
>>> and proceeding keeps running the code without mutating the object.
>>>
>>> One needs to build a ModificationTracker framework on top of the VM
>>> support I introduced. Multiple things are required, like default behavior
>>> in this call-back and in primitive failure code. I am willing to support
>>> and help anyone willing to build such a framework, but I won't build it
>>> myself.
>>>
>>> If you have any other questions or if you find bug don't hesitate to ask
>>> further questions
>>>
>>> Best,
>>>
>>> PS: Make sure "Smalltalk vm supportsWriteBarrier" answers true in your
>>> system, if this is not the case it means the VM does not support read-only
>>> objects.
>>>
>>> Clement
>>>
>>>
>>>
>>>
>>>
>>>

 Norbert

>>>
>>>
>>
>

Re: [Pharo-dev] [bloc] addressing the moz2d issue

[Tudor Girba]

Hi Stef,

There was a misunderstanding. Alex was just listing the need of underlying 
technologies for the features that Bloc already supports.

Let’s restart this conversation. He will send an explanatory email.

Cheers,
Doru

> On Jan 26, 2017, at 10:27 PM, stepharong  wrote:
> 
> 
> 
> Hi,
> 
> Then we will need Cairo + SDL2 (that does not work for us) 
> 
> I do not get why SDL20 would not work for us while it is used by gaming 
> engines. Are we that special?
> We built interactive applications for Thales with complex event touch and now 
> suddenly "it does not work for us" TM.
> I have the impression that each time I see Bloc we need something more 
> special (now this is Gtk)
> To me it looks like it is a systematic "fuite en avant" with even more Mb 
> consumption each time. 
> 
> Personally I do not care of blur and effects, or color max filters. Right now 
> you do not even have a single example of something that is not a little 
> demo.
> 
> Why we cannot have a tk/tcl or red-language like working system? I mean 
> working now and not relying 
> on multiple MB of code extracted from an existing project?
> 
> + Freetype2 (for fonts) + Graphite (glyphs shaping technology in order to use 
> them within vector graphics engine) + cross platform OpenGL / Vulkan 
> context/device provider for hardware acceleration + implement Filters for 
> effects (blur, lights, color matrix filters, etc...).
> 
> Without all those technologies bloc WILL progress, from 80's to 00's. Still 
> decades behind :)
> 
> Well I would prefer to have something from the 00 working now that from 2016 
> not working. 
> 
> Because now what I will do is continuing to work on Morphic because this is 
> what I have. 
> You see I removed graphics from my future books. You probably do not care. 
> In the future I will concentrate on anything else than graphics and widgets 
> like that I will have no frustration.
> Hacking the compiler finally should be a lot nicer. 
> You see next week I go to visit alain and I will not discuss nor work on such 
> topics like that no frustration. 
> 
> Finally I will not comment anymore on Bloc anymore. I should not have. 
> You do not seem to understand my point so I will shut up but years will pass 
> before Bloc will be integrated in Pharo, because 
> integrated means maintained by us in case the guys behind bloc/brick get 
> hired by anybody else on earth. 
> 
> 
> You seem to underestimate that part.
> Ok you are super right and I'm super wrong. 
> 
> Stef

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

"Be rather willing to give than demanding to get."

Re: [Pharo-dev] [Ann] Calypso update: method browser and better UI

[Denis Kudriashov]

2017-01-26 21:09 GMT+01:00 Bernhard Pieber :

> > - no Spec text model anymore. Rubric widgets are used directly. It
> improves speed of building text editors
> This is really great. I love the Method Browser.


I also forgot to show in demo that it is possible to drag window tab to get
normal separate window (just drag it to free space in World).
I hope it will be enough because to my mind tabs are most suitable approach
but when you really need separate window you will just drag tab out.

Re: [Pharo-dev] [bloc] addressing the moz2d issue

[stepharong]

Hi,

Then we will need Cairo + SDL2 (that does not work for us)


I do not get why SDL20 would not work for us while it is used by gaming  
engines. Are we that special?
We built interactive applications for Thales with complex event touch and  
now suddenly "it does not work for us" TM.
I have the impression that each time I see Bloc we need something more  
special (now this is Gtk)
To me it looks like it is a systematic "fuite en avant" with even more Mb  
consumption each time.


Personally I do not care of blur and effects, or color max filters. Right  
now you do not even have a single example of something that is not a little

demo.

Why we cannot have a tk/tcl or red-language like working system? I mean  
working now and not relying

on multiple MB of code extracted from an existing project?

+ Freetype2 (for fonts) + Graphite (glyphs shaping technology in order  
to use them within vector graphics engine) + cross platform OpenGL /  
Vulkan context/device provider for hardware >acceleration + implement  
Filters for effects (blur, lights, color matrix filters, etc...).


Without all those technologies bloc WILL progress, from 80's to 00's.  
Still decades behind :)


Well I would prefer to have something from the 00 working now that from  
2016 not working.


Because now what I will do is continuing to work on Morphic because this  
is what I have.

You see I removed graphics from my future books. You probably do not care.
In the future I will concentrate on anything else than graphics and  
widgets like that I will have no frustration.

Hacking the compiler finally should be a lot nicer.
You see next week I go to visit alain and I will not discuss nor work on  
such topics like that no frustration.


Finally I will not comment anymore on Bloc anymore. I should not have.
You do not seem to understand my point so I will shut up but years will  
pass before Bloc will be integrated in Pharo, because
integrated means maintained by us in case the guys behind bloc/brick get  
hired by anybody else on earth.



You seem to underestimate that part.
Ok you are super right and I'm super wrong.

Stef

Re: [Pharo-dev] [bloc] addressing the moz2d issue

[Tudor Girba]

Hi Stef,

As explained before Brick is where the main focus will be next. I think that 
once the editor will be working, we should see more visible movement in that 
department.

Cheers,
Doru


> On Jan 26, 2017, at 8:39 PM, stepharong  wrote:
> 
> I think that instead of investigating gtk (yet another library to bind and 
> carry around),
> it would be smarter to have Sparta back-end using an accelerated Cairo + 
> pango.
> Why? Because
>   - For example Cairo will not disappear in the future (here you will 
> tell me that it does not have all the full
>   features I think that Bloc should deliver Brick first and focus on 
> this because else it will stay a nice
>   experiment.)
>   - We do not have bench with an accelerated compiled version so no idea 
> if this is good enough.
>   - Cairo is about 1.5 mb vs 20Mb and it is packaged.
> 
> I share the concerns of Esteban about the maintenance of such Mozz2d bundling 
> and he was pretty
> clear with me, he will not maintain it nor take any responsibility about 
> pharo using it.
> 
>   So having a Cairo Sparta back-end would be a smart move.
> Stef
> 
> 
> 
> 
> 
>> Hi,
>> 
>> Thank you for the intensive set of issues you raised during the Bloc 
>> presentation. I think it is worthwhile addressing them more thoroughly, so 
>> let me start with the issue that seemed to have caused the most worries: 
>> Sparta & Moz2D.
>> 
>> Please keep in mind that while I am involved to some extent in Bloc, the 
>> real credits for the current state go to Glenn and Alex.
>> 
>> Moz2D (https://github.com/mozilla/moz2d, 
>> https://wiki.mozilla.org/Platform/GFX/Moz2D) offers an advanced backend and 
>> using it puts us on par with the rendering speed of a web browser, which is 
>> a significant added value over what we have now.
>> 
>> However, as it was noted, it does come with a cost due to the fact that it 
>> is not available as standalone with only the features we are interested in. 
>> The vector graphics part is actually buildable out of the box. However, the 
>> text support needs to be extracted out of Moz2D, and this is where the 
>> patching scripts are used. The patches are there only for compilation 
>> purposes and not for features and they are applied automatically. You can 
>> see it here:
>> https://github.com/syrel/Moz2D
>> 
>> Alex updated recently the Moz2D version and it worked without problems. Of 
>> course, future changes in Moz2D might imply changes in this script as well, 
>> and this implies that we will need to maintain that script. And we could 
>> imagine applying these patches on the trunk of Moz2D to see if they work, 
>> and we can also imagine engaging with the Moz2D owners to see if we can find 
>> a middle ground.
>> 
>> Now, let’s put this into perspective. We are currently using Athens and the 
>> Cairo backend. While Cairo is provided as a standalone library it has not 
>> seen significant advances since Mozzila shifted its focus towards Moz2D. So, 
>> sticking with it might not be an ideal strategy either.
>> 
>> Furthermore, just like Athens, Sparta is an abstraction that allows us to 
>> switch the underlying backend should we need to. Until now we did not find a 
>> cross-platform backend that is as advanced and complete as Moz2D, but there 
>> is no reason to think that none other will appear in the future. Skia is an 
>> alternative but it is only a vector graphic engine without text support, so 
>> using it would imply to have another library for the text support.
>> 
>> Sparta also comes with a reasonable set of tests that is aimed at testing 
>> the basic Moz2D functionality to make sure that the assumptions on top of 
>> which Sparta is built are correct.
>> 
>> All in all, I think that the current situation is not ideal, but there is 
>> already enough engineering in place to actually make it work. And I 
>> definitely think that the potential it opens is rather significant.
>> 
>> And, if more people look at the scripts, we might find even better and 
>> cheaper ways to express it.
>> 
>> Cheers,
>> Doru
>> 
>> 
>> --
>> www.tudorgirba.com
>> www.feenk.com
>> 
>> "We cannot reach the flow of things unless we let go."
>> 
>> 
>> 
>> 
>> 
> 
> 
> -- 
> Using Opera's mail client: http://www.opera.com/mail/

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

"Every now and then stop and ask yourself if the war you're fighting is the 
right one."

Re: [Pharo-dev] [bloc] addressing the moz2d issue

[Tudor Girba]

Hi,

The mail from Alex is a bit cryptic. Alex, please send a more elaborate answer 
:).

Cheers,
Doru


> On Jan 26, 2017, at 9:10 PM, Aliaksei Syrel  wrote:
> 
> Hi,
> 
> Then we will need Cairo + SDL2 (that does not work for us) + Freetype2 (for 
> fonts) + Graphite (glyphs shaping technology in order to use them within 
> vector graphics engine) + cross platform OpenGL / Vulkan context/device 
> provider for hardware acceleration + implement Filters for effects (blur, 
> lights, color matrix filters, etc...).
> 
> Without all those technologies bloc WILL progress, from 80's to 00's. Still 
> decades behind :)
> 
> Cheers
> 
> On Jan 26, 2017 20:40, "stepharong"  wrote:
> I think that instead of investigating gtk (yet another library to bind and 
> carry around),
> it would be smarter to have Sparta back-end using an accelerated Cairo + 
> pango.
> Why? Because
> - For example Cairo will not disappear in the future (here you will 
> tell me that it does not have all the full
> features I think that Bloc should deliver Brick first and focus 
> on this because else it will stay a nice
> experiment.)
> - We do not have bench with an accelerated compiled version so no 
> idea if this is good enough.
> - Cairo is about 1.5 mb vs 20Mb and it is packaged.
> 
> I share the concerns of Esteban about the maintenance of such Mozz2d bundling 
> and he was pretty
> clear with me, he will not maintain it nor take any responsibility about 
> pharo using it.
> 
> So having a Cairo Sparta back-end would be a smart move.
> Stef
> 
> 
> 
> 
> 
> Hi,
> 
> Thank you for the intensive set of issues you raised during the Bloc 
> presentation. I think it is worthwhile addressing them more thoroughly, so 
> let me start with the issue that seemed to have caused the most worries: 
> Sparta & Moz2D.
> 
> Please keep in mind that while I am involved to some extent in Bloc, the real 
> credits for the current state go to Glenn and Alex.
> 
> Moz2D (https://github.com/mozilla/moz2d, 
> https://wiki.mozilla.org/Platform/GFX/Moz2D) offers an advanced backend and 
> using it puts us on par with the rendering speed of a web browser, which is a 
> significant added value over what we have now.
> 
> However, as it was noted, it does come with a cost due to the fact that it is 
> not available as standalone with only the features we are interested in. The 
> vector graphics part is actually buildable out of the box. However, the text 
> support needs to be extracted out of Moz2D, and this is where the patching 
> scripts are used. The patches are there only for compilation purposes and not 
> for features and they are applied automatically. You can see it here:
> https://github.com/syrel/Moz2D
> 
> Alex updated recently the Moz2D version and it worked without problems. Of 
> course, future changes in Moz2D might imply changes in this script as well, 
> and this implies that we will need to maintain that script. And we could 
> imagine applying these patches on the trunk of Moz2D to see if they work, and 
> we can also imagine engaging with the Moz2D owners to see if we can find a 
> middle ground.
> 
> Now, let’s put this into perspective. We are currently using Athens and the 
> Cairo backend. While Cairo is provided as a standalone library it has not 
> seen significant advances since Mozzila shifted its focus towards Moz2D. So, 
> sticking with it might not be an ideal strategy either.
> 
> Furthermore, just like Athens, Sparta is an abstraction that allows us to 
> switch the underlying backend should we need to. Until now we did not find a 
> cross-platform backend that is as advanced and complete as Moz2D, but there 
> is no reason to think that none other will appear in the future. Skia is an 
> alternative but it is only a vector graphic engine without text support, so 
> using it would imply to have another library for the text support.
> 
> Sparta also comes with a reasonable set of tests that is aimed at testing the 
> basic Moz2D functionality to make sure that the assumptions on top of which 
> Sparta is built are correct.
> 
> All in all, I think that the current situation is not ideal, but there is 
> already enough engineering in place to actually make it work. And I 
> definitely think that the potential it opens is rather significant.
> 
> And, if more people look at the scripts, we might find even better and 
> cheaper ways to express it.
> 
> Cheers,
> Doru
> 
> 
> --
> www.tudorgirba.com
> www.feenk.com
> 
> "We cannot reach the flow of things unless we let go."
> 
> 
> 
> 
> 
> 
> 
> -- 
> Using Opera's mail client: http://www.opera.com/mail/
> 

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

"Every thing has its own flow."

Re: [Pharo-dev] Odd (and wrong) implementation of Float>>sign

[Nicolas Cellier]

2017-01-26 21:22 GMT+01:00 Martin McClure :

> Pharo's implementation of Float>>sign is very odd, and rather disturbing.
>
> It answers 1 for positive, -1 for negative, and 0 for zero. Except for
> negative zero, for which it answers -1. This is asymmetric -- positive
> zero gets 0 but negative 0 gets -1? This does not seem correct.
>
> Both the ANSI Smalltalk spec and the ISO/IEC 10967 portable numerics
> spec say that "sign" should just answer 0 for zero -- positive or
> negative. I don't always agree with the spec, but in this case I do.
>

OK, I think you are right


> The IEEE 754 floating-point spec doesn't have a "sign" operation, but it
> does have an operation called "isSignMinus" which can be used to
> distinguish negative from positive zero (and negative from positive NaN).
>
> The current implementation of #sign is
>
> self > 0 ifTrue: [^ 1].
> (self < 0 or: [((self at: 1) bitShift: -31) = 1]) ifTrue: [^ -1].
> ^ 0
>
> I'd propose factoring this into two simpler methods:
>
> sign
> self > 0 ifTrue: [^ 1].
> self < 0 ifTrue: [^ -1].
> ^ 0
>
>
maybe self isNan ifTrue [^-1 raisedTo: self signBit], or the standard tells
it should be 0 too?



> isSignMinus
> ^((self at: 1) bitShift: -31) = 1
>
> Which would restore symmetry, as well as conforming to all the relevant
> specs.
>
> -Martin
>
>
> Or just

signBit
^(self at: 1) bitShift: -31)

That means that we'd have to refactor most (all?) senders of sign...

Re: [Pharo-dev] memoized vs once

[Eliot Miranda]

Hi Torsten,

On Wed, Jan 25, 2017 at 2:45 PM, Torsten Bergmann  wrote:

> Hi,
>
> From my perspective:
>
> - I agree with Igor that "once" can be interpreted as "evaluate it only
> once" as in
>   "Halt once".
>
> - I'm not sure but from the (now very distributed) discussion it is not
> clear to me if
>   the #once mentioned by Eliot really has exactly the same behavior as
> #memoized in Pharo.
>

Let's separate the implementation from the semantics.  Memorizing a
function implies cacheing its results for some set of arguments and
answering the results, avoiding evaluating the function again.  This is the
effectively same semantics as [expr] once, which says that expire will be
evaluated exactly once.  So they're both forms of memorization.  I
recognized this but was too stupid/tired to realize they weren't the same,
since once applies to nullify blocks and memorize applies to Nary blocks.
That started this whole discussion, apologies.

Now, descending to the implementations, I understand that Ben's memorize
answers a block that wraps a dictionary which caches the arguments ->
results mappings.  #once is implemented to use become to convert the block
(which in VW must be a clean block) into a cacheingBlockClosure which has
an extra inst var to hold its values.  We can make this work in Squeak and
Pharo because we now have a prototype for clean blocks.  So, quite
different implementations, but very similar semantics

That brings me to mention that in VW there's another, rather elegant, use
for the once style block tricks, and that is to speed up step into in the
debugger.  Currently the implementation of step into is to simulate
election (that's Smalltalk executing the InstructionStream byte code
execution code, byte code by byte code) until control either returns or
enters a block in the current method.  That's slooow.  The alternative
is for the debugger to find all the blocks in the method and change their
classes to a subclass of BlockClosure that raises an exception on value,
and then use the step over code to get the VM to execute the code (via
perform:) until either control returns or the exception is raised.  The
debugger then changes all the classes back and sets the focus to the
current method.  This is fast.  Of course things get hairy when one
considers debugging the debugger, but its all about the particular debugger
only halting execution if it sees the exception is raised by the current
set of blocks it has changed the classes of, and uses #pass to ignore any
others created by other debuggers.


>   Does it also  return a block that is caching the results and avoids a
> second evalution
>   of the original block when having similar inputs? Also is there a
> similar possibility
>   to give an own cache as in #memoizedUsing: for further tuning?
>
> - #memoizing is really not well explaining what it does but this seems to
> be the official
>   term (also in other languages like Python, Java, JS, ...):
> https://en.wikipedia.org/wiki/Memoization
>
> - maybe #withMemo(r)izingResults or #withCachingResults, #withReusedResults,
> ... or something along that line
>   would be more intention revealing selectors
>
>
> Side note:
> =
> - For license reason it would not make much sense to look into non-open
> Smalltalks
> - I have no idea about the VW version (and for obvious reasons dont want
> to have a look)
> - also dont know about other dialects if they have built in support for
> memoization but it would be
>   good if Squeak, Pharo, Cuis, ... could align for such a case
> - IMHO if #once and Pharos #memoization really have the same behavior then
> compatibility for VW users
>   could be easily retained by adding #once to existing compatibility
> layers (like "Grease")
>
> Bye
> T.
>
> Gesendet: Mittwoch, 25. Januar 2017 um 22:30 Uhr
> Von: "Igor Stasenko" 
> An: "Pharo Development List" 
> Betreff: Re: [Pharo-dev] memoized vs once
>
> #once can be interpreted as 'evaluate it once',
>
> but i don't like the #memoized .. it sounds painful to my ears.
> It sounds like something stinking smeared across my face.. and i always
> got stuck,confused and lost as the meaning of it always
> escaping my mind, since it naturally defends itself from any unpleasant
> thoughts.
>
> IMHO, maybe #once is not the best wording for what it does , but
> #memoizing... yuck.. pardon me.
>
>
>  :)
>
>  --
> Best regards,
> Igor Stasenko.
>
>


-- 
_,,,^..^,,,_
best, Eliot

[Pharo-dev] Odd (and wrong) implementation of Float>>sign

[Martin McClure]

Pharo's implementation of Float>>sign is very odd, and rather disturbing.

It answers 1 for positive, -1 for negative, and 0 for zero. Except for
negative zero, for which it answers -1. This is asymmetric -- positive
zero gets 0 but negative 0 gets -1? This does not seem correct.

Both the ANSI Smalltalk spec and the ISO/IEC 10967 portable numerics
spec say that "sign" should just answer 0 for zero -- positive or
negative. I don't always agree with the spec, but in this case I do.

The IEEE 754 floating-point spec doesn't have a "sign" operation, but it
does have an operation called "isSignMinus" which can be used to
distinguish negative from positive zero (and negative from positive NaN).

The current implementation of #sign is

self > 0 ifTrue: [^ 1].
(self < 0 or: [((self at: 1) bitShift: -31) = 1]) ifTrue: [^ -1].
^ 0

I'd propose factoring this into two simpler methods:

sign
self > 0 ifTrue: [^ 1].
self < 0 ifTrue: [^ -1].
^ 0

isSignMinus
^((self at: 1) bitShift: -31) = 1

Which would restore symmetry, as well as conforming to all the relevant
specs.

-Martin

Re: [Pharo-dev] [bloc] addressing the moz2d issue

[Aliaksei Syrel]

Hi,

Then we will need Cairo + SDL2 (that does not work for us) + Freetype2 (for
fonts) + Graphite (glyphs shaping technology in order to use them within
vector graphics engine) + cross platform OpenGL / Vulkan context/device
provider for hardware acceleration + implement Filters for effects (blur,
lights, color matrix filters, etc...).

Without all those technologies bloc WILL progress, from 80's to 00's. Still
decades behind :)

Cheers

On Jan 26, 2017 20:40, "stepharong"  wrote:

> I think that instead of investigating gtk (yet another library to bind and
> carry around),
> it would be smarter to have Sparta back-end using an accelerated Cairo +
> pango.
> Why? Because
> - For example Cairo will not disappear in the future (here you
> will tell me that it does not have all the full
> features I think that Bloc should deliver Brick first and
> focus on this because else it will stay a nice
> experiment.)
> - We do not have bench with an accelerated compiled version so no
> idea if this is good enough.
> - Cairo is about 1.5 mb vs 20Mb and it is packaged.
>
> I share the concerns of Esteban about the maintenance of such Mozz2d
> bundling and he was pretty
> clear with me, he will not maintain it nor take any responsibility about
> pharo using it.
>
> So having a Cairo Sparta back-end would be a smart move.
> Stef
>
>
>
>
>
> Hi,
>>
>> Thank you for the intensive set of issues you raised during the Bloc
>> presentation. I think it is worthwhile addressing them more thoroughly, so
>> let me start with the issue that seemed to have caused the most worries:
>> Sparta & Moz2D.
>>
>> Please keep in mind that while I am involved to some extent in Bloc, the
>> real credits for the current state go to Glenn and Alex.
>>
>> Moz2D (https://github.com/mozilla/moz2d, https://wiki.mozilla.org/Platf
>> orm/GFX/Moz2D) offers an advanced backend and using it puts us on par
>> with the rendering speed of a web browser, which is a significant added
>> value over what we have now.
>>
>> However, as it was noted, it does come with a cost due to the fact that
>> it is not available as standalone with only the features we are interested
>> in. The vector graphics part is actually buildable out of the box. However,
>> the text support needs to be extracted out of Moz2D, and this is where the
>> patching scripts are used. The patches are there only for compilation
>> purposes and not for features and they are applied automatically. You can
>> see it here:
>> https://github.com/syrel/Moz2D
>>
>> Alex updated recently the Moz2D version and it worked without problems.
>> Of course, future changes in Moz2D might imply changes in this script as
>> well, and this implies that we will need to maintain that script. And we
>> could imagine applying these patches on the trunk of Moz2D to see if they
>> work, and we can also imagine engaging with the Moz2D owners to see if we
>> can find a middle ground.
>>
>> Now, let’s put this into perspective. We are currently using Athens and
>> the Cairo backend. While Cairo is provided as a standalone library it has
>> not seen significant advances since Mozzila shifted its focus towards
>> Moz2D. So, sticking with it might not be an ideal strategy either.
>>
>> Furthermore, just like Athens, Sparta is an abstraction that allows us to
>> switch the underlying backend should we need to. Until now we did not find
>> a cross-platform backend that is as advanced and complete as Moz2D, but
>> there is no reason to think that none other will appear in the future. Skia
>> is an alternative but it is only a vector graphic engine without text
>> support, so using it would imply to have another library for the text
>> support.
>>
>> Sparta also comes with a reasonable set of tests that is aimed at testing
>> the basic Moz2D functionality to make sure that the assumptions on top of
>> which Sparta is built are correct.
>>
>> All in all, I think that the current situation is not ideal, but there is
>> already enough engineering in place to actually make it work. And I
>> definitely think that the potential it opens is rather significant.
>>
>> And, if more people look at the scripts, we might find even better and
>> cheaper ways to express it.
>>
>> Cheers,
>> Doru
>>
>>
>> --
>> www.tudorgirba.com
>> www.feenk.com
>>
>> "We cannot reach the flow of things unless we let go."
>>
>>
>>
>>
>>
>>
>
> --
> Using Opera's mail client: http://www.opera.com/mail/
>
>

Re: [Pharo-dev] [Ann] Calypso update: method browser and better UI

[Bernhard Pieber]

Am 20.01.2017 um 14:12 schrieb Denis Kudriashov :
> 
> And this is done. I just upload new stable version:
> - source code shortcuts are managed by Calypso. I found simple hook how to 
> achieve this
> - senders/implementors by source code shortcuts in method browser are now 
> opened in new tabs instead of separate window.
> - no Spec text model anymore. Rubric widgets are used directly. It improves 
> speed of building text editors
This is really great. I love the Method Browser.

Thank you!

Bernhard

Re: [Pharo-dev] [Ann] PharmIDE: Pharo remote IDE to develop farm of Pharo images remotely

[stepharong]

Denis

Since I'm basically the head of the team that pays you :) I would really  
like to have a chance to talk about the name of this environment.
Because we will have to market it to a lot of people so I would like to  
take the time to think about a name that looks like a name.


Stef


Hi.

I am glad announce first version of PharmIDE project which is complete  
toolset for remote development of Pharo images. It includes:

remote debugger
remote inspector
remote playground
remote browser
Old project RemoteDebuggingTools is deprecated. But it could be used for  
Pharo 5 images. PharmIDE targets Pharo 6 or later and provides  
everything which was done in original project.


For details and live demo look at my blog  
http://dionisiydk.blogspot.fr/2017/01/pharmide-pharo-remote-ide-to-develop.html.


Best regards,
Denis




--
Using Opera's mail client: http://www.opera.com/mail/

Re: [Pharo-dev] [bloc] addressing the moz2d issue

[stepharong]

I think that instead of investigating gtk (yet another library to bind and  
carry around),
it would be smarter to have Sparta back-end using an accelerated Cairo +  
pango.

Why? Because
	- For example Cairo will not disappear in the future (here you will tell  
me that it does not have all the full
	features I think that Bloc should deliver Brick first and focus on  
this because else it will stay a nice

experiment.)
	- We do not have bench with an accelerated compiled version so no idea if  
this is good enough.

- Cairo is about 1.5 mb vs 20Mb and it is packaged.

I share the concerns of Esteban about the maintenance of such Mozz2d  
bundling and he was pretty
clear with me, he will not maintain it nor take any responsibility about  
pharo using it.


So having a Cairo Sparta back-end would be a smart move.
Stef






Hi,

Thank you for the intensive set of issues you raised during the Bloc  
presentation. I think it is worthwhile addressing them more thoroughly,  
so let me start with the issue that seemed to have caused the most  
worries: Sparta & Moz2D.


Please keep in mind that while I am involved to some extent in Bloc, the  
real credits for the current state go to Glenn and Alex.


Moz2D (https://github.com/mozilla/moz2d,  
https://wiki.mozilla.org/Platform/GFX/Moz2D) offers an advanced backend  
and using it puts us on par with the rendering speed of a web browser,  
which is a significant added value over what we have now.


However, as it was noted, it does come with a cost due to the fact that  
it is not available as standalone with only the features we are  
interested in. The vector graphics part is actually buildable out of the  
box. However, the text support needs to be extracted out of Moz2D, and  
this is where the patching scripts are used. The patches are there only  
for compilation purposes and not for features and they are applied  
automatically. You can see it here:

https://github.com/syrel/Moz2D

Alex updated recently the Moz2D version and it worked without problems.  
Of course, future changes in Moz2D might imply changes in this script as  
well, and this implies that we will need to maintain that script. And we  
could imagine applying these patches on the trunk of Moz2D to see if  
they work, and we can also imagine engaging with the Moz2D owners to see  
if we can find a middle ground.


Now, let’s put this into perspective. We are currently using Athens and  
the Cairo backend. While Cairo is provided as a standalone library it  
has not seen significant advances since Mozzila shifted its focus  
towards Moz2D. So, sticking with it might not be an ideal strategy  
either.


Furthermore, just like Athens, Sparta is an abstraction that allows us  
to switch the underlying backend should we need to. Until now we did not  
find a cross-platform backend that is as advanced and complete as Moz2D,  
but there is no reason to think that none other will appear in the  
future. Skia is an alternative but it is only a vector graphic engine  
without text support, so using it would imply to have another library  
for the text support.


Sparta also comes with a reasonable set of tests that is aimed at  
testing the basic Moz2D functionality to make sure that the assumptions  
on top of which Sparta is built are correct.


All in all, I think that the current situation is not ideal, but there  
is already enough engineering in place to actually make it work. And I  
definitely think that the potential it opens is rather significant.


And, if more people look at the scripts, we might find even better and  
cheaper ways to express it.


Cheers,
Doru


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

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








--
Using Opera's mail client: http://www.opera.com/mail/

Re: [Pharo-dev] memoized vs once

[Torsten Bergmann]

stepharong wrote:
>can we rename this selector?
>asMethodConst should be at least be renamed to asConstantMethod

When you use "as {something}" then "something" depicts the result of the 
conversion message sent to an object.

Like in #asNumber or #asString which shows to what the receiver will be 
converted.


My understanding is that in the case discussed the receiver object is 
NOT converted to a constant unchangeable method, so #asConstantMethod would 
not fit as a selector.

Instead it is sent to an object that afterwards is a constant within a method
(so it will not be evaluated later at runtime again) so IMHO #asMethodConstant 
instead of #asMethodConst would be better.

Finding good names is really hardest part in programming...

Thanks
T.

Re: [Pharo-dev] memoized vs once

[stepharong]

Denis

can we rename this selector?
asMethodConst should be at least be renamed to asConstantMethod


Hi Eliot.

2017-01-25 19:56 GMT+01:00 Eliot Miranda :

Hi Ben,

   via FaceBook via twitter I hear you've coined  
BlockClosure>>#memoized.  Allow me to beg you to rename it to  
BlockClosure>>#once.  There's a preexisting implementation of this in  
>>VisualWorks by Travis Griggs called once.  I hope you agree that it's  
good to eliminate gratuitous incompatibilities between dialects and  
that "once" is an elegant name.


#once is not the same as #memoized. #memoized returns another block  
which wrap original one to perform some caching. Actually I not  
understand logic behind it.But #once supposed to evaluate receiver while  
#memoized creates new block.


In Pharo 6 I pushed new method #asMethodConst. Unfortunately I was not  
aware about #once from VisualWorks at this time and reviewers too.
But #asMethodConst is a bit different. It is Object method instead of  
Block. And it is based on AST modification.When asMethodConst is  
executed it replace executing AST-node of sender with receiver which  
produce new method where full message node is replaced by result as  
literal.
I put mode details here  
http://dionisiydk.blogspot.fr/2016/07/magic-with-pharo-reflectivity.html.  
In short you can write expressions like:

10 factorial asMethodConst







--
Using Opera's mail client: http://www.opera.com/mail/

Re: [Pharo-dev] [ANN] Pharo Sprint Friday, Jan 27

[Marcus Denker]

> On 26 Jan 2017, at 14:30, Marcus Denker  wrote:
> 
> (this is a bit late… next will be announced earlier. I will start to put the 
> sprints as official 
> events on the assoc site, too)

https://association.pharo.org/event-2447196 


No idea if it makes sense to have them listed here…

Marcus

[Pharo-dev] [ANN] Pharo Sprint Friday, Jan 27

[Marcus Denker]

(this is a bit late… next will be announced earlier. I will start to put the 
sprints as official 
events on the assoc site, too)


We will organize a Pharo sprint / Moose dojo Friday, 27 Jan, starting at
10:00am. (Local Time Paris).

Goals of this sprint:
- Clean issue tracker to prepare for release Pharo6 
- remove Pharo6 tag from not-important cases
- Check Pharo5 Issues and pending back-ports

Remote Sprint


Remotely, you can join us on Slack. During the sprint, we will try to 
synchronize
local and remote Pharo sprinters.


Known Local Sprint meeting organised
==

We know about just one for this sprint:

Lille/France:
It will be at the Inria Lille, Building B, third floor (RMoD offices).
As the building is not open to the public, please contact us before if
you plan to come.

Re: [Pharo-dev] memoized vs once

[Yuriy Tymchuk]

> On 26 Jan 2017, at 00:30, p...@highoctane.be wrote:
> 
> SomeClass>>#initialize
>self memoize: #someMethod:andParms:.
> 
> and bingo, automatic method memoization keyed by the objects passed.
> 

I had a prototype called “vigorous caching”. It worked for methods without 
parameters though 
(http://blog.yuriy.tymch.uk/2016/02/vigorous-caching-in-pharo-or-how-i-used.html
 
)

Re: [Pharo-dev] Immutability support

[Clément Bera]

Denis' idea is good.

There is one problem with the implementation of jump though.

MyClass>>iv
iv := 1.
[ 2 ] value.
1halt.

MyClass new
beReadOnlyObject ;
iv

When reaching the halt we see there is an extra nil on stack.

I think this is better than the process hack, at least until we add VM
support for this case.

On Thu, Jan 26, 2017 at 11:36 AM, Denis Kudriashov 
wrote:

>
> 2017-01-26 10:59 GMT+01:00 Clément Bera :
>
>> Let's rewrite the method this way:
>>
>> attemptToAssign: value withIndex: index
>> | process |
>> "INSERT CODE HERE"
>> process := Processor activeProcess.
>> [ process suspendedContext: process suspendedContext sender ] fork.
>> Processor yield.
>> self error: 'should not be reached'.
>>
>
> I guess I found simplest solution to problem. Instead of process logic we
> can just use "thisContext sender jump".
>
> attemptToAssign: value withIndex: index
> | process |
>   thisContext sender jump.
>   self error: 'should not be reached'.
>
> In my tests it works correctly. I use this method:
>
> ValueHolder>>contents2: anObject
>
> | result |
>
> result := (contents := anObject).
> self halt.
> ^result printString.
>
>
> So debugger is opened at halt. And #result var contains anObject.
>

[Pharo-dev] [pharo-project/pharo-core] 029fd5: 60357

[GitHub]

  Branch: refs/heads/6.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: 029fd5cd43d54b77ff02a7ec6f974389b4e83c63
  
https://github.com/pharo-project/pharo-core/commit/029fd5cd43d54b77ff02a7ec6f974389b4e83c63
  Author: Jenkins Build Server 
  Date:   2017-01-26 (Thu, 26 Jan 2017)

  Changed paths:
M 
BaselineOfIDE.package/BaselineOfIDE.class/instance/actions/postload_package_.st
M 
ConfigurationOfEpicea.package/ConfigurationOfEpicea.class/instance/tags/stable_.st
A 
ConfigurationOfEpicea.package/ConfigurationOfEpicea.class/instance/versions/version808_.st
M EpiceaBrowsers.package/EpMonitorLogNode.class/class/instance 
creation/for_.st
M EpiceaBrowsers.package/EpMonitorLogNode.class/definition.st
A 
EpiceaBrowsers.package/EpMonitorLogNode.class/instance/accessing/headReference.st
A 
EpiceaBrowsers.package/EpMonitorLogNode.class/instance/accessing/headReference_.st
R 
EpiceaBrowsers.package/EpMonitorLogNode.class/instance/accessing/referencedGlobalNameIfEmptyLog.st
R 
EpiceaBrowsers.package/EpMonitorLogNode.class/instance/accessing/referencedGlobalNameIfEmptyLog_.st
M 
EpiceaBrowsers.package/EpMonitorLogNode.class/instance/accessing/referencedGlobalNamesIfEmptyLog.st
R ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
scripts/script60356.st
A ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
scripts/script60357.st
R ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
updates/update60356.st
A ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
updates/update60357.st
M 
ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st

  Log Message:
  ---
  60357
19601 [Epicea] Epicea monitor is off by default
https://pharo.fogbugz.com/f/cases/19601

19600 [Epicea] OmNullReference shuld provide #globalName
https://pharo.fogbugz.com/f/cases/19600

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

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

[GitHub]

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

Re: [Pharo-dev] Immutability support

[Denis Kudriashov]

2017-01-26 10:59 GMT+01:00 Clément Bera :

> Let's rewrite the method this way:
>
> attemptToAssign: value withIndex: index
> | process |
> "INSERT CODE HERE"
> process := Processor activeProcess.
> [ process suspendedContext: process suspendedContext sender ] fork.
> Processor yield.
> self error: 'should not be reached'.
>

I guess I found simplest solution to problem. Instead of process logic we
can just use "thisContext sender jump".

attemptToAssign: value withIndex: index
| process |
  thisContext sender jump.
  self error: 'should not be reached'.

In my tests it works correctly. I use this method:

ValueHolder>>contents2: anObject

| result |

result := (contents := anObject).
self halt.
^result printString.


So debugger is opened at halt. And #result var contains anObject.

Re: [Pharo-dev] Immutability support

[Denis Kudriashov]

2017-01-26 10:59 GMT+01:00 Clément Bera :

> Let's rewrite the method this way:
>
> attemptToAssign: value withIndex: index
> | process |
> "INSERT CODE HERE"
> process := Processor activeProcess.
> [ process suspendedContext: process suspendedContext sender ] fork.
> Processor yield.
> self error: 'should not be reached'.
>
> This way it's clear that execution flow never reaches the end of the
> method as the error message is never sent. For some reason in the previous
> code by increasing the priority of the process the end of the method could
> be reached, as Denis showed, which leaded to incorrect behavior. This is
> still hackish and we still need to provide a better way of performing such
> returns.
>
> Any code can be written at the  "INSERT CODE HERE" position, including
> exception signals, etc.
>
> Normal methods ends with a return, for example, "^ self". When performed,
> "^ self" pushes "self" on the sender's stack and resumes execution in the
> sender. In this call-back, when reaching the end of the method, the
> sender's execution needs to be resumed, but no value needs to be pushed on
> its stack. That's why instead of a normal return I use:
> process := Processor activeProcess.
> [ process suspendedContext: process suspendedContext sender ] fork.
> Processor yield.
> I don't know how to explain it better. I understand that because it was
> bugged it was very hard to understand. I will put a slice on the bug
> tracker.
>

Thank's Clement. Now I understand it.

Re: [Pharo-dev] Immutability support

[Stefan Marr]

Hi Clement:

> On 26 Jan 2017, at 10:59, Clément Bera  wrote:
> 
> Let's rewrite the method this way:
> 
> attemptToAssign: value withIndex: index 
> | process |
> "INSERT CODE HERE"
>   process := Processor activeProcess.
>   [ process suspendedContext: process suspendedContext sender ] fork. 
>   Processor yield.
>   self error: ‘should not be reached'.

The PRocessorScheduler>>#yield does not guarantee that this process becomes 
never runnable again.
It just puts the processes at the end of the runnable list. The fallback code 
of yield even explicitly forks another processes that’s signaling the old 
process again to make it runnable.

Best regards
Stefan



-- 
Stefan Marr
Johannes Kepler Universität Linz
http://stefan-marr.de/research/

Re: [Pharo-dev] Immutability support

[Clément Bera]

Let's rewrite the method this way:

attemptToAssign: value withIndex: index
| process |
"INSERT CODE HERE"
process := Processor activeProcess.
[ process suspendedContext: process suspendedContext sender ] fork.
Processor yield.
self error: 'should not be reached'.

This way it's clear that execution flow never reaches the end of the method
as the error message is never sent. For some reason in the previous code by
increasing the priority of the process the end of the method could be
reached, as Denis showed, which leaded to incorrect behavior. This is still
hackish and we still need to provide a better way of performing such
returns.

Any code can be written at the  "INSERT CODE HERE" position, including
exception signals, etc.

Normal methods ends with a return, for example, "^ self". When performed,
"^ self" pushes "self" on the sender's stack and resumes execution in the
sender. In this call-back, when reaching the end of the method, the
sender's execution needs to be resumed, but no value needs to be pushed on
its stack. That's why instead of a normal return I use:
process := Processor activeProcess.
[ process suspendedContext: process suspendedContext sender ] fork.
Processor yield.
I don't know how to explain it better. I understand that because it was
bugged it was very hard to understand. I will put a slice on the bug
tracker.



On Thu, Jan 26, 2017 at 10:35 AM, Clément Bera 
wrote:

>
> *Sorry Clement, maybe I am stupid but it is not clear for me.*
>
> *If I put halt after "CAN'T REACH" I got debugger which means that it "can
> reach".*
> *Maybe by "CAN'T REACH" you mean that any return value will not be used?
> But it is not true: if I return something it will be result of original
> assignment expression. But as you said it could crash VM.*
>
> Ok I tried and I can see that. This is why I have bugs. Well "CAN'T REACH"
> was supposed to mean it cannot be reached, I don't understand how it could
> be reached.
>
>
> On Thu, Jan 26, 2017 at 10:18 AM, Denis Kudriashov 
> wrote:
>
>>
>> 2017-01-26 8:11 GMT+01:00 Clément Bera :
>>
>>> The "CAN'T REACH" comment is there because execution never reach that
>>> part of the code. If you write code there, it will never be executed. The
>>> process code performs a return without pushing any value on stack.
>>>
>>
>> Sorry Clement, maybe I am stupid but it is not clear for me.
>> If I put halt after "CAN'T REACH" I got debugger which means that it "can
>> reach".
>> Maybe by "CAN'T REACH" you mean that any return value will not be used?
>> But it is not true: if I return something it will be result of original
>> assignment expression. But as you said it could crash VM.
>>
>>
>>>
>>> Signalling an error is safe if the error is never resumed. But you'll
>>> need the returnNoValue for performance intensive modification tracking.
>>>
>>
>> Do you have reproducible test case to crash VM when #attemptToAssign is
>> badly implemented? It will help for framework implementation and would be
>> nice description for method. In comment we can point to it. Because this
>> magic with forking process is very confusing.
>> Also I not get your "returnNoValue" sentence.
>>
>
>

Re: [Pharo-dev] Immutability support

[Norbert Hartl]

> Am 26.01.2017 um 10:32 schrieb Clément Bera :
> 
> 
> 
> On Thu, Jan 26, 2017 at 9:54 AM, Norbert Hartl  > wrote:
> 
>> Am 26.01.2017 um 08:11 schrieb Clément Bera > >:
>> 
>> The "CAN'T REACH" comment is there because execution never reach that part 
>> of the code. If you write code there, it will never be executed. The process 
>> code performs a return without pushing any value on stack.
>> 
> Because you return from the sender, right?
> 
> Yes because the process code returns to the sender. 
> 
> In Smalltalk a send returns necessarily a value to be pushed on the stack of 
> the context performing the send. In the write barrier call-back, the context 
> is not performing a send, but an instance variable store. Unlike sends, 
> instance variable stores are not expected to push a value on stack. If the 
> call-back returns a value, it's pushed on stack while nothing is expected, 
> and if further code use values on stack it will use the returned value 
> instead of the correct one, furthermore, stack depth computation is messed 
> up, overflowing the context stack somewhere in the runtime memory leading to 
> data corruption.

I see. I'm not sure I understand it correctly. But isn't it the case that you 
return the value of attemptToAssign:index: as return value of the sender? In 
the current implementation it will return self. This would break any method 
with instVar access that do not return self. 
 
>> Signalling an error is safe if the error is never resumed. But you'll need 
>> the returnNoValue for performance intensive modification tracking.
>> 
>> 
> Ok, while you are popping of the stack there is no way to return, right? I 
> cannot see what it has to be that way but I can see that my approach cannot 
> work this way. In my case the error is resumed because not resuming would 
> defeat the purpose of having transparent modification tracking.
> 
> I'll use announcements for it because it is a better fit for that anyway.
> 
> You can signal an error, but then keep the process code. For example:
> 
> Object>>#attemptToAssign: value withIndex: index 
>   | process |
>   NoModification signal.
>   process := Processor activeProcess.
>   [ process suspendedContext: process suspendedContext sender ] forkAt: 
> Processor activePriority + 1.
>   Processor yield.
> 
> this method just works fine.
> 
> However, 
> 
> Object>>#attemptToAssign: value withIndex: index 
>   NoModification signal.
> 
> this method does not work because it returns a value.
> 
Ok, thanks.

Norbert

> 
> Norbert
> 
>> 
>> On Wed, Jan 25, 2017 at 10:26 PM, Denis Kudriashov > > wrote:
>> 
>> 2017-01-25 22:24 GMT+01:00 Denis Kudriashov > >:
>> For the Process hack, it's because the call-back was designed to return no 
>> value.
>> 
>> Now I am confused. 
>> Why anybody needs to return value from this method? 
>> And why there is  "CAN'T REACH" comment at the end of method?
>> Do you mean that method should never return? 
>>  
>> It may look like it works when returning a value but you will have uncommon 
>> crashes.
>> 
>> And is it safe to just signal error? 
>> 
> 
> 

Re: [Pharo-dev] Immutability support

[Clément Bera]

*Sorry Clement, maybe I am stupid but it is not clear for me.*

*If I put halt after "CAN'T REACH" I got debugger which means that it "can
reach".*
*Maybe by "CAN'T REACH" you mean that any return value will not be used?
But it is not true: if I return something it will be result of original
assignment expression. But as you said it could crash VM.*

Ok I tried and I can see that. This is why I have bugs. Well "CAN'T REACH"
was supposed to mean it cannot be reached, I don't understand how it could
be reached.


On Thu, Jan 26, 2017 at 10:18 AM, Denis Kudriashov 
wrote:

>
> 2017-01-26 8:11 GMT+01:00 Clément Bera :
>
>> The "CAN'T REACH" comment is there because execution never reach that
>> part of the code. If you write code there, it will never be executed. The
>> process code performs a return without pushing any value on stack.
>>
>
> Sorry Clement, maybe I am stupid but it is not clear for me.
> If I put halt after "CAN'T REACH" I got debugger which means that it "can
> reach".
> Maybe by "CAN'T REACH" you mean that any return value will not be used?
> But it is not true: if I return something it will be result of original
> assignment expression. But as you said it could crash VM.
>
>
>>
>> Signalling an error is safe if the error is never resumed. But you'll
>> need the returnNoValue for performance intensive modification tracking.
>>
>
> Do you have reproducible test case to crash VM when #attemptToAssign is
> badly implemented? It will help for framework implementation and would be
> nice description for method. In comment we can point to it. Because this
> magic with forking process is very confusing.
> Also I not get your "returnNoValue" sentence.
>

Re: [Pharo-dev] Immutability support

[Clément Bera]

On Thu, Jan 26, 2017 at 9:54 AM, Norbert Hartl  wrote:

>
> Am 26.01.2017 um 08:11 schrieb Clément Bera :
>
> The "CAN'T REACH" comment is there because execution never reach that part
> of the code. If you write code there, it will never be executed. The
> process code performs a return without pushing any value on stack.
>
> Because you return from the sender, right?
>

Yes because the process code returns to the sender.

In Smalltalk a send returns necessarily a value to be pushed on the stack
of the context performing the send. In the write barrier call-back, the
context is not performing a send, but an instance variable store. Unlike
sends, instance variable stores are not expected to push a value on stack.
If the call-back returns a value, it's pushed on stack while nothing is
expected, and if further code use values on stack it will use the returned
value instead of the correct one, furthermore, stack depth computation is
messed up, overflowing the context stack somewhere in the runtime memory
leading to data corruption.

> Signalling an error is safe if the error is never resumed. But you'll need
> the returnNoValue for performance intensive modification tracking.
>
>
> Ok, while you are popping of the stack there is no way to return, right? I
> cannot see what it has to be that way but I can see that my approach cannot
> work this way. In my case the error is resumed because not resuming would
> defeat the purpose of having transparent modification tracking.
>
> I'll use announcements for it because it is a better fit for that anyway.
>

You can signal an error, but then keep the process code. For example:

Object>>#attemptToAssign: value withIndex: index
| process |
NoModification signal.
process := Processor activeProcess.
[ process suspendedContext: process suspendedContext sender ] forkAt:
Processor activePriority + 1.
Processor yield.

this method just works fine.

However,

Object>>#attemptToAssign: value withIndex: index
NoModification signal.

this method does not work because it returns a value.


> Norbert
>
>
> On Wed, Jan 25, 2017 at 10:26 PM, Denis Kudriashov 
> wrote:
>
>>
>> 2017-01-25 22:24 GMT+01:00 Denis Kudriashov :
>>
>>> For the Process hack, it's because the call-back was designed to return
 no value.
>>>
>>>
>>> Now I am confused.
>>> Why anybody needs to return value from this method?
>>> And why there is  "CAN'T REACH" comment at the end of method?
>>> Do you mean that method should never return?
>>>
>>>
 It may look like it works when returning a value but you will have
 uncommon crashes.
>>>
>>>
>> And is it safe to just signal error?
>>
>
>
>

Re: [Pharo-dev] Immutability support

[Denis Kudriashov]

2017-01-26 8:11 GMT+01:00 Clément Bera :

> The "CAN'T REACH" comment is there because execution never reach that part
> of the code. If you write code there, it will never be executed. The
> process code performs a return without pushing any value on stack.
>

Sorry Clement, maybe I am stupid but it is not clear for me.
If I put halt after "CAN'T REACH" I got debugger which means that it "can
reach".
Maybe by "CAN'T REACH" you mean that any return value will not be used? But
it is not true: if I return something it will be result of original
assignment expression. But as you said it could crash VM.


>
> Signalling an error is safe if the error is never resumed. But you'll need
> the returnNoValue for performance intensive modification tracking.
>

Do you have reproducible test case to crash VM when #attemptToAssign is
badly implemented? It will help for framework implementation and would be
nice description for method. In comment we can point to it. Because this
magic with forking process is very confusing.
Also I not get your "returnNoValue" sentence.

Re: [Pharo-dev] CALL for GSoC project proposals

[Guillermo Polito]

We just add project proposals there?

On Wed, Jan 25, 2017 at 11:19 AM, Stephane Ducasse 
wrote:

> But I understand the process.
> So I did a pass
>
> On Wed, Jan 25, 2017 at 11:05 AM, Stephane Ducasse <
> stepharo.s...@gmail.com> wrote:
>
>> Hi yuriy
>>
>> you could have done it a bit less brutal.
>>
>> Stef
>>
>> On Wed, Jan 25, 2017 at 10:52 AM, Yuriy Tymchuk 
>> wrote:
>>
>>> Dear all, this year we plan to apply again as a mentoring organization
>>> for Google Summer of Code. However, we are going to follow a different
>>> strategy regarding project proposals. Instead of having a swarm of small
>>> ideas we want to end up with around ten well-described projects.
>>>
>>> This is why I cleaned the topics file, and I ask all interested people
>>> to propose the best one of your topics here:
>>> https://github.com/pharo-project/pharo-project-proposals/blo
>>> b/master/Topics.st
>>>
>>> There is a copy of the old file in case you want to remind what you
>>> proposed last year:
>>> https://github.com/pharo-project/pharo-project-proposals/blo
>>> b/master/Topics-old.st
>>>
>>> As we are going for well-described projects with links to related
>>> resources, pictures, prototype videos, etc. you can also add a standalone
>>> file with a project description in some rich format to this dir:
>>> https://github.com/pharo-project/pharo-project-proposals/tre
>>> e/master/topics
>>>
>>> Again, we want around ten diverse and well-described projects with a
>>> precise definition of the domain and the problem, possible solutions, and
>>> expected benefits. So it also will be nice to have diverse projects, so if
>>> you are collaborating with someone, please try to propose a joined project
>>> that will have backup members (also crucial for the application) and do not
>>> create multiple similar but less powerful projects.
>>>
>>> We heavily rely on the input of the community.
>>> Let’s make Pharo great again ;P
>>> Uko on behalf of the Pharo GSoC application team.
>>>
>>
>>
>

Re: [Pharo-dev] Immutability support

[Norbert Hartl]

> Am 26.01.2017 um 08:11 schrieb Clément Bera :
> 
> The "CAN'T REACH" comment is there because execution never reach that part of 
> the code. If you write code there, it will never be executed. The process 
> code performs a return without pushing any value on stack.
> 
Because you return from the sender, right?

> Signalling an error is safe if the error is never resumed. But you'll need 
> the returnNoValue for performance intensive modification tracking.
> 
> 
Ok, while you are popping of the stack there is no way to return, right? I 
cannot see what it has to be that way but I can see that my approach cannot 
work this way. In my case the error is resumed because not resuming would 
defeat the purpose of having transparent modification tracking.

I'll use announcements for it because it is a better fit for that anyway.

Norbert

> 
> On Wed, Jan 25, 2017 at 10:26 PM, Denis Kudriashov  > wrote:
> 
> 2017-01-25 22:24 GMT+01:00 Denis Kudriashov  >:
> For the Process hack, it's because the call-back was designed to return no 
> value.
> 
> Now I am confused. 
> Why anybody needs to return value from this method? 
> And why there is  "CAN'T REACH" comment at the end of method?
> Do you mean that method should never return? 
>  
> It may look like it works when returning a value but you will have uncommon 
> crashes.
> 
> And is it safe to just signal error? 
>