Re: [Pharo-dev] TxText model

[p...@highoctane.be]

On Wed, Apr 6, 2016 at 2:07 AM, Sean P. DeNigris 
wrote:

> philippe.b...@highoctane.be wrote
> > So, I ended up in ParagraphEditor, Text attributes etc.
>
> Ugh. How many beautiful projects have died because of Paragraph and
> associated editors?!


A damn lot, I can tell you.


> This is where my vim keybindings experiment came
> screeching to a halt.
>
>
>
> -
> Cheers,
> Sean
> --
> View this message in context:
> http://forum.world.st/TxText-model-tp4888199p4888515.html
> Sent from the Pharo Smalltalk Developers mailing list archive at
> Nabble.com.
>
>

Re: [Pharo-dev] Pillar vs Pandoc?

[Damien Cassou]

Hi Alex,

Alexandre Bergel  writes:

> Offray is visiting us in Chile. 
> He showed me http://pandoc.org and it seems to be pretty cool. Looks like a 
> strong competitor.
> I am wondering how Pillar position itself against Pandoc?

AFAIK, pandoc is only a tool, not a language. Pandoc has no syntax on
its own, it doesn't mean anything to "write a document in Pandoc".

Nevertheless, Pandoc is nice because it accepts many formats as input
and can export to many formats.

-- 
Damien Cassou
http://damiencassou.seasidehosting.st

"Success is the ability to go from one failure to another without
losing enthusiasm." --Winston Churchill

Re: [Pharo-dev] TxText model

[Sean P. DeNigris]

philippe.b...@highoctane.be wrote
> So, I ended up in ParagraphEditor, Text attributes etc.

Ugh. How many beautiful projects have died because of Paragraph and
associated editors?! This is where my vim keybindings experiment came
screeching to a halt.



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/TxText-model-tp4888199p4888515.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] Pharo Days 2016 Photos and Video

[Sean P. DeNigris]

stepharo wrote
>> Beautiful !
>>
>> Thank you.
> 
> +1

Yes, big +1. I wish I could've been there!!



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/Pharo-Days-2016-Photos-and-Video-tp4888134p4888511.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

[Pharo-dev] Pillar vs Pandoc?

[Alexandre Bergel]

Hi!

Offray is visiting us in Chile. 
He showed me http://pandoc.org and it seems to be pretty cool. Looks like a 
strong competitor.
I am wondering how Pillar position itself against Pandoc?

Cheers,
Alexandre
-- 
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

[Pharo-dev] Two possible Morphic-related issues

[Carlos Lombardi]

Hi,

proviso:
this is my first mail to a Pharo list. I guess that it is pertinent for the
pharo-dev list, since it describes a possible failure in Pharo 4 and an
enhancement suggestion. If this mail is better suited for the pharo-users
list, or else it should be better addressed to both lists, please let me
know. Thanks!

--

I just upgraded an application from Pharo 3 to Pharo 4. In this
application, we use StrikeFont class>>fromUser:allowKeyboard: to let the
user choose the point size of the font in a PluggableTextMorph. In fact,
the size is applied to the selected part of the text only, so that we allow
the edition of a text mixing different point sizes, and also bold, italics
and underline.
I hope to be able to publish shortly a button row that adds this capability
to a given PluggableTextMorph.

The mentioned method, StrikeFont class>>fromUser:allowKeyboard:, builds a
menu where a check box is added to each option. This menu is told the
currently selected point size, to propose it as pre-selected value. To
build such a menu, the options are Associations (Boolean -> String), where
the boolean is true for the option to be pre-selected, instead of just
Strings. This works OK in Pharo 3. But in Pharo 4, we get an error when
using StrikeFont class>>fromUser:allowKeyboard:. The reason lies in
MenuMorph>>addToggle:target:selector:getStateSelector:enablementSelector:argumentList:,
where the message translated is sent to the first parameter. This parameter
is assumed to be a String, whilst in this case it is the Association I just
mentioned.

I provisionally patched this issue by modifying the class method in
StrikeFont, in order to give the menu Strings instead of Associations. As
far as this way of selecting a point size is still usable, it would be nice
to have this issue fixed. If there is another, maybe more modern, way of
graphically choosing a point size, please let me know.

We had another problem to obtain a mix-style PluggableTextMorph. When the
Text is accepted, the model is given actually a style-less Text, this is
explicitly established in PluggableTextMorph>>acceptTextInModel. I guess
that such is convenient when the Text being edited is code, so that the
styles are automatically set by the editor, and must not be present in the
code of a method. But in our case, it is the user that establishes the
styles, so that they must be preserved.
I created a subclass of PluggableTextMorph, in which the Text is passed
unchanged to the model. If there is a better way to solve this issue,
please tell me.
Please consider the possibility of creating a specific CodeTextMorph in
order to deal with the peculiarities of the code edition, instead of mixing
them in the would-be-generic PluggableTextMorph.

Cordially - Carlos Lombardi

Re: [Pharo-dev] Philosophy here

[Richard Sargent]

Igor Stasenko wrote
> (This philosophical post provoked by discussion in another thread where we
> talking about cases of implementing wrappers and layers of composition.)
> 
> To achieve more you shall do more.
> Usual truth thing in daily life.
> Not so true for programming.
> It actually
> 'do less to achieve more'.
> Because it's non-linear in programming. Because each line of code you add
> to the system is increasing it complexity accordingly. And that means more
> effort for future maintenance for you, or for some other unsuspecting
> victim.
> So, that's why i always look how to do less, reduce the amount of code, to
> achieve something. But not just plainly implement yet another feature, so
> its done.

Nice!

I'll add one, inspired by orbital mechanics and unlocking car doors in the
rain.

To go faster, slow down.
A slightly slower, more deliberate pace will yield greater results than
rushing headlong into something.



> 
> -- 
> Best regards,
> Igor Stasenko.





--
View this message in context: 
http://forum.world.st/Philosophy-here-tp4888073p4888456.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] [ bloc ] I do not understand why some behavior is not in the right place

[Igor Stasenko]

On 5 April 2016 at 17:27, Igor Stasenko  wrote:

>
>
> On 5 April 2016 at 16:29, Aliaksei Syrel  wrote:
>
>> Now let's take a look at this code:
>>
>> drawOnSpartaCanvas: aCanvas
>>
>>> aCanvas
>>>   clipPreserveBy: self shape during: [
>>>   aCanvas paintGroup: [
>>> aCanvas setPaint: self shape fillPaint.
>>> aCanvas fillPreserve.
>>> aCanvas paintMode source.
>>> aCanvas setStrokePaint: self shape strokePaint.
>>> aCanvas stroke ] ]
>>
>>
>> You may be curious why it is so ugly :) Make it work - make it right -
>> make it fast. We are on the first etappe, because I invested zero time in
>> rendering stuff.
>>
>> What you see is the minimal amount of cairo primitive calls that are
>> needed to render not overlapping fill and stroke. Clipping is needed to
>> make sure that stroke does not get rendered outside of a path. Group is
>> needed to have transparent target in order to make source paint mode work
>> as expected. Compared to image_surface group, it in this case allows to
>> preserve clip and current cairo state which is pushed to stack during
>> push_group and restored during pop_group_to_source. fillPreserve allows to
>> reuse the same path as used for clipping before saving cpu time on loading
>> path.
>>
>> Yes, i understand that. You are forced to do that. And it is ugly not
> because of all you listed above, it ugly because you could just use a
> cascade:
>
> aCanvas setPaint: self shape fillPaint;
>   fillPreserve;
>paintMode source;
>setStrokePaint: self shape strokePaint;
> stroke
>
> (something like that)
> but yeah.. that can wait .. since it is still work in progress. I agree.
>
>
>> It is implemented in canvas specific method after dispatch though canvas,
>> so we are allowed to use canvas specific api, for example groups.
>>
>> How to model stroke, fillPreserve and paintModein terms of Athens?
>>
>>
> A good question. And i don't have an answer to it , ready for you.
> 1. Stroke can be expressed as a special kind of paint. And that how its
> done in Athens.
>
> 2. What fillPreserve is, is can't find it in source code? Some
> hot-swapping and preserving context state , i guess.
>
> 3. As for paint mode, it is already in Athens, so why you asking? You
> don't like how it is done or what?
>
>
or maybe you meant how to group those operation and express them as command
group?
I have no simple answer here. Because this is root points of the core of
graphics engine. From one side, you want such things be exposed to user,
and from other you want a higher dimension concepts/operations to be
allowed by combining those.
There's no simple way. I would just stop at this level, letting user to
decide how he wants to play with those pieces to achieve results he wants.



>
>> Cheers,
>> Alex
>>
>> On Tue, Apr 5, 2016 at 3:15 PM, Aliaksei Syrel 
>> wrote:
>>
>>> Hello Igor
>>>
>>> Thanks for extensive design explanation and effort!
>>> Issues you mentioned in previous emails are important and need to be
>>> addressed :)
>>> fill(), stroke() fillPreserve() strokePreserve() need to disappear in
>>> the end. We will come back to them later.
>>>
>>> Let me tell a few words about Sparta.
>>> Sparta implements Athens interface api (excluding some experimental
>>> stuff to test possible performance boost in a few places) and does not have
>>> task to remove Athens style and abstractions. Ideally Sparta will be
>>> AthensCairo for bloc. I'm looking forward for your help :)
>>>
>>> Here are some aspects in AthensCairo that Sparta tries to address in
>>> first place:
>>>
>>>- *Clipping in local coordinates*. It is critical in Bloc. You
>>>implemented AthensCairo to have vector based rendering in Morphic and 
>>> Pharo
>>>in general. Morphic lives in global coordinates, so your choice to clip 
>>> in
>>>global coordinate is perfect! At the same time global clipping in bloc 
>>> adds
>>>complexity. Sparta clips always in local coordinates (user space in cairo
>>>terminology).
>>>- *Clip by arbitrary path*. Athens and AthenCairo expect to see
>>>aRectangle as clipping region - your wise choice for morphic. In bloc I
>>>would have clipping by arbitrary path. clipBy:during: gets aPath.
>>>Rectangle/Color is polymorphic with path/paint in Sparta
>>>- *Support of groups*. (maybe user-level aspect? like shadows)
>>>Groups are powerful in cairo (do they exist outside of cairo?) and allow 
>>> to
>>>draw both transparent fill and stroke without overlapping using only one
>>>path. On class side of BlElement there are examples (exampleCircle) that
>>>show such behavior.
>>>- *Do not maintain and set pathTransformation before each
>>>render-dependent action.* Questionable but what if Canvas will not
>>>maintain current state of pathTransform? Instead all transformations can 
>>> be
>>>directly applied on cairo_t using native calls. If there is a need to get
>>>actual matrix 

