March 2017 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Voyage and duplicated entry

by Hilaire

Hi Sabine, Norbert, It is nice to have feedbacks from other Voyagers ;) Thanks about the notice regarding reset on the repository. It may have implication I should be careful about, but not in my scenario because: - I start with empty collections in the repository, for the model part, - I import in the repository a model instance. The model instance comes from a Fuel document, - When I edit an instance (a person data), then save, I got a supplementary entry in the repo. No where in this scenario I execute a reset, at least from my code. I must stress the same instance duplication occurs when I inspect an instance, edit one attribute from the inspector, then save it from the inspector with "self save" command. Hilaire Le 04/03/2017 Ã 12:21, Sabine Manaa a Ã©crit : > did you do VORepository current reset in the meantime? > > If yes, this could be the reason. If you do this, the smalltalk cache > of the objects is reset and the next time the objects are loaded again > from mongo and then they are no longer "the same" objects within > smalltalk. I had a hard time to learn this. -- Dr. Geo http://drgeo.eu

March 5, 2017

Re: [Pharo-users] Voyage and Date

by Esteban Lorenzano

yes, this is a good solution. the base of the problem is that mongo does not actually has a Date type, just DateAndTime (even if is called Date). So if you want a Date, you need to do some conversion. Esteban > On 4 Mar 2017, at 11:25, Hilaire <hilaire(a)drgeo.eu> wrote: > > Concerning this problem, one option I found is to get far away of the > Voyage/Mongo Date/DateAndTime representation/conversion and stick to > string, not really efficience, but well... > > mongoBirthday > <mongoDescription> > ^ VOToOneDescription new > attributeName: 'birthday'; > accessor: (MAPluggableAccessor > read: [:person | person birthday ifNotNil: [person birthday yyyymmdd]] > write: [:person :string |string ifNotNil: [person birthday: string > asDate]]); > yourself > > > Le 03/03/2017 Ã 21:12, Hilaire a Ã©crit : >> Not sure it is related to this: >> http://forum.world.st/Possible-bug-with-Voyage-Mongo-date-tt4735597.html > > -- > Dr. Geo > http://drgeo.eu > >

March 5, 2017

Re: [Pharo-users] Crash in Athens

by Esteban Lorenzano

