April 2016 - Pharo-dev - lists.pharo.org

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

by Sven Van Caekenberghe

> On 05 Apr 2016, at 13:02, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > 2016-04-05 12:32 GMT+02:00 Cyril Ferlicot Delbecque <cyril.ferlicot(a)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. 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

April 5, 2016

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

by Nicolai Hess

2016-04-05 12:32 GMT+02:00 Cyril Ferlicot Delbecque < cyril.ferlicot(a)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 > >

April 5, 2016

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

by 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

April 5, 2016

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