Re: [Pharo-dev] [ bloc ] I do not understand why some behavior is not in the right place

[Igor Stasenko]

On 5 April 2016 at 16:29, Aliaksei Syrel  wrote:

> Now let's take a look at this code:
>
> drawOnSpartaCanvas: aCanvas
>
>> aCanvas
>>   clipPreserveBy: self shape during: [
>>   aCanvas paintGroup: [
>> aCanvas setPaint: self shape fillPaint.
>> aCanvas fillPreserve.
>> aCanvas paintMode source.
>> aCanvas setStrokePaint: self shape strokePaint.
>> aCanvas stroke ] ]
>
>
> You may be curious why it is so ugly :) Make it work - make it right -
> make it fast. We are on the first etappe, because I invested zero time in
> rendering stuff.
>
> What you see is the minimal amount of cairo primitive calls that are
> needed to render not overlapping fill and stroke. Clipping is needed to
> make sure that stroke does not get rendered outside of a path. Group is
> needed to have transparent target in order to make source paint mode work
> as expected. Compared to image_surface group, it in this case allows to
> preserve clip and current cairo state which is pushed to stack during
> push_group and restored during pop_group_to_source. fillPreserve allows to
> reuse the same path as used for clipping before saving cpu time on loading
> path.
>
> Yes, i understand that. You are forced to do that. And it is ugly not
because of all you listed above, it ugly because you could just use a
cascade:

aCanvas setPaint: self shape fillPaint;
  fillPreserve;
   paintMode source;
   setStrokePaint: self shape strokePaint;
stroke

(something like that)
but yeah.. that can wait .. since it is still work in progress. I agree.


> It is implemented in canvas specific method after dispatch though canvas,
> so we are allowed to use canvas specific api, for example groups.
>
> How to model stroke, fillPreserve and paintModein terms of Athens?
>
>
A good question. And i don't have an answer to it , ready for you.
1. Stroke can be expressed as a special kind of paint. And that how its
done in Athens.

2. What fillPreserve is, is can't find it in source code? Some hot-swapping
and preserving context state , i guess.

3. As for paint mode, it is already in Athens, so why you asking? You don't
like how it is done or what?


>
> Cheers,
> Alex
>
> On Tue, Apr 5, 2016 at 3:15 PM, Aliaksei Syrel 
> wrote:
>
>> Hello Igor
>>
>> Thanks for extensive design explanation and effort!
>> Issues you mentioned in previous emails are important and need to be
>> addressed :)
>> fill(), stroke() fillPreserve() strokePreserve() need to disappear in the
>> end. We will come back to them later.
>>
>> Let me tell a few words about Sparta.
>> Sparta implements Athens interface api (excluding some experimental stuff
>> to test possible performance boost in a few places) and does not have task
>> to remove Athens style and abstractions. Ideally Sparta will be AthensCairo
>> for bloc. I'm looking forward for your help :)
>>
>> Here are some aspects in AthensCairo that Sparta tries to address in
>> first place:
>>
>>- *Clipping in local coordinates*. It is critical in Bloc. You
>>implemented AthensCairo to have vector based rendering in Morphic and 
>> Pharo
>>in general. Morphic lives in global coordinates, so your choice to clip in
>>global coordinate is perfect! At the same time global clipping in bloc 
>> adds
>>complexity. Sparta clips always in local coordinates (user space in cairo
>>terminology).
>>- *Clip by arbitrary path*. Athens and AthenCairo expect to see
>>aRectangle as clipping region - your wise choice for morphic. In bloc I
>>would have clipping by arbitrary path. clipBy:during: gets aPath.
>>Rectangle/Color is polymorphic with path/paint in Sparta
>>- *Support of groups*. (maybe user-level aspect? like shadows) Groups
>>are powerful in cairo (do they exist outside of cairo?) and allow to draw
>>both transparent fill and stroke without overlapping using only one path.
>>On class side of BlElement there are examples (exampleCircle) that show
>>such behavior.
>>- *Do not maintain and set pathTransformation before each
>>render-dependent action.* Questionable but what if Canvas will not
>>maintain current state of pathTransform? Instead all transformations can 
>> be
>>directly applied on cairo_t using native calls. If there is a need to get
>>actual matrix we can ask cairo directly. From my perspective it simplifies
>>transformation stuff a little bit.
>>- *Benefit from cairo_save and cairo_restore.* AthensCairo maintains
>>state manually by setting transformation matrix and clip. Instead we could
>>save and restore state without caring about clip/matrix which simplifies
>>code. Check SpartaCanvas>>#clipBy:during:
>>
>>
>> Cheers,
>> Alex
>>
>> On Tue, Apr 5, 2016 at 2:12 PM, Igor Stasenko  wrote:
>>
>>>
>>> Couple more words about that fill() function abstraction.
>>> Now you probably understand why there's no notion of stroke operation in
>>> Athens.
>>> Because instead of introducing 

Re: [Pharo-dev] [ bloc ] I do not understand why some behavior is not in the right place

[Igor Stasenko]

On 5 April 2016 at 16:51, Aliaksei Syrel  wrote:

> Let me now clarify terminology behind path / shape (with fill and stroke).
>
> We decided to not invent a wheel and rely on our knowledge of english.
> Instead it is better to be in sync with terminology used among graphics and
> vector designers.
>
> As an example let's stick with Adobe's naming conventions (Photoshop,
> After Effects and Illustrator are widely used). [1]
>
> Yeah, who are me, and who Adobe :)


> *Path*
>
>> A path consists of *segments* and *vertices*. Segments are the lines or
>> curves that connect vertices. Vertices define where each segment of a path
>> starts and ends.
>
>
>  A path itself has no visual appearance in rendered output; it is
>> essentially a collection of information about how to place or modify other
>> visual elements.
>
>
> Right, but as you can see, that is just a specific way how you can define
a shape (shape in my terms).


> *Shape*
>
>> [ ... ] layers contain vector graphics objects called *shapes*. By
>> default, a shape consists of a path, a stroke, and a fill.
>
>
> You can modify a shape path by applying *path operations*, such as Wiggle
>> Paths and Pucker & Bloat. You apply a stroke to a path or fill the area
>> defined by a path with color by applying *paint operations*.
>
>
>
Maybe an idea of having BlShape that holds path, fill and stroke is not
> that bad as you thought? Anyway we found even better way.
>
> Sure, but now, maybe you can see, why my definition of shape is more
generic. It doesn't says it can only be filled or stoked. It is orthogonal.
I take the definition of shape in its purest form: anything that can have
some form, designating location(s) on surface. It even more generic than
Adobe's Path, since path is just a single case of it.

>From that perspective, yes your BlShape conforms to Adobe's shape, but also
inherits its limitations.



> P.S. There is always a *reason* behind our decision. I am not the only
> person that made that decision. it was discussed multiple times.
>
> Of course. But if we started talking about authorities, i don't think if
you ask a person on the street, what shape is, his answer will start from
'Adobe defines it as  ' :)



> Cheers,
> Alex
>
> [1]
> https://helpx.adobe.com/after-effects/using/overview-shape-layers-paths-vector.html
> 
>
> On Tue, Apr 5, 2016 at 3:29 PM, Aliaksei Syrel 
> wrote:
>
>> Now let's take a look at this code:
>>
>> drawOnSpartaCanvas: aCanvas
>>
>>> aCanvas
>>>   clipPreserveBy: self shape during: [
>>>   aCanvas paintGroup: [
>>> aCanvas setPaint: self shape fillPaint.
>>> aCanvas fillPreserve.
>>> aCanvas paintMode source.
>>> aCanvas setStrokePaint: self shape strokePaint.
>>> aCanvas stroke ] ]
>>
>>
>> You may be curious why it is so ugly :) Make it work - make it right -
>> make it fast. We are on the first etappe, because I invested zero time in
>> rendering stuff.
>>
>> What you see is the minimal amount of cairo primitive calls that are
>> needed to render not overlapping fill and stroke. Clipping is needed to
>> make sure that stroke does not get rendered outside of a path. Group is
>> needed to have transparent target in order to make source paint mode work
>> as expected. Compared to image_surface group, it in this case allows to
>> preserve clip and current cairo state which is pushed to stack during
>> push_group and restored during pop_group_to_source. fillPreserve allows to
>> reuse the same path as used for clipping before saving cpu time on loading
>> path.
>>
>> It is implemented in canvas specific method after dispatch though canvas,
>> so we are allowed to use canvas specific api, for example groups.
>>
>> How to model stroke, fillPreserve and paintModein terms of Athens?
>>
>>
>> Cheers,
>> Alex
>>
>> On Tue, Apr 5, 2016 at 3:15 PM, Aliaksei Syrel 
>> wrote:
>>
>>> Hello Igor
>>>
>>> Thanks for extensive design explanation and effort!
>>> Issues you mentioned in previous emails are important and need to be
>>> addressed :)
>>> fill(), stroke() fillPreserve() strokePreserve() need to disappear in
>>> the end. We will come back to them later.
>>>
>>> Let me tell a few words about Sparta.
>>> Sparta implements Athens interface api (excluding some experimental
>>> stuff to test possible performance boost in a few places) and does not have
>>> task to remove Athens style and abstractions. Ideally Sparta will be
>>> AthensCairo for bloc. I'm looking forward for your help :)
>>>
>>> Here are some aspects in AthensCairo that Sparta tries to address in
>>> first place:
>>>
>>>- *Clipping in local coordinates*. It is critical in Bloc. You
>>>implemented AthensCairo to have vector based rendering in Morphic and 
>>> Pharo
>>>in general. Morphic lives in global coordinates, so your choice to clip 
>>> in
>>>global coordinate is perfect! At the same 

Re: [Pharo-dev] [ bloc ] I do not understand why some behavior is not in the right place

[Aliaksei Syrel]

Let me now clarify terminology behind path / shape (with fill and stroke).

We decided to not invent a wheel and rely on our knowledge of english.
Instead it is better to be in sync with terminology used among graphics and
vector designers.

As an example let's stick with Adobe's naming conventions (Photoshop, After
Effects and Illustrator are widely used). [1]

*Path*

> A path consists of *segments* and *vertices*. Segments are the lines or
> curves that connect vertices. Vertices define where each segment of a path
> starts and ends.


 A path itself has no visual appearance in rendered output; it is
> essentially a collection of information about how to place or modify other
> visual elements.


*Shape*

> [ ... ] layers contain vector graphics objects called *shapes*. By
> default, a shape consists of a path, a stroke, and a fill.


You can modify a shape path by applying *path operations*, such as Wiggle
> Paths and Pucker & Bloat. You apply a stroke to a path or fill the area
> defined by a path with color by applying *paint operations*.


Maybe an idea of having BlShape that holds path, fill and stroke is not
that bad as you thought? Anyway we found even better way.

P.S. There is always a *reason* behind our decision. I am not the only
person that made that decision. it was discussed multiple times.

Cheers,
Alex

[1]
https://helpx.adobe.com/after-effects/using/overview-shape-layers-paths-vector.html


On Tue, Apr 5, 2016 at 3:29 PM, Aliaksei Syrel  wrote:

> Now let's take a look at this code:
>
> drawOnSpartaCanvas: aCanvas
>
>> aCanvas
>>   clipPreserveBy: self shape during: [
>>   aCanvas paintGroup: [
>> aCanvas setPaint: self shape fillPaint.
>> aCanvas fillPreserve.
>> aCanvas paintMode source.
>> aCanvas setStrokePaint: self shape strokePaint.
>> aCanvas stroke ] ]
>
>
> You may be curious why it is so ugly :) Make it work - make it right -
> make it fast. We are on the first etappe, because I invested zero time in
> rendering stuff.
>
> What you see is the minimal amount of cairo primitive calls that are
> needed to render not overlapping fill and stroke. Clipping is needed to
> make sure that stroke does not get rendered outside of a path. Group is
> needed to have transparent target in order to make source paint mode work
> as expected. Compared to image_surface group, it in this case allows to
> preserve clip and current cairo state which is pushed to stack during
> push_group and restored during pop_group_to_source. fillPreserve allows to
> reuse the same path as used for clipping before saving cpu time on loading
> path.
>
> It is implemented in canvas specific method after dispatch though canvas,
> so we are allowed to use canvas specific api, for example groups.
>
> How to model stroke, fillPreserve and paintModein terms of Athens?
>
>
> Cheers,
> Alex
>
> On Tue, Apr 5, 2016 at 3:15 PM, Aliaksei Syrel 
> wrote:
>
>> Hello Igor
>>
>> Thanks for extensive design explanation and effort!
>> Issues you mentioned in previous emails are important and need to be
>> addressed :)
>> fill(), stroke() fillPreserve() strokePreserve() need to disappear in the
>> end. We will come back to them later.
>>
>> Let me tell a few words about Sparta.
>> Sparta implements Athens interface api (excluding some experimental stuff
>> to test possible performance boost in a few places) and does not have task
>> to remove Athens style and abstractions. Ideally Sparta will be AthensCairo
>> for bloc. I'm looking forward for your help :)
>>
>> Here are some aspects in AthensCairo that Sparta tries to address in
>> first place:
>>
>>- *Clipping in local coordinates*. It is critical in Bloc. You
>>implemented AthensCairo to have vector based rendering in Morphic and 
>> Pharo
>>in general. Morphic lives in global coordinates, so your choice to clip in
>>global coordinate is perfect! At the same time global clipping in bloc 
>> adds
>>complexity. Sparta clips always in local coordinates (user space in cairo
>>terminology).
>>- *Clip by arbitrary path*. Athens and AthenCairo expect to see
>>aRectangle as clipping region - your wise choice for morphic. In bloc I
>>would have clipping by arbitrary path. clipBy:during: gets aPath.
>>Rectangle/Color is polymorphic with path/paint in Sparta
>>- *Support of groups*. (maybe user-level aspect? like shadows) Groups
>>are powerful in cairo (do they exist outside of cairo?) and allow to draw
>>both transparent fill and stroke without overlapping using only one path.
>>On class side of BlElement there are examples (exampleCircle) that show
>>such behavior.
>>- *Do not maintain and set pathTransformation before each
>>render-dependent action.* Questionable but what if Canvas will not
>>maintain current state of pathTransform? Instead all transformations can 
>> be
>>directly 

Re: [Pharo-dev] [ bloc ] I do not understand why some behavior is not in the right place

[Igor Stasenko]

On 5 April 2016 at 16:15, Aliaksei Syrel  wrote:

> Hello Igor
>
> Thanks for extensive design explanation and effort!
> Issues you mentioned in previous emails are important and need to be
> addressed :)
> fill(), stroke() fillPreserve() strokePreserve() need to disappear in the
> end. We will come back to them later.
>
> /me feel happiness :)


> Let me tell a few words about Sparta.
> Sparta implements Athens interface api (excluding some experimental stuff
> to test possible performance boost in a few places) and does not have task
> to remove Athens style and abstractions. Ideally Sparta will be AthensCairo
> for bloc. I'm looking forward for your help :)
>
> Here are some aspects in AthensCairo that Sparta tries to address in first
> place:
>
>- *Clipping in local coordinates*. It is critical in Bloc. You
>implemented AthensCairo to have vector based rendering in Morphic and Pharo
>in general. Morphic lives in global coordinates, so your choice to clip in
>global coordinate is perfect! At the same time global clipping in bloc adds
>complexity. Sparta clips always in local coordinates (user space in cairo
>terminology).
>
> No, my code is not perfect. Don't say it like that. It was just a mere
attempt to marry Morphic with Athens, in order to make things work.. But if
it works, it doesn't means it perfect. It just works. I don't need false
credit(s) :)

Ideally , of course, all clipping should be done in local coordinates.
There should be no, or as little as possible things, that require absolute
coordinates. And so, i am happy to hear that, and that we are on same side
here, i can only welcome any steps towards that direction.


>
>- *Clip by arbitrary path*. Athens and AthenCairo expect to see
>aRectangle as clipping region - your wise choice for morphic. In bloc I
>would have clipping by arbitrary path. clipBy:during: gets aPath.
>Rectangle/Color is polymorphic with path/paint in Sparta
>
> That is also a step forward. Ideally it should be possible in Athens as
well, to clip using any shape. But.. yeah.. we needed to implement simplest
things  first, before introducing more.
So, ideally what you need is to extend functionality of
#clipBy:during:  , of AthensCanvas, and allow any shape, not just Rectangle.


>- *Support of groups*. (maybe user-level aspect? like shadows) Groups
>are powerful in cairo (do they exist outside of cairo?) and allow to draw
>both transparent fill and stroke without overlapping using only one path.
>On class side of BlElement there are examples (exampleCircle) that show
>such behavior.
>
> Hmm.. That is a higher level/dimension concept. I doubt that graphics
engine needs to support it out of the box.
Grouping operations is up to the user.. there's no single fixed way how one
can group simple operations of fill() function.. and in what order whatever.

I do not object that grouping operations are not useful. I just objecting
that it should be part of core API.
Any kind of grouping is allowed at the user level, so in Bloc you are free
to introduce it the way you like or want.

I would say more about it, if you would motivate , what you can see, how
graphical engine could potentially allow better performance/ease of use in
case if it will support groups.
For instance , in OpenGL there are a command lists, which you can compile
once and then execute it as many time as you want. That is useful in terms
that it can prepare a bunch of operations and optimize them for later use.
This is basically a simple command pattern, implemented in C :)
>From that perspective, if you mean support of groups in that way.. then it
is good direction. But if not, then i am not convinced.


>- *Do not maintain and set pathTransformation before each
>render-dependent action.* Questionable but what if Canvas will not
>maintain current state of pathTransform? Instead all transformations can be
>directly applied on cairo_t using native calls. If there is a need to get
>actual matrix we can ask cairo directly. From my perspective it simplifies
>transformation stuff a little bit.
>
>  Review and optimization. I can only welcome that.

>
>- *Benefit from cairo_save and cairo_restore.* AthensCairo maintains
>state manually by setting transformation matrix and clip. Instead we could
>save and restore state without caring about clip/matrix which simplifies
>code. Check SpartaCanvas>>#clipBy:during:
>
> Sure, using backend to its full potential is again can be only welcomed.
But Cairo is not the only backend for Athens.
So, if you can expose such operation at more backend neutral level in
Athens, then it is welcome as well.
I was thinking about that, but never got my hands to it.. How to expose it
in backend-neutral way.
So, if you found how - do it. I can only welcome that.


> Cheers,
> Alex
>
> On Tue, Apr 5, 2016 at 2:12 PM, Igor Stasenko  wrote:
>
>>
>> Couple 

