- Pharo-dev - lists.pharo.org

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

by 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

April 5, 2016

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

by Sven Van Caekenberghe

> On 05 Apr 2016, at 11:50, Peter UhnÃ¡k <i.uhnak(a)gmail.com> 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 <sven(a)stfx.eu> 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 <i.uhnak(a)gmail.com> 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 > > > > > > > > >

April 5, 2016

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

by Igor Stasenko

On 5 April 2016 at 02:37, Aliaksei Syrel <alex.syrel(a)gmail.com> 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" <siguctua(a)gmail.com> wrote: > >> >> >> On 5 April 2016 at 01:12, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >>> >>> >>> On 5 April 2016 at 00:51, Andrei Chis <chisvasileandrei(a)gmail.com> >>> 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.

April 5, 2016

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

by 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 <sven(a)stfx.eu> 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 <i.uhnak(a)gmail.com> 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 > > > > > > > > >

April 5, 2016

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

by Igor Stasenko

On 5 April 2016 at 02:34, Aliaksei Syrel <alex.syrel(a)gmail.com> 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.

April 5, 2016

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

by 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 <i.uhnak(a)gmail.com> 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 > > >

April 5, 2016

STON materialization corrupts a dictionary if the keys are references

by 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

April 5, 2016

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

by 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-… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

April 5, 2016

Re: [Pharo-dev] TxText model

by Ben Coman

On Mon, Apr 4, 2016 at 9:49 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > On 4 April 2016 at 16:32, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: >> >> >> >> 2016-04-04 15:23 GMT+02:00 Igor Stasenko <siguctua(a)gmail.com>: >>> >>> >>>> >>> 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 [2] https://ci.inria.fr/pharo-contribution/job/EnterprisePharoBook/lastSuccessf… Most (all?) of docs at [3] are done using Pillar... [3] https://github.com/SquareBracketAssociates cheers -ben

April 5, 2016

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

by Ben Coman

On Tue, Apr 5, 2016 at 2:51 AM, Igor Stasenko <siguctua(a)gmail.com> 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) cheers -ben

April 5, 2016