> On 5 Mar 2017, at 05:00, Alexander Samoylovich <samoylovich(a)gmail.com> wrote: > > Hi Ronie, Esteban. > > Ronie's suggestion in the form Esteban presented it helped. > After implementing the fix I failed to crash my application any more. > > Will anybody be so kind to explain me what actually happens and why the fix works? > It looks so innocent. Cairo Surface is GCd if not kept while using itâ¦ then your system go BOOM :P thatâs why we need to be sure it will not be disposed before itâs time (hence we kept it in the form that needs to be displayed). Esteban > > As far as I understand we do one additional copy. > But I do not understand why it prevents from accessing beyond the memory bounds. > > Thank you, > Alex > > On Wed, Mar 1, 2017 at 8:24 AM, Igor Stasenko <siguctua(a)gmail.com <mailto:siguctua@gmail.com>> wrote: > > > On 1 March 2017 at 05:42, Alexander Samoylovich <samoylovich(a)gmail.com <mailto:samoylovich@gmail.com>> wrote: > Thanks everybody for the explanation. > > I tried to apply Igor's suggestion. I allocate an offscreen surface 1 row larger than needed > and when converting discard one row. > > The code looks more stable now. The test was up for about 30 minutes before crashing instead of 1 minute before the fix. > Is it the right code change or just a coincidence? > > > AthensCairoSurface>>asForm > > "create a form and copy an image data there" > self checkSession. > > self flush. > ^ Form extent: (self width@self height) - (0@1) depth: 32 bits: id > > > no, it isn't . This is how it supposed to be there. > But the problem is when you using surfaces for bitmaps in Cairo itself, > you're screwed since AthensCairoSurface purposedly makes it 1 row taller, > while for texture you want it to contain exact height, else you'll obviously have artifacts. :( > > So, the point is: if you creating a surface that will be used by bitblt (asForm), then you should allocate 1 extra row, > else you shouldn't.. And there's no workaround to match such behavior in single class, > since it doesn't knows what it will be used for :( > > > On Mon, Feb 27, 2017 at 2:39 PM, Stephane Ducasse <stepharo.self(a)gmail.com <mailto:stepharo.self@gmail.com>> wrote: > Tx igor I added > > https://pharo.fogbugz.com/f/cases/19764/Improve-comment-of-AthensCairoSurfa… <https://pharo.fogbugz.com/f/cases/19764/Improve-comment-of-AthensCairoSurfa…> > > On Mon, Feb 27, 2017 at 7:35 PM, Igor Stasenko <siguctua(a)gmail.com <mailto:siguctua@gmail.com>> wrote: > and i was dealing with it by adding 1 extra line to cairo surface, > but reporting 1 less to Form. Like so, bitblt still reads past the > allowed size, but it is safe, because there are unused bit(s). > > On 27 February 2017 at 20:31, Igor Stasenko <siguctua(a)gmail.com <mailto:siguctua@gmail.com>> wrote: > > > On 27 February 2017 at 12:29, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: > Hi, > > the problem wit Ronieâs fix is that (as he says) you are copying another time the surface, before passing it to the VM (who makes yet-another-copy) so this is not optimalâ¦ and you can see it when running the Tiger demo: there are a lot of pauses. > So I would prefer the other approach he suggests: > > Form subclass: #AthensCairoSurfaceForm > instanceVariableNames: 'surface' > classVariableNames: '' > package: 'Athens-Cairo' > > AthensCairoSurfaceForm>>surface > ^ surface > > AthensCairoSurfaceForm>>surface: anObject > surface := anObject > > AthensCairoSurface>>asForm > "create a form and copy an image data there" > self checkSession. > self flush. > ^ (AthensCairoSurfaceForm extent: (self width@self height) depth: 32 bits: id) > surface: self; > yourself > > that seems to work. Can you try and see? > > > Btw, remember the culprit there , that you must have extra word in trailing buffer space, > this is because bit-blt using read-ahead . Which is OK for objects located in object memory, > since there are always something past the last object (unallocated space), > but not so ok for buffers allocated by malloc (such as cairo surface bitmap), and so, > if you read even a single byte past it, you get protection fault. > > Esteban > > > On 24 Feb 2017, at 15:47, stepharong <stepharong(a)free.fr <mailto:stepharong@free.fr>> wrote: > > > > Hi alex > > > > can you try the fix of ronie and let us know if it makes roassal more stable? > > > > Stef > > > >> Dear Alexander, > >> > >> Sine the new FFI of Pharo, using Athens has become unreliable. This is a pity, but fixing this is not trivial at all (we have been trying for years). > >> > >> What exactly are you doing with Athens? > >> > >> Alexandre > >> > >> > >>> On Feb 22, 2017, at 12:55 AM, Alexander Samoylovich <samoylovich(a)gmail.com <mailto:samoylovich@gmail.com>> wrote: > >>> > >>> Hello > >>> > >>> I am writing graphic demo programs using Athens on Mac Sierra. > >>> Time by time Pharo VM crashes. Programs not using Athens work reliably. > >>> I believe the behavior is reproducible. > >>> How should I report a bug? > >>> > >>> Alex > >> > > > > > > -- > > Using Opera's mail client: http://www.opera.com/mail/ <http://www.opera.com/mail/> > > > > > > > > -- > Best regards, > Igor Stasenko. > > > > -- > Best regards, > Igor Stasenko. > > > > > > -- > Best regards, > Igor Stasenko. >

March 5, 2017

Re: [Pharo-users] Lost access in Smalltalkhub

by Esteban Lorenzano

Esteban, not Stephen. Me. Send me a private mail with the username/email you used to register. cheers, Esteban > On 5 Mar 2017, at 02:36, Juan Manuel Vallejos <juanmanuelvallejos2(a)gmail.com> wrote: > > > Thank you. What is Stephen's mail? > > Juan Manuel Vallejos > > 2017-03-04 4:17 GMT-03:00 Stephane Ducasse <stepharo.self(a)gmail.com <mailto:stepharo.self@gmail.com>>: > esteban will fix it. Contact him. > > On Fri, Mar 3, 2017 at 7:13 PM, Juan Manuel Vallejos <juanmanuelvallejos2(a)gmail.com <mailto:juanmanuelvallejos2@gmail.com>> wrote: > Hi, > > I lost access to my smalltalkhub account and wanted to ask if you know who I should contact to solve my problem. > > Regards. > > Juan Manuel Vallejos > >

March 5, 2017

Re: [Pharo-users] Voyage and Date

by Hilaire

Hi Stephan, I am maintaining such a digest, with links to the discussion on the list. I will post it once I am done with Voyage. Hilaire Le 04/03/2017 Ã 21:34, stepharong a Ã©crit : > I would love to have a digest of the problems you encountered and the > solution. > Because like that we could write a better documentation. > > I cannot because I do not face the problems (since I'm not developing > real apps for lack of time/concentration....). > -- Dr. Geo http://drgeo.eu

March 5, 2017

Re: [Pharo-users] Crash in Athens

by Alexander Samoylovich

Hi Ronie, Esteban. Ronie's suggestion in the form Esteban presented it helped. After implementing the fix I failed to crash my application any more. Will anybody be so kind to explain me what actually happens and why the fix works? It looks so innocent. As far as I understand we do one additional copy. But I do not understand why it prevents from accessing beyond the memory bounds. Thank you, Alex On Wed, Mar 1, 2017 at 8:24 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > On 1 March 2017 at 05:42, Alexander Samoylovich <samoylovich(a)gmail.com> > wrote: > >> Thanks everybody for the explanation. >> >> I tried to apply Igor's suggestion. I allocate an offscreen surface 1 row >> larger than needed >> and when converting discard one row. >> >> The code looks more stable now. The test was up for about 30 minutes >> before crashing instead of 1 minute before the fix. >> Is it the right code change or just a coincidence? >> >> >> AthensCairoSurface>>asForm >> >> >> "create a form and copy an image data there" >> >> self checkSession. >> >> self flush. >> >> ^ Form extent: (self width@self height) - (0@1) depth: 32 bits: id >> >> > no, it isn't . This is how it supposed to be there. > But the problem is when you using surfaces for bitmaps in Cairo itself, > you're screwed since AthensCairoSurface purposedly makes it 1 row taller, > while for texture you want it to contain exact height, else you'll > obviously have artifacts. :( > > So, the point is: if you creating a surface that will be used by bitblt > (asForm), then you should allocate 1 extra row, > else you shouldn't.. And there's no workaround to match such behavior in > single class, > since it doesn't knows what it will be used for :( > > >> >> On Mon, Feb 27, 2017 at 2:39 PM, Stephane Ducasse < >> stepharo.self(a)gmail.com> wrote: >> >>> Tx igor I added >>> >>> https://pharo.fogbugz.com/f/cases/19764/Improve-comment-of-A >>> thensCairoSurfaceForm >>> >>> On Mon, Feb 27, 2017 at 7:35 PM, Igor Stasenko <siguctua(a)gmail.com> >>> wrote: >>> >>>> and i was dealing with it by adding 1 extra line to cairo surface, >>>> but reporting 1 less to Form. Like so, bitblt still reads past the >>>> allowed size, but it is safe, because there are unused bit(s). >>>> >>>> On 27 February 2017 at 20:31, Igor Stasenko <siguctua(a)gmail.com> wrote: >>>> >>>>> >>>>> >>>>> On 27 February 2017 at 12:29, Esteban Lorenzano <estebanlm(a)gmail.com> >>>>> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> the problem wit Ronieâs fix is that (as he says) you are copying >>>>>> another time the surface, before passing it to the VM (who makes >>>>>> yet-another-copy) so this is not optimalâ¦ and you can see it when running >>>>>> the Tiger demo: there are a lot of pauses. >>>>>> So I would prefer the other approach he suggests: >>>>>> >>>>>> Form subclass: #AthensCairoSurfaceForm >>>>>> instanceVariableNames: 'surface' >>>>>> classVariableNames: '' >>>>>> package: 'Athens-Cairo' >>>>>> >>>>>> AthensCairoSurfaceForm>>surface >>>>>> ^ surface >>>>>> >>>>>> AthensCairoSurfaceForm>>surface: anObject >>>>>> surface := anObject >>>>>> >>>>>> AthensCairoSurface>>asForm >>>>>> "create a form and copy an image data there" >>>>>> self checkSession. >>>>>> self flush. >>>>>> ^ (AthensCairoSurfaceForm extent: (self width@self height) >>>>>> depth: 32 bits: id) >>>>>> surface: self; >>>>>> yourself >>>>>> >>>>>> that seems to work. Can you try and see? >>>>>> >>>>>> >>>>> Btw, remember the culprit there , that you must have extra word in >>>>> trailing buffer space, >>>>> this is because bit-blt using read-ahead . Which is OK for objects >>>>> located in object memory, >>>>> since there are always something past the last object (unallocated >>>>> space), >>>>> but not so ok for buffers allocated by malloc (such as cairo surface >>>>> bitmap), and so, >>>>> if you read even a single byte past it, you get protection fault. >>>>> >>>>> >>>>>> Esteban >>>>>> >>>>>> > On 24 Feb 2017, at 15:47, stepharong <stepharong(a)free.fr> wrote: >>>>>> > >>>>>> > Hi alex >>>>>> > >>>>>> > can you try the fix of ronie and let us know if it makes roassal >>>>>> more stable? >>>>>> > >>>>>> > Stef >>>>>> > >>>>>> >> Dear Alexander, >>>>>> >> >>>>>> >> Sine the new FFI of Pharo, using Athens has become unreliable. >>>>>> This is a pity, but fixing this is not trivial at all (we have been trying >>>>>> for years). >>>>>> >> >>>>>> >> What exactly are you doing with Athens? >>>>>> >> >>>>>> >> Alexandre >>>>>> >> >>>>>> >> >>>>>> >>> On Feb 22, 2017, at 12:55 AM, Alexander Samoylovich < >>>>>> samoylovich(a)gmail.com> wrote: >>>>>> >>> >>>>>> >>> Hello >>>>>> >>> >>>>>> >>> I am writing graphic demo programs using Athens on Mac Sierra. >>>>>> >>> Time by time Pharo VM crashes. Programs not using Athens work >>>>>> reliably. >>>>>> >>> I believe the behavior is reproducible. >>>>>> >>> How should I report a bug? >>>>>> >>> >>>>>> >>> Alex >>>>>> >> >>>>>> > >>>>>> > >>>>>> > -- >>>>>> > Using Opera's mail client: http://www.opera.com/mail/ >>>>>> > >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Best regards, >>>>> Igor Stasenko. >>>>> >>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko. >>>> >>> >>> >> > > > -- > Best regards, > Igor Stasenko. >

March 5, 2017

Re: [Pharo-users] why is concat of Symbols a string?

by Igor Stasenko

Hmm.. symbols is usually treated like immutable object(s) in system. They tend to stay while rest of data changes.. This could explain why authors of this method purposedly picked to use ByteString for its species to discourage using symbols for collection manipulation(s).. Else, if you would need to change this method as well: at: anInteger put: anObject "You cannot modify the receiver." self errorNoModification because base class #, implementation is going to use at:put: during concatenation. On 4 March 2017 at 13:40, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > Hi, > > All symbols are interned in the Symbol table. If one does (#foo , #bar , > #baz) and each returned value would be a symbol, then both #foobar and > #foobarbaz would be registered in the symbol table. > > I would guess that's why the concatenated value is a string and not a > symbol, to avoid registering many unused symbols. But maybe I am wrong. > > If for your use case you need to concatenate symbols and get a symbol out > of it, you can define a new method in Symbol to do what you want. > > For example: > > Symbol >> ,, arg > ^ (self , arg) asSymbol > > Then > > #foo ,, #bar > > Answers directly the symbol #foobar. > > Best, > > > > > On Sat, Mar 4, 2017 at 11:36 AM, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > >> Hi, >> >> why is the concatenation of symbols a string? >> >> e.g. #desc, #Name -> 'descName' >> >> this means that I have to always wrap in parentheses and recast, or >> stream it, e.g. >> >> (#desc, #Name) asSymbol -> #descName >> Symbol streamContents: [ :s | s << #desc; << #Name ] -> #descName >> >> both of which introduce extraneous syntactical clutter. >> The technical reason seems to be ByteSymbol>>#species returning >> ByteString, but I have no idea why it has to be this complicated. >> >> Thanks, >> Peter >> >> > -- Best regards, Igor Stasenko.

March 5, 2017

Re: [Pharo-users] Lost access in Smalltalkhub

by Juan Manuel Vallejos

Thank you. What is Stephen's mail? Juan Manuel Vallejos 2017-03-04 4:17 GMT-03:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > esteban will fix it. Contact him. > > On Fri, Mar 3, 2017 at 7:13 PM, Juan Manuel Vallejos < > juanmanuelvallejos2(a)gmail.com> wrote: > >> Hi, >> >> I lost access to my smalltalkhub account and wanted to ask if you know >> who I should contact to solve my problem. >> >> Regards. >> >> Juan Manuel Vallejos >> > >

March 5, 2017

Re: [Pharo-users] [Modeling with Pharo] How to model a simple human interaction.

by Paul DeBruicker

This may be overkill for your use but would love to have an MIT licensed set of classes that allow for/enable something like this: https://medium.com/assist/theres-a-dozen-ways-to-order-a-coffee-why-do-dumb… sergio ruiz wrote > Hey all.. > > I got my first paying gig that i am able to use pharo with, and i am on > the last leg before calling it complete. > > Hereâs what I need to do.. > > This application accepts SMS text messages. It allows the user to send > images via MMS and place an order to a print house for those images.. Â it > then compiles the order, and submits it to the order processing system and > makes the prints. > > The last thing I need to zero in on is handling the interaction. Believe > it or not, I have never modeled such an interaction. The interaction goes: > > - user sends images{s) > - bot says âthanksâ and asks if there are more > - user types âdoneâ or sends more > - on âdoneâ bot asks for print size > - bot says âthanksâ and the interaction is done. order is processed. > > my first inclination is to use a state machine, progressing through order > each time the user enters âdoneâ..Â > > does this sound reasonable, or is there a better model/design pattern for > this interaction? > > Thanks! > > > ---- > peace, > sergio > photographer, journalist, visionary > > Public Key:Â http://bit.ly/29z9fG0 > #BitMessageÂ BM-NBaswViL21xqgg9STRJjaJaUoyiNe2dV > http://www.Village-Buzz.com > http://www.ThoseOptimizeGuys.com > http://www.coffee-black.com > http://www.painlessfrugality.com > http://www.twitter.com/sergio_101 > http://www.facebook.com/sergio101 > > signature.asc (852 bytes) > <http://forum.world.st/attachment/4937293/0/signature.asc> -- View this message in context: http://forum.world.st/Modeling-with-Pharo-How-to-model-a-simple-human-inter… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

March 4, 2017

Re: [Pharo-users] Voyage and Date

by stepharong

I would love to have a digest of the problems you encountered and the solution. Because like that we could write a better documentation. I cannot because I do not face the problems (since I'm not developing real apps for lack of time/concentration....). Stef On Sat, 04 Mar 2017 12:15:39 +0100, Sabine Manaa <manaa.sabine(a)gmail.com> wrote: > Hi Hilaire, > > it is interesting to see your posts and having similar topics as me when > starting to use voyage. > I ended up with saving ZTimestamps. But I will think about storing > strings too, because this is more readable when having direct look into > mongo. > There was a discussion in slack a few days ago (February, 21st) about > saving Dates in voyage. > > RegardsSabine > > > > 2017-03-04 11:21 GMT+01:00 HilaireFernandes [via Smalltalk] <[hidden > email]>: >> Concerning this problem, one option I found is to get far away of the >> Voyage/Mongo Date/DateAndTime representation/conversion and stick to >> string, not really efficience, but well... >> mongoBirthday<mongoDescription>^ VOToOneDescription new >> attributeName: 'birthday'; accessor: (MAPluggableAccessor >> read: [:person | person birthday ifNotNil: [person >> birthday yyyymmdd]] write: [:person :string |string >> ifNotNil: [person birthday: stringasDate]]); yourself >> >> Le 03/03/2017 Ã 21:12, Hilaire a Ã©crit : >>> Not sure it is related to this: >>> http://forum.world.st/Possible-bug-with-Voyage-Mongo-date-tt4735597.html >> >> --Dr. Geohttp://drgeo.eu >> >> >> http://drgeo.eu >> >>>> If you reply to this email, your message will be added to the >>>> discussion below: >> http://forum.world.st/Voyage-and-Date-tp4937235p4937262.htmlTo start a >> new topic under Pharo Smalltalk Users, email [hidden email]To >> unsubscribe from Pharo Smalltalk Users, click here. >> NAML > > > View this message in context: Re: Voyage and Date > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. -- Using Opera's mail client: http://www.opera.com/mail/

March 4, 2017