Re: [Pharo-dev] Pharo Days 2016 Photos and Video

[Tudor Girba]

Nice :)

Cheers,
Tudor


> On Apr 4, 2016, at 12:15 AM, Yuriy Tymchuk  wrote:
> 
> Good morning everyone!
> 
> I think that it’s a nice way to start the new week by viewing photos from 
> Pharo Days 2016: https://goo.gl/photos/orgTn4C1bSeqf6fy5.
> Additionally if someone wants to get a quick impression of the conference, 
> now there is a video for that: https://youtu.be/eHKtxgbuLSg.
> 
> 
> Have a great week.
> Cheers!
> Uko

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

"When people care, great things can happen."

Re: [Pharo-dev] [ bloc ] I do not understand why some behavior is not in the right place

[Aliaksei Syrel]

Now let's take a look at this code:

drawOnSpartaCanvas: aCanvas

> aCanvas
>   clipPreserveBy: self shape during: [
>   aCanvas paintGroup: [
> aCanvas setPaint: self shape fillPaint.
> aCanvas fillPreserve.
> aCanvas paintMode source.
> aCanvas setStrokePaint: self shape strokePaint.
> aCanvas stroke ] ]


You may be curious why it is so ugly :) Make it work - make it right - make
it fast. We are on the first etappe, because I invested zero time in
rendering stuff.

What you see is the minimal amount of cairo primitive calls that are needed
to render not overlapping fill and stroke. Clipping is needed to make sure
that stroke does not get rendered outside of a path. Group is needed to
have transparent target in order to make source paint mode work as
expected. Compared to image_surface group, it in this case allows to
preserve clip and current cairo state which is pushed to stack during
push_group and restored during pop_group_to_source. fillPreserve allows to
reuse the same path as used for clipping before saving cpu time on loading
path.

It is implemented in canvas specific method after dispatch though canvas,
so we are allowed to use canvas specific api, for example groups.

How to model stroke, fillPreserve and paintModein terms of Athens?


Cheers,
Alex

On Tue, Apr 5, 2016 at 3:15 PM, Aliaksei Syrel  wrote:

> Hello Igor
>
> Thanks for extensive design explanation and effort!
> Issues you mentioned in previous emails are important and need to be
> addressed :)
> fill(), stroke() fillPreserve() strokePreserve() need to disappear in the
> end. We will come back to them later.
>
> Let me tell a few words about Sparta.
> Sparta implements Athens interface api (excluding some experimental stuff
> to test possible performance boost in a few places) and does not have task
> to remove Athens style and abstractions. Ideally Sparta will be AthensCairo
> for bloc. I'm looking forward for your help :)
>
> Here are some aspects in AthensCairo that Sparta tries to address in first
> place:
>
>- *Clipping in local coordinates*. It is critical in Bloc. You
>implemented AthensCairo to have vector based rendering in Morphic and Pharo
>in general. Morphic lives in global coordinates, so your choice to clip in
>global coordinate is perfect! At the same time global clipping in bloc adds
>complexity. Sparta clips always in local coordinates (user space in cairo
>terminology).
>- *Clip by arbitrary path*. Athens and AthenCairo expect to see
>aRectangle as clipping region - your wise choice for morphic. In bloc I
>would have clipping by arbitrary path. clipBy:during: gets aPath.
>Rectangle/Color is polymorphic with path/paint in Sparta
>- *Support of groups*. (maybe user-level aspect? like shadows) Groups
>are powerful in cairo (do they exist outside of cairo?) and allow to draw
>both transparent fill and stroke without overlapping using only one path.
>On class side of BlElement there are examples (exampleCircle) that show
>such behavior.
>- *Do not maintain and set pathTransformation before each
>render-dependent action.* Questionable but what if Canvas will not
>maintain current state of pathTransform? Instead all transformations can be
>directly applied on cairo_t using native calls. If there is a need to get
>actual matrix we can ask cairo directly. From my perspective it simplifies
>transformation stuff a little bit.
>- *Benefit from cairo_save and cairo_restore.* AthensCairo maintains
>state manually by setting transformation matrix and clip. Instead we could
>save and restore state without caring about clip/matrix which simplifies
>code. Check SpartaCanvas>>#clipBy:during:
>
>
> Cheers,
> Alex
>
> On Tue, Apr 5, 2016 at 2:12 PM, Igor Stasenko  wrote:
>
>>
>> Couple more words about that fill() function abstraction.
>> Now you probably understand why there's no notion of stroke operation in
>> Athens.
>> Because instead of introducing it that way, by adding new kind of a
>> function
>> stroke(shape,paint)
>> from our perspective, it falls into our more generic fill() function,
>> except that
>> instead of literally filling the shape we deciding to paint a stroke:
>> fill(shape, strokePaint).
>>
>> As i said, there's nothing that tells that fill() function must affect
>> only areas enclosed by the shape.
>> For instance, you could imagine, that i'm in contrary, may want to fill
>> everything , but the area(s) enclosed by given shape. And that still can be
>> represented as invocation of our generic fill() function, except that we
>> will use a different kind of paint, that will fill everything outside
>> designated region, i.e.:
>> fill(shape, fillOutsidePaint)
>>
>>
>>
>> On 5 April 2016 at 14:33, Igor Stasenko  wrote:
>>
>>>
>>>
>>> On 5 April 2016 at 04:00, Ben Coman  wrote:
>>>
 On Tue, Apr 5, 2016 at 2:51 AM, Igor Stasenko 

Re: [Pharo-dev] [ bloc ] I do not understand why some behavior is not in the right place

[Cyril Ferlicot Delbecque]

On 05/04/2016 15:08, Igor Stasenko wrote:
> 
> 
> On 5 April 2016 at 15:58, p...@highoctane.be 
> > wrote:
> 
> Made a quick gist of of
> this: 
> https://gist.github.com/philippeback/ef4d128e953de226cf40639641f83e04
> 
> Thanks. Would be nice if someone with better English than mine skim
> trough it and fix bad language :)

This should be added in the meta data of Athens's configuration I think.
It would help people to find it.

> 
> -- 
> Best regards,
> Igor Stasenko.

-- 
Cyril Ferlicot

http://www.synectique.eu

165 Avenue Bretagne
Lille 59000 France



signature.asc
Description: OpenPGP digital signature

Re: [Pharo-dev] [ bloc ] I do not understand why some behavior is not in the right place

[Aliaksei Syrel]

Hello Igor

Thanks for extensive design explanation and effort!
Issues you mentioned in previous emails are important and need to be
addressed :)
fill(), stroke() fillPreserve() strokePreserve() need to disappear in the
end. We will come back to them later.

Let me tell a few words about Sparta.
Sparta implements Athens interface api (excluding some experimental stuff
to test possible performance boost in a few places) and does not have task
to remove Athens style and abstractions. Ideally Sparta will be AthensCairo
for bloc. I'm looking forward for your help :)

Here are some aspects in AthensCairo that Sparta tries to address in first
place:

   - *Clipping in local coordinates*. It is critical in Bloc. You
   implemented AthensCairo to have vector based rendering in Morphic and Pharo
   in general. Morphic lives in global coordinates, so your choice to clip in
   global coordinate is perfect! At the same time global clipping in bloc adds
   complexity. Sparta clips always in local coordinates (user space in cairo
   terminology).
   - *Clip by arbitrary path*. Athens and AthenCairo expect to see
   aRectangle as clipping region - your wise choice for morphic. In bloc I
   would have clipping by arbitrary path. clipBy:during: gets aPath.
   Rectangle/Color is polymorphic with path/paint in Sparta
   - *Support of groups*. (maybe user-level aspect? like shadows) Groups
   are powerful in cairo (do they exist outside of cairo?) and allow to draw
   both transparent fill and stroke without overlapping using only one path.
   On class side of BlElement there are examples (exampleCircle) that show
   such behavior.
   - *Do not maintain and set pathTransformation before each
   render-dependent action.* Questionable but what if Canvas will not
   maintain current state of pathTransform? Instead all transformations can be
   directly applied on cairo_t using native calls. If there is a need to get
   actual matrix we can ask cairo directly. From my perspective it simplifies
   transformation stuff a little bit.
   - *Benefit from cairo_save and cairo_restore.* AthensCairo maintains
   state manually by setting transformation matrix and clip. Instead we could
   save and restore state without caring about clip/matrix which simplifies
   code. Check SpartaCanvas>>#clipBy:during:


Cheers,
Alex

On Tue, Apr 5, 2016 at 2:12 PM, Igor Stasenko  wrote:

>
> Couple more words about that fill() function abstraction.
> Now you probably understand why there's no notion of stroke operation in
> Athens.
> Because instead of introducing it that way, by adding new kind of a
> function
> stroke(shape,paint)
> from our perspective, it falls into our more generic fill() function,
> except that
> instead of literally filling the shape we deciding to paint a stroke:
> fill(shape, strokePaint).
>
> As i said, there's nothing that tells that fill() function must affect
> only areas enclosed by the shape.
> For instance, you could imagine, that i'm in contrary, may want to fill
> everything , but the area(s) enclosed by given shape. And that still can be
> represented as invocation of our generic fill() function, except that we
> will use a different kind of paint, that will fill everything outside
> designated region, i.e.:
> fill(shape, fillOutsidePaint)
>
>
>
> On 5 April 2016 at 14:33, Igor Stasenko  wrote:
>
>>
>>
>> On 5 April 2016 at 04:00, Ben Coman  wrote:
>>
>>> On Tue, Apr 5, 2016 at 2:51 AM, Igor Stasenko 
>>> wrote:
>>> >
>>> > Some more bashing today.. (don't take it personal, i may be wrong)
>>> >
>>> > BlPath hierarchy.. and BlShape.
>>> >
>>> > Why you redefining what is shape and what is path?
>>> > Of course, you are free to do it in Bloc..
>>> > But in terms of Athens, all of BlPath are actually - shapes..
>>> > And BlShape is some kind of encapsulation of shape, paints and
>>> transform.
>>> > It is a dumb state holder without any extra logic.
>>> >
>>> > My rule of thumb: do not produce dumb state holders. They has to be
>>> smart,
>>> > else it makes no sense in creating separate entity and designating it
>>> as
>>> > something else than any other bunch of data thrown into single clump,
>>> > sitting there deaf, blind, dead and silent until someone else will
>>> grab it
>>> > somewhere
>>> > and start using it for own purpose.
>>> >
>>> > Sure, i could understand, why you potentially may want such object(s)
>>> > around,
>>> > but it is not shape anymore and i wouldn't call it like that. Because
>>> shape
>>> > are shape, and has nothing to do with paints and transform,
>>> > it don't knows and don't cares whether it will be filled or stroked or
>>> both,
>>> >  and how many times, and if there will be single paint or thousand.
>>> > Such kind of properties is simply orthogonal to what shape existing
>>> for,
>>> > because it exists only to define geometry.
>>> >
>>> > I think all of that came from not understanding the roles of 

Re: [Pharo-dev] [ bloc ] I do not understand why some behavior is not in the right place

[Igor Stasenko]

On 5 April 2016 at 15:58, p...@highoctane.be  wrote:

> Made a quick gist of of this:
> https://gist.github.com/philippeback/ef4d128e953de226cf40639641f83e04
>
> Thanks. Would be nice if someone with better English than mine skim trough
it and fix bad language :)



> On Tue, Apr 5, 2016 at 1:33 PM, Igor Stasenko  wrote:
>
>>
>>
>> On 5 April 2016 at 04:00, Ben Coman  wrote:
>>
>>> On Tue, Apr 5, 2016 at 2:51 AM, Igor Stasenko 
>>> wrote:
>>> >
>>> > Some more bashing today.. (don't take it personal, i may be wrong)
>>> >
>>> > BlPath hierarchy.. and BlShape.
>>> >
>>> > Why you redefining what is shape and what is path?
>>> > Of course, you are free to do it in Bloc..
>>> > But in terms of Athens, all of BlPath are actually - shapes..
>>> > And BlShape is some kind of encapsulation of shape, paints and
>>> transform.
>>> > It is a dumb state holder without any extra logic.
>>> >
>>> > My rule of thumb: do not produce dumb state holders. They has to be
>>> smart,
>>> > else it makes no sense in creating separate entity and designating it
>>> as
>>> > something else than any other bunch of data thrown into single clump,
>>> > sitting there deaf, blind, dead and silent until someone else will
>>> grab it
>>> > somewhere
>>> > and start using it for own purpose.
>>> >
>>> > Sure, i could understand, why you potentially may want such object(s)
>>> > around,
>>> > but it is not shape anymore and i wouldn't call it like that. Because
>>> shape
>>> > are shape, and has nothing to do with paints and transform,
>>> > it don't knows and don't cares whether it will be filled or stroked or
>>> both,
>>> >  and how many times, and if there will be single paint or thousand.
>>> > Such kind of properties is simply orthogonal to what shape existing
>>> for,
>>> > because it exists only to define geometry.
>>> >
>>> > I think all of that came from not understanding the roles of objects
>>> and how
>>> > they interact in Athens.
>>>
>>> Can you point us to documentation that describes Athen's architecture
>>> for these interactions?
>>> (sorry I haven't checked class comments, but I'm looking to start with
>>> something at higher level anyway)
>>>
>>
>> No, i can't point it out. And you are right , this is nobody else's fault
>> than my own. I feel ashamed. Sure how i could demand that people understand
>> the concepts, if i didn't explained then anywhere (or if i did, it is not
>> in easily reachable place).
>>
>> So, lets fix that. I will write it down here, and you can pick it up and
>> find suitable place for it.
>>
>> --
>> Basic abstractions behind Athens.
>>
>> Since Athens is about drawing graphics, we need a media where all drawing
>> operations will appear. We call that media a surface.
>> The surface is abstract. It can have set dimensions, or don't.  We don't
>> define if it representing some kind of physical surface (like part of the
>> display screen), or how it storing the data inside. We leaving an
>> introduction of such details to concrete surface implementation.
>> All that matters is that surface is a final target of all our drawing
>> operations.
>> Therefore, in Athens, a surface is usually a starting point where all
>> begins from, and you doing so by creating a specific surface.
>> It is surface's responsibility then, to provide user a means how he can
>> draw on it, and therefore there is a number of factory methods, that
>> allowing you to create a canvas, paints and shapes. All those three are
>> specific implementation of AthensCanvas, AthensPaint and AthensShape
>> protocols, suitable to be used with specific surface implementation that
>> you using.
>>
>> Canvas.
>> Canvas represents a basic drawing context. We don't allow a direct
>> operations with surface, but instead we provide a context, that contains
>> and carries all information that represents a current stage of drawing
>> operations.
>> This includes things like, current coordinate transformation(s),
>> currently selected paint and shape, and paint mode.
>>
>> In order to obtain canvas, one must use #drawDuring: message sent to
>> surface with block as argument. The given block receives an instance of
>> AthensCanvas as a single parameter. We intentionally enclosing all possible
>> drawing operations within a block to make sure that when we leave, we can
>> safely release all resources that was allocated, required to hold the
>> drawing context state. By exposing it in such form, we also making sure
>> that nothing can alter the surface outside a given block. That way, it
>> gives users a definitive answer, whether he finished drawing operations or
>> not, and if it safe to operate with surface for things like saving it to
>> file, or using it as a source for more complex operations, like acting as a
>> paint to fill area(s) inside another surface etc.
>>
>> Paints and shapes.
>> A starting point is answering a question, how we can represent a

Re: [Pharo-dev] [ bloc ] I do not understand why some behavior is not in the right place

[p...@highoctane.be]

Made a quick gist of of this:
https://gist.github.com/philippeback/ef4d128e953de226cf40639641f83e04

On Tue, Apr 5, 2016 at 1:33 PM, Igor Stasenko  wrote:

>
>
> On 5 April 2016 at 04:00, Ben Coman  wrote:
>
>> On Tue, Apr 5, 2016 at 2:51 AM, Igor Stasenko  wrote:
>> >
>> > Some more bashing today.. (don't take it personal, i may be wrong)
>> >
>> > BlPath hierarchy.. and BlShape.
>> >
>> > Why you redefining what is shape and what is path?
>> > Of course, you are free to do it in Bloc..
>> > But in terms of Athens, all of BlPath are actually - shapes..
>> > And BlShape is some kind of encapsulation of shape, paints and
>> transform.
>> > It is a dumb state holder without any extra logic.
>> >
>> > My rule of thumb: do not produce dumb state holders. They has to be
>> smart,
>> > else it makes no sense in creating separate entity and designating it as
>> > something else than any other bunch of data thrown into single clump,
>> > sitting there deaf, blind, dead and silent until someone else will grab
>> it
>> > somewhere
>> > and start using it for own purpose.
>> >
>> > Sure, i could understand, why you potentially may want such object(s)
>> > around,
>> > but it is not shape anymore and i wouldn't call it like that. Because
>> shape
>> > are shape, and has nothing to do with paints and transform,
>> > it don't knows and don't cares whether it will be filled or stroked or
>> both,
>> >  and how many times, and if there will be single paint or thousand.
>> > Such kind of properties is simply orthogonal to what shape existing for,
>> > because it exists only to define geometry.
>> >
>> > I think all of that came from not understanding the roles of objects
>> and how
>> > they interact in Athens.
>>
>> Can you point us to documentation that describes Athen's architecture
>> for these interactions?
>> (sorry I haven't checked class comments, but I'm looking to start with
>> something at higher level anyway)
>>
>
> No, i can't point it out. And you are right , this is nobody else's fault
> than my own. I feel ashamed. Sure how i could demand that people understand
> the concepts, if i didn't explained then anywhere (or if i did, it is not
> in easily reachable place).
>
> So, lets fix that. I will write it down here, and you can pick it up and
> find suitable place for it.
>
> --
> Basic abstractions behind Athens.
>
> Since Athens is about drawing graphics, we need a media where all drawing
> operations will appear. We call that media a surface.
> The surface is abstract. It can have set dimensions, or don't.  We don't
> define if it representing some kind of physical surface (like part of the
> display screen), or how it storing the data inside. We leaving an
> introduction of such details to concrete surface implementation.
> All that matters is that surface is a final target of all our drawing
> operations.
> Therefore, in Athens, a surface is usually a starting point where all
> begins from, and you doing so by creating a specific surface.
> It is surface's responsibility then, to provide user a means how he can
> draw on it, and therefore there is a number of factory methods, that
> allowing you to create a canvas, paints and shapes. All those three are
> specific implementation of AthensCanvas, AthensPaint and AthensShape
> protocols, suitable to be used with specific surface implementation that
> you using.
>
> Canvas.
> Canvas represents a basic drawing context. We don't allow a direct
> operations with surface, but instead we provide a context, that contains
> and carries all information that represents a current stage of drawing
> operations.
> This includes things like, current coordinate transformation(s), currently
> selected paint and shape, and paint mode.
>
> In order to obtain canvas, one must use #drawDuring: message sent to
> surface with block as argument. The given block receives an instance of
> AthensCanvas as a single parameter. We intentionally enclosing all possible
> drawing operations within a block to make sure that when we leave, we can
> safely release all resources that was allocated, required to hold the
> drawing context state. By exposing it in such form, we also making sure
> that nothing can alter the surface outside a given block. That way, it
> gives users a definitive answer, whether he finished drawing operations or
> not, and if it safe to operate with surface for things like saving it to
> file, or using it as a source for more complex operations, like acting as a
> paint to fill area(s) inside another surface etc.
>
> Paints and shapes.
> A starting point is answering a question, how we can represent a simplest,
> elementary drawing operation on a surface without putting too much
> constraints.
> We doing so by postulating that any elementary drawing operation can be
> expressed by a function:
>
> fill(paint, shape)
>
> Please, note that 'fill' here is not a literally fill given shape with
> 

Re: [Pharo-dev] TxText model

[Igor Stasenko]

On 5 April 2016 at 04:16, Ben Coman  wrote:

> On Mon, Apr 4, 2016 at 9:49 PM, Igor Stasenko  wrote:
> >
> >
> > On 4 April 2016 at 16:32, Thierry Goubier 
> wrote:
> >>
> >>
> >>
> >> 2016-04-04 15:23 GMT+02:00 Igor Stasenko :
> >>>
> >>>
> 
> >>> Analogies don't work. Right :) I never used Pillar and have remote
> ideas
> >>> about what it does or requires. From that perspective you appeal to
> wrong
> >>> person. On your place i would be asking a guy who knows Pillar innards
> about
> >>> it.
>
> Please see...
>
> [1]
> http://esug.org/data/ESUG2015/4%20thursday/1600-1630%20Pilar/Pillar.pdf
>
> Okay. Now i remember.
Yeah, i can easily imagine making a transformer that renders a pillar
markup text into TxText instance, by implementing an yet another exporter,
like  PRTxTextWriter.
Certain features would be impossible right now, but for simple docs i guess
it may work just fine.



> [2]
> https://ci.inria.fr/pharo-contribution/job/EnterprisePharoBook/lastSuccessfulBuild/artifact/book-result/PillarChap/Pillar.html
>
> Most (all?) of docs at [3] are done using Pillar...
> [3] https://github.com/SquareBracketAssociates
>
> cheers -ben
>
>


-- 
Best regards,
Igor Stasenko.

Re: [Pharo-dev] [ bloc ] I do not understand why some behavior is not in the right place

[Igor Stasenko]

Couple more words about that fill() function abstraction.
Now you probably understand why there's no notion of stroke operation in
Athens.
Because instead of introducing it that way, by adding new kind of a function
stroke(shape,paint)
from our perspective, it falls into our more generic fill() function,
except that
instead of literally filling the shape we deciding to paint a stroke:
fill(shape, strokePaint).

As i said, there's nothing that tells that fill() function must affect only
areas enclosed by the shape.
For instance, you could imagine, that i'm in contrary, may want to fill
everything , but the area(s) enclosed by given shape. And that still can be
represented as invocation of our generic fill() function, except that we
will use a different kind of paint, that will fill everything outside
designated region, i.e.:
fill(shape, fillOutsidePaint)



On 5 April 2016 at 14:33, Igor Stasenko  wrote:

>
>
> On 5 April 2016 at 04:00, Ben Coman  wrote:
>
>> On Tue, Apr 5, 2016 at 2:51 AM, Igor Stasenko  wrote:
>> >
>> > Some more bashing today.. (don't take it personal, i may be wrong)
>> >
>> > BlPath hierarchy.. and BlShape.
>> >
>> > Why you redefining what is shape and what is path?
>> > Of course, you are free to do it in Bloc..
>> > But in terms of Athens, all of BlPath are actually - shapes..
>> > And BlShape is some kind of encapsulation of shape, paints and
>> transform.
>> > It is a dumb state holder without any extra logic.
>> >
>> > My rule of thumb: do not produce dumb state holders. They has to be
>> smart,
>> > else it makes no sense in creating separate entity and designating it as
>> > something else than any other bunch of data thrown into single clump,
>> > sitting there deaf, blind, dead and silent until someone else will grab
>> it
>> > somewhere
>> > and start using it for own purpose.
>> >
>> > Sure, i could understand, why you potentially may want such object(s)
>> > around,
>> > but it is not shape anymore and i wouldn't call it like that. Because
>> shape
>> > are shape, and has nothing to do with paints and transform,
>> > it don't knows and don't cares whether it will be filled or stroked or
>> both,
>> >  and how many times, and if there will be single paint or thousand.
>> > Such kind of properties is simply orthogonal to what shape existing for,
>> > because it exists only to define geometry.
>> >
>> > I think all of that came from not understanding the roles of objects
>> and how
>> > they interact in Athens.
>>
>> Can you point us to documentation that describes Athen's architecture
>> for these interactions?
>> (sorry I haven't checked class comments, but I'm looking to start with
>> something at higher level anyway)
>>
>
> No, i can't point it out. And you are right , this is nobody else's fault
> than my own. I feel ashamed. Sure how i could demand that people understand
> the concepts, if i didn't explained then anywhere (or if i did, it is not
> in easily reachable place).
>
> So, lets fix that. I will write it down here, and you can pick it up and
> find suitable place for it.
>
> --
> Basic abstractions behind Athens.
>
> Since Athens is about drawing graphics, we need a media where all drawing
> operations will appear. We call that media a surface.
> The surface is abstract. It can have set dimensions, or don't.  We don't
> define if it representing some kind of physical surface (like part of the
> display screen), or how it storing the data inside. We leaving an
> introduction of such details to concrete surface implementation.
> All that matters is that surface is a final target of all our drawing
> operations.
> Therefore, in Athens, a surface is usually a starting point where all
> begins from, and you doing so by creating a specific surface.
> It is surface's responsibility then, to provide user a means how he can
> draw on it, and therefore there is a number of factory methods, that
> allowing you to create a canvas, paints and shapes. All those three are
> specific implementation of AthensCanvas, AthensPaint and AthensShape
> protocols, suitable to be used with specific surface implementation that
> you using.
>
> Canvas.
> Canvas represents a basic drawing context. We don't allow a direct
> operations with surface, but instead we provide a context, that contains
> and carries all information that represents a current stage of drawing
> operations.
> This includes things like, current coordinate transformation(s), currently
> selected paint and shape, and paint mode.
>
> In order to obtain canvas, one must use #drawDuring: message sent to
> surface with block as argument. The given block receives an instance of
> AthensCanvas as a single parameter. We intentionally enclosing all possible
> drawing operations within a block to make sure that when we leave, we can
> safely release all resources that was allocated, required to hold the
> drawing context state. By exposing it in such form, we 

Re: [Pharo-dev] [ bloc ] I do not understand why some behavior is not in the right place

[Igor Stasenko]

On 5 April 2016 at 04:00, Ben Coman  wrote:

> On Tue, Apr 5, 2016 at 2:51 AM, Igor Stasenko  wrote:
> >
> > Some more bashing today.. (don't take it personal, i may be wrong)
> >
> > BlPath hierarchy.. and BlShape.
> >
> > Why you redefining what is shape and what is path?
> > Of course, you are free to do it in Bloc..
> > But in terms of Athens, all of BlPath are actually - shapes..
> > And BlShape is some kind of encapsulation of shape, paints and transform.
> > It is a dumb state holder without any extra logic.
> >
> > My rule of thumb: do not produce dumb state holders. They has to be
> smart,
> > else it makes no sense in creating separate entity and designating it as
> > something else than any other bunch of data thrown into single clump,
> > sitting there deaf, blind, dead and silent until someone else will grab
> it
> > somewhere
> > and start using it for own purpose.
> >
> > Sure, i could understand, why you potentially may want such object(s)
> > around,
> > but it is not shape anymore and i wouldn't call it like that. Because
> shape
> > are shape, and has nothing to do with paints and transform,
> > it don't knows and don't cares whether it will be filled or stroked or
> both,
> >  and how many times, and if there will be single paint or thousand.
> > Such kind of properties is simply orthogonal to what shape existing for,
> > because it exists only to define geometry.
> >
> > I think all of that came from not understanding the roles of objects and
> how
> > they interact in Athens.
>
> Can you point us to documentation that describes Athen's architecture
> for these interactions?
> (sorry I haven't checked class comments, but I'm looking to start with
> something at higher level anyway)
>

No, i can't point it out. And you are right , this is nobody else's fault
than my own. I feel ashamed. Sure how i could demand that people understand
the concepts, if i didn't explained then anywhere (or if i did, it is not
in easily reachable place).

So, lets fix that. I will write it down here, and you can pick it up and
find suitable place for it.

--
Basic abstractions behind Athens.

Since Athens is about drawing graphics, we need a media where all drawing
operations will appear. We call that media a surface.
The surface is abstract. It can have set dimensions, or don't.  We don't
define if it representing some kind of physical surface (like part of the
display screen), or how it storing the data inside. We leaving an
introduction of such details to concrete surface implementation.
All that matters is that surface is a final target of all our drawing
operations.
Therefore, in Athens, a surface is usually a starting point where all
begins from, and you doing so by creating a specific surface.
It is surface's responsibility then, to provide user a means how he can
draw on it, and therefore there is a number of factory methods, that
allowing you to create a canvas, paints and shapes. All those three are
specific implementation of AthensCanvas, AthensPaint and AthensShape
protocols, suitable to be used with specific surface implementation that
you using.

Canvas.
Canvas represents a basic drawing context. We don't allow a direct
operations with surface, but instead we provide a context, that contains
and carries all information that represents a current stage of drawing
operations.
This includes things like, current coordinate transformation(s), currently
selected paint and shape, and paint mode.

In order to obtain canvas, one must use #drawDuring: message sent to
surface with block as argument. The given block receives an instance of
AthensCanvas as a single parameter. We intentionally enclosing all possible
drawing operations within a block to make sure that when we leave, we can
safely release all resources that was allocated, required to hold the
drawing context state. By exposing it in such form, we also making sure
that nothing can alter the surface outside a given block. That way, it
gives users a definitive answer, whether he finished drawing operations or
not, and if it safe to operate with surface for things like saving it to
file, or using it as a source for more complex operations, like acting as a
paint to fill area(s) inside another surface etc.

Paints and shapes.
A starting point is answering a question, how we can represent a simplest,
elementary drawing operation on a surface without putting too much
constraints.
We doing so by postulating that any elementary drawing operation can be
expressed by a function:

fill(paint, shape)

Please, note that 'fill' here is not a literally fill given shape with
given paint. We call it 'fill' for simplicity reason. It can anything that
altering the surface, but always taking into account given parameters:
paint and shape.

Then, from that perspective we can clearly say what are the roles and
responsibility of shapes and paints.

The shape defines the affected region, its geometry and location,

Re: [Pharo-dev] [Pharo-users] STON materialization corrupts a dictionary if the keys are references

[Sven Van Caekenberghe]

> On 05 Apr 2016, at 13:02, Nicolai Hess  wrote:
> 
> 
> 
> 2016-04-05 12:32 GMT+02:00 Cyril Ferlicot Delbecque 
> :
> 
> 
> On 05/04/2016 12:09, Sven Van Caekenberghe wrote:
> 
> > Like I said, it is a hashing issue, sometimes it will be correct by 
> > accident.
> >
> > I hope you did not have to much trouble with this bug, I guess it must have 
> > been hard to chase.
> >
> > Is it urgent ?
> >
> > I probably can give you a quick fix, but I would like to think a bit more 
> > about this, since rehashing each materialised dictionary seems expensive.
> >
> >
> >
> 
> Hi Sven,
> 
> I got the same kind of problem in a personal application.
> 
> I use Sets that I serialize and I had a lot of trouble because sometimes
> some action had strange behaviours.
> 
> For example in a set with element `aSet remove: aSet anyOne` raised 'XXX
> not found in aSet'.
> 
> I am glad to hear that it is a Ston issue and not me that used sets in a
> bad way :)
> 
> For me too it is not urgent since I have a not of university work for
> the moment.
> 
> 
> 
> How are hashed collections created/filled during ston-parsing ?
> If the position in a hashed collection is created by a ston-reference, that 
> is later replaced by the "real" object,
> the index in the dictionary  (or other hashed collections) may be wrong.

Yes, that is indeed it, Nicolai. 

But I would like to try to minimise the rehashing as it seems expensive. But 
first I need a more reliable failure.

> --
> Cyril Ferlicot
> 
> http://www.synectique.eu
> 
> 165 Avenue Bretagne
> Lille 59000 France

Re: [Pharo-dev] [Pharo-users] STON materialization corrupts a dictionary if the keys are references

[Nicolai Hess]

2016-04-05 12:32 GMT+02:00 Cyril Ferlicot Delbecque <
cyril.ferli...@gmail.com>:

>
>
> On 05/04/2016 12:09, Sven Van Caekenberghe wrote:
>
> > Like I said, it is a hashing issue, sometimes it will be correct by
> accident.
> >
> > I hope you did not have to much trouble with this bug, I guess it must
> have been hard to chase.
> >
> > Is it urgent ?
> >
> > I probably can give you a quick fix, but I would like to think a bit
> more about this, since rehashing each materialised dictionary seems
> expensive.
> >
> >
> >
>
> Hi Sven,
>
> I got the same kind of problem in a personal application.
>
> I use Sets that I serialize and I had a lot of trouble because sometimes
> some action had strange behaviours.
>
> For example in a set with element `aSet remove: aSet anyOne` raised 'XXX
> not found in aSet'.
>
> I am glad to hear that it is a Ston issue and not me that used sets in a
> bad way :)
>
> For me too it is not urgent since I have a not of university work for
> the moment.
>
>

How are hashed collections created/filled during ston-parsing ?
If the position in a hashed collection is created by a ston-reference, that
is later replaced by the "real" object,
the index in the dictionary  (or other hashed collections) may be wrong.



> --
> Cyril Ferlicot
>
> http://www.synectique.eu
>
> 165 Avenue Bretagne
> Lille 59000 France
>
>

Re: [Pharo-dev] [Pharo-users] STON materialization corrupts a dictionary if the keys are references

[Cyril Ferlicot Delbecque]

On 05/04/2016 12:09, Sven Van Caekenberghe wrote:

> Like I said, it is a hashing issue, sometimes it will be correct by accident.
> 
> I hope you did not have to much trouble with this bug, I guess it must have 
> been hard to chase.
> 
> Is it urgent ?
> 
> I probably can give you a quick fix, but I would like to think a bit more 
> about this, since rehashing each materialised dictionary seems expensive.
> 
> 
> 

Hi Sven,

I got the same kind of problem in a personal application.

I use Sets that I serialize and I had a lot of trouble because sometimes
some action had strange behaviours.

For example in a set with element `aSet remove: aSet anyOne` raised 'XXX
not found in aSet'.

I am glad to hear that it is a Ston issue and not me that used sets in a
bad way :)

For me too it is not urgent since I have a not of university work for
the moment.

-- 
Cyril Ferlicot

http://www.synectique.eu

165 Avenue Bretagne
Lille 59000 France



signature.asc
Description: OpenPGP digital signature

Re: [Pharo-dev] [Pharo-users] STON materialization corrupts a dictionary if the keys are references

[Peter Uhnák]

>
> Like I said, it is a hashing issue, sometimes it will be correct by
> accident.
>
> I hope you did not have to much trouble with this bug, I guess it must
> have been hard to chase.
>

The hardest thing often is to suspect the system or external libraries, but
it wasn't that bad.

Is it urgent ?
>

I can rehash it for now (I have a trivial case), but it should be fixed
eventually (it wouldn't be so easy to rehash more complex structures).

Thanks,
Peter

Re: [Pharo-dev] [Pharo-users] STON materialization corrupts a dictionary if the keys are references

[Sven Van Caekenberghe]

> On 05 Apr 2016, at 11:50, Peter Uhnák  wrote:
> 
> This is
> Pharo #50666
> Moose 6.0 build #1437
> STON-Core-SvenVanCaekenberghe.67
> 
>  (I also loaded STON-Core-SvenVanCaekenberghe.70 but the result is the same).
> 
> One thing to note: it doesn't fail always… for me it seems that about every 
> ten or so attempts it succeeds.

Like I said, it is a hashing issue, sometimes it will be correct by accident.

I hope you did not have to much trouble with this bug, I guess it must have 
been hard to chase.

Is it urgent ?

I probably can give you a quick fix, but I would like to think a bit more about 
this, since rehashing each materialised dictionary seems expensive.

> Peter
> 
> On Tue, Apr 5, 2016 at 11:41 AM, Sven Van Caekenberghe  wrote:
> Hi Peter,
> 
> Strange indeed. It did not fail for me in 5.0 with the standard STON version, 
> but it does fail in 4.0 with the latest STON. Asking the bogus dictionary to 
> #rehash seems to fix the problem. I will investigate and turn you example 
> into a unit test.
> 
> Sven
> 
> > On 05 Apr 2016, at 11:14, Peter Uhnák  wrote:
> >
> > Hi,
> >
> > I ran into a problem with STON that seems to corrupt on materialization.
> >
> > Consider the following script:
> >
> > ~~
> > c := OrderedCollection with: UUID new.
> > d := Dictionary with: c first -> nil.
> > o := { c . d }.
> >
> > s := STON toStringPretty: o.
> >
> > o2 := STON reader
> >   allowComplexMapKeys: true;
> >   on: s readStream;
> >   next.
> >
> > o2 second keys. "an Array(an UUID('571bbfb7-78b9-430c-9aad-3e0088a25f4c'))"
> > o2 second printString. "KeyNotFound: key an 
> > UUID(''571bbfb7-78b9-430c-9aad-3e0088a25f4c'') not found in Dictionary"
> > o2 second at: o2 second keys first. "the same error"
> > ~~
> >
> > So even though it contains the key it fails to access it.
> >
> > Interestingly enough if I serialize and materialize the "broken" dictionary 
> > again it suddenly works again.
> >
> > Thanks,
> > Peter
> >
> >
> >
> 
> 
> 

Re: [Pharo-dev] [ bloc ] I do not understand why some behavior is not in the right place

[Igor Stasenko]

On 5 April 2016 at 02:37, Aliaksei Syrel  wrote:

> About hit detection. Idea was to be completely general. And this is the
> only approach I found (still bad because uses native calls instead of
> athens-like solution) that works with text. Text is also a shape and it's
> very cool to be able to detect events inside characters. Imagine morph in
> form of huge arbitrary string.
>
Yes, that would be cool to have.


> Current solution does not render, it only sets fill paint and path, then
> uses cairo, no need to invent wheel.
> Imagine that paint is something fancy, Cairo takes Cairo about special
> cases.
>
This code was born before Cairo came to play. Mind you that Cairo is only
one of the potential backends of Athens.
It doesn't means that you cannot use feature and invent own wheel.
Don't you think i am not hating to reproduce numerical algorithms by
myself, if i would be able to use one that already available for use. But
that was not the case.
So, exposing feature via correct protocol is the way to go. Then when
backend provides such feature, one can simply use backed.. and if not -
then it will fallback to homemade numerical crunching.
And especially that code smells and need a cleanup (not your code, but code
in Athens).
All i wanna see is exposing feature in nice and consisting way. We all want
it to be there. Not just you and me, but whole community does. The rest is
a poetry.

> Cheers
> Alex
> On Apr 5, 2016 12:17 AM, "Igor Stasenko"  wrote:
>
>>
>>
>> On 5 April 2016 at 01:12, Igor Stasenko  wrote:
>>
>>>
>>>
>>> On 5 April 2016 at 00:51, Andrei Chis 
>>> wrote:
>>>
>>> btw, Andrei , if you looking how you can test if point contains shape or
>>> not, take a look at AthensCurveFlattener.
>>> It converts curved path, that containing Bezier curves (or not) into
>>> simple polygonal shape that consists only from a simple lines.
>>> Then there AthensPolygonTester, that has the piece you missing:
>>> - a small algorithm that can test if given point inside or outside that
>>> polygon.
>>>
>>> Please note that it is simpler even-odd rule algorithm. It not works
>>> correctly for all possible cases.
>>>
>>> There's another algorithm- winding number algorithm, that is much better,
>>> but i had to switch to other stuff before were able to get my hands to
>>> it.
>>> It is more reliable, since it can work for self-intersecting shapes.
>>>
>>> https://en.wikipedia.org/wiki/Point_in_polygon
>>>
>>> So, what you need is to wire these things down to Bloc.Then whenever you
>>> need to test whether point within shape or not, you can convert any path
>>> into polygon and perform the test. And of course, you can cache the results
>>> of conversion in order to avoid expensive computations every time you need
>>> to perform such tests. Once path is converted, the test is relatively cheap
>>> and costs something like O(n), where n is number of line segments.
>>>
>>> Or maybe, to simplify things, you could extend the shape protocol and
>>> introduce #containsPoint:
>>> or as variant #containsPoint:ifNotAvailable:
>>> so that if shape implements such feature - it can answer true or false,
>>> and if not - evaluating a block. So, you don't have to implement all tests
>>> for all kinds of shapes that invented or not yet invented in universe.
>>>
>>>
>> Oh, forgot to add, you can look for example how i converting path in
>> AthensBezier3Scene class.
>>
>>
>>> --
>>> Best regards,
>>> Igor Stasenko.
>>>
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko.
>>
>


-- 
Best regards,
Igor Stasenko.

Re: [Pharo-dev] [Pharo-users] STON materialization corrupts a dictionary if the keys are references

[Peter Uhnák]

This is
Pharo #50666
Moose 6.0 build #1437
STON-Core-SvenVanCaekenberghe.67

 (I also loaded STON-Core-SvenVanCaekenberghe.70 but the result is the
same).

One thing to note: it doesn't fail always… for me it seems that about every
ten or so attempts it succeeds.

Peter

On Tue, Apr 5, 2016 at 11:41 AM, Sven Van Caekenberghe  wrote:

> Hi Peter,
>
> Strange indeed. It did not fail for me in 5.0 with the standard STON
> version, but it does fail in 4.0 with the latest STON. Asking the bogus
> dictionary to #rehash seems to fix the problem. I will investigate and turn
> you example into a unit test.
>
> Sven
>
> > On 05 Apr 2016, at 11:14, Peter Uhnák  wrote:
> >
> > Hi,
> >
> > I ran into a problem with STON that seems to corrupt on materialization.
> >
> > Consider the following script:
> >
> > ~~
> > c := OrderedCollection with: UUID new.
> > d := Dictionary with: c first -> nil.
> > o := { c . d }.
> >
> > s := STON toStringPretty: o.
> >
> > o2 := STON reader
> >   allowComplexMapKeys: true;
> >   on: s readStream;
> >   next.
> >
> > o2 second keys. "an Array(an
> UUID('571bbfb7-78b9-430c-9aad-3e0088a25f4c'))"
> > o2 second printString. "KeyNotFound: key an
> UUID(''571bbfb7-78b9-430c-9aad-3e0088a25f4c'') not found in Dictionary"
> > o2 second at: o2 second keys first. "the same error"
> > ~~
> >
> > So even though it contains the key it fails to access it.
> >
> > Interestingly enough if I serialize and materialize the "broken"
> dictionary again it suddenly works again.
> >
> > Thanks,
> > Peter
> >
> >
> >
>
>
>

Re: [Pharo-dev] [ bloc ] I do not understand why some behavior is not in the right place

[Igor Stasenko]

On 5 April 2016 at 02:34, Aliaksei Syrel  wrote:

> > Seriously, brute force is synonym of dumb. If you cannot solve the
> problem
> by anything else than using brute force, then first thing you do, you
> leave an extensive comment "sorry guys, this piece stinks, but i was <...>
> unable to do any better".
>
> That is enough, Igor.
> Calling other developers or their decisions "dumb" is unacceptable! It is
> far way beyond a red line and only shows impoliteness. You are not trying
> to constructively criticize but just trolling us.
>
> Why i should be polite to bad code and bad practices?
And have you thought what i should feel , when you using 'perfect' wording
for something that not nearly close to perfect? That was insulting.

> Here are some basic rules if you want to continue discussion:
>
> 1) Before "pushing" other people to spend time on you, try to spend your
> own. Read previous posts at least in the same thread before writing an
> email. Link to bloc build was in the second email but you asked for it 2 or
> 3 messages later.
>
> 2) Don't use "pfff...",  "yadda yadda", " pony" or whatever other jargon
> in any thread related to bloc. It distracts and shows your disregard to the
> reader.
>
3) Don't judge others that they don't know or understand something. There
> are no stupid people around here.
>
> 4) Write short but informative emails. We have a lot of other stuff to do.
> Everything that you wrote can be expressed using much less amount of
> characters.
>
If you don't have time to read mails, don't read them. Just ignore. Nobody
forcing you to to read it.
I had to write long, because i need to explain what i don't like and why.
Or would it be better for you if i would review the code and just state:
- i don't like it, fix it.
Leaving you clueless what i don't like and how it should be fixed?

Will such brevity help you to fix things? Apparently not. It is quite
opposite, because them you can simply ignore it. And if i would do it like
that, this is exactly will be disregard to participants of discussion.

> 5) First ask why decision was made and only then describe cons and pros.
> There is obsolete code in multiple places left because it maybe forgotten
> or we realized that it was a mistake but accidentally committed. That
> shadow problem was a mistake and big thanks to Glenn who explained and
> fixed it in bloc a lot of month ago by using ShadowFilter which is in
> another repo for a moment.
>
> 6) When criticizing try to find and mention also positive desicions. It is
> called politeness.
>
I just want it to see it fixed. Yes, #containsX:Y: works.. but that's far
from 'perfect'.
Because right now it using a private method of Cairo, bypassing layer of
abstraction provided by Athens.
So, you need to expose feature in proper way via Athens API.. and then it
is perfect. And i didn't mentioned it, because as to me it is obvious.
You asking me to be short, but then pointing that i don't mention positive
decisions.
You can't have both, choose one.

>From your side, i don't like to see that on all that mails with many
questions, all i got in response it: 'bullshit, it is perfect'. Because it
feels like that.

If all that i wrote here is bullshit, then fine.. perfect. You don't have
to do and worry about anything.

> Thanks
> Alex
>
>
-- 
Best regards,
Igor Stasenko.

Re: [Pharo-dev] [Pharo-users] STON materialization corrupts a dictionary if the keys are references

[Sven Van Caekenberghe]

Hi Peter,

Strange indeed. It did not fail for me in 5.0 with the standard STON version, 
but it does fail in 4.0 with the latest STON. Asking the bogus dictionary to 
#rehash seems to fix the problem. I will investigate and turn you example into 
a unit test.

Sven
 
> On 05 Apr 2016, at 11:14, Peter Uhnák  wrote:
> 
> Hi,
> 
> I ran into a problem with STON that seems to corrupt on materialization.
> 
> Consider the following script:
> 
> ~~
> c := OrderedCollection with: UUID new.
> d := Dictionary with: c first -> nil.
> o := { c . d }.
> 
> s := STON toStringPretty: o.
> 
> o2 := STON reader
>   allowComplexMapKeys: true;
>   on: s readStream;
>   next.
>   
> o2 second keys. "an Array(an UUID('571bbfb7-78b9-430c-9aad-3e0088a25f4c'))"
> o2 second printString. "KeyNotFound: key an 
> UUID(''571bbfb7-78b9-430c-9aad-3e0088a25f4c'') not found in Dictionary"
> o2 second at: o2 second keys first. "the same error"
> ~~
> 
> So even though it contains the key it fails to access it.
> 
> Interestingly enough if I serialize and materialize the "broken" dictionary 
> again it suddenly works again.
> 
> Thanks,
> Peter
> 
> 
> 

[Pharo-dev] STON materialization corrupts a dictionary if the keys are references

[Peter Uhnák]

Hi,

I ran into a problem with STON that seems to corrupt on materialization.

Consider the following script:

~~
c := OrderedCollection with: UUID new.
d := Dictionary with: c first -> nil.
o := { c . d }.

s := STON toStringPretty: o.

o2 := STON reader
allowComplexMapKeys: true;
on: s readStream;
next.
o2 second keys. "an Array(an UUID('571bbfb7-78b9-430c-9aad-3e0088a25f4c'))"
o2 second printString. "KeyNotFound: key an
UUID(''571bbfb7-78b9-430c-9aad-3e0088a25f4c'') not found in Dictionary"
o2 second at: o2 second keys first. "the same error"
~~

So even though it contains the key it fails to access it.

Interestingly enough if I serialize and materialize the "broken" dictionary
again it suddenly works again.

Thanks,
Peter

Re: [Pharo-dev] [ bloc ] I do not understand why some behavior is not in the right place

[Erik Stel]

Hi Igor and others,

(Without having seen any of the code, but from experience on other
(Javascript) project, beziers might be useful. Maybe the mentioned approach
for polygon approximation is already based on beziers. Forgive me for
wasting your time in that case.)

Beziers may be a good starting point for different kinds of
tests/transformations/etc. Most shapes (should I say Paths here? ;-) can be
specified as (cubic) beziers or approximated, allowing these
tests/transforms on all shapes.

See http://pomax.github.io/bezierinfo/ for the explanation and the
Javascript-code.

Nice read for anyone interested in some maths concerning beziers.

Cheers,
Erik




--
View this message in context: 
http://forum.world.st/bloc-I-do-not-understand-why-some-behavior-is-not-in-the-right-place-tp4888273p4888331.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.