- Pharo-users - lists.pharo.org

Re: [Pharo-users] Best Practices for Bundling Documentation

by Evan Donahue

Hello, The projects are a logic programming and machine learning system respectively, so they probably warrant more involved tutorial-style documentation. I will take a look at the Pillar docs, but just to think ahead a bit, assuming I write up some docs in Pillar, what would be the best way to distribute those? Can they be packaged with the code or would the docs be outside the image? If outside, where do people tend to host them? Thanks, Evan -- View this message in context: http://forum.world.st/Best-Practices-for-Bundling-Documentation-tp4958788p4… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Aug. 5, 2017

Re: [Pharo-users] Glorp: `session login` fails for Garage SQLite

by Herby VojÄÃk

Guillermo Polito wrote: > AFAIR, PharoDatabaseAccessor was meant to work with SqueakDBX/DBXTalk > driver. No other driver should use it. At the time Garage did not even > exist. > > So I'd say that you should not use PharoDatabaseAccessor with another > driver than the one it was originally mean to? I do not know exactly > your setup, I was not following this thread. > > Really I cannot tell much more. This was really long time ago. Great to know! I am not using it consciously, though. System somehow selects it and uses it in the background (I just do MyDescriptorSystem sessionForLogin: myLoginObject; and before that I set GarageGlorpDrive to be the default). This seems to be the actual fix (make Glorp with Garage not use PharoDatabaseAccessor). Herby > > On Sun, Aug 6, 2017 at 12:20 AM, Herby VojÄÃk <herby(a)mailbox.sk > <mailto:herby@mailbox.sk>> wrote: > > Esteban A. Maringolo wrote: > > Herby, > > I regularly use `session login`, but I don't use SQLite in > Pharo, but I > do in VisualWorks and it works just fine. > Maybe if there is a bug we should fix it. Even with a no-op method. > > Regards! > > Esteban A. Maringolo > > > It's hard. The problem is > > PharoDatabaseAccessor >> encoding > ^self connection queryEncoding > > which overrides parent, which is atm: > > encoding > "The connection is specific to the dialect; some dialects will need > to override this method." > > ^connection encoding > > The former was added at GuillermoPolito.73 back in 2011 (and the > latter was the same back then). It probably fixed something, but I > don't see any implementors of queryEncoding atm (definitely not in > Garage). From the diff it is clear lots of databases and drivers > have gone. Now, why was it change for Pharo (and does it need to be > changed in 2017)? > > Ccing Guillermo Polito. > > Herby > > P.S.: I wonder how it is that no one actually had problem with this? > This predictably fails on `session login` on pharo, unless > queryEncoding is somehow magically present without seeing it in > source code for other platforms? > > > 2017-08-05 15:52 GMT-03:00 Herby VojÄÃk <herby(a)mailbox.sk > <mailto:herby@mailbox.sk> > <mailto:herby@mailbox.sk <mailto:herby@mailbox.sk>>>: > > Alistair Grant wrote: > > Hi Herby, > > On 5 August 2017 at 18:09, Herby > VojÄÃk<herby(a)mailbox.sk <mailto:herby@mailbox.sk> > <mailto:herby@mailbox.sk <mailto:herby@mailbox.sk>>> wrote: > > Hello! > > First of all, what is preferred way to (first time) > login > into database? I > had the impression that `aDatabaseAccessor login` > is sorta > low-level, and > one should do `session login` (after all, it is > session you > get to work > with, not an accessor). > > But with Garage SQLite, `session login`, when > accessor is > not logged, always > fails with "MessageNotUnderstood: > GASqlite3Driver>>queryEncoding". > > Should one not use `session login` at all, then (when > accessor is logged, it > just does nothing, if it isn't, it connects the > accessor, > but tries to do > some additional work which always fails)? > > Herby > > > From memory this is caused by differences between > VisualWorks > and Pharo. > > Anyway, it is discussed and resolved in: > > http://forum.world.st/Glorp-SQLite3-issue-td4899792.html > <http://forum.world.st/Glorp-SQLite3-issue-td4899792.html> > <http://forum.world.st/Glorp-SQLite3-issue-td4899792.html > <http://forum.world.st/Glorp-SQLite3-issue-td4899792.html>> > > > Doesn't look like solved to me. Anyway, at least I know it > is known > for year and no-one seemed to see it as a bug. > > I think it is one (you cannot just send queryEncoding where > no class > implements it and be fine, imo). > > So what is the state of `session login`? Is it meant to be > used, or > everyone just took a step down to low-level and uses `accessor > login` instead? :-( > > > Cheers, > Alistair > > > Thanks, Herby > > > > > > > -- > > > > Guille Polito > > > Research Engineer > > French National Center for Scientific Research - _http://www.cnrs.fr_ > > > > *Web:* _http://guillep.github.io_ > > *Phone: *+33 06 52 70 66 13 >

Aug. 5, 2017

Re: [Pharo-users] Glorp: `session login` fails for Garage SQLite

by Herby VojÄÃk

Esteban A. Maringolo wrote: > Which version of Pharo, Glorp and SQLite are you using? As for SQLite dll, I don't know (does it change the fact if queryEncoding method is present?). Pharo is 6.1, Glorp, Garage etc. are #stable loaded from Pharo60 catalog (see attachment). Herby > > > Esteban A. Maringolo > > > 2017-08-05 19:20 GMT-03:00 Herby VojÄÃk<herby(a)mailbox.sk>: >> Esteban A. Maringolo wrote: >>> Herby, >>> >>> I regularly use `session login`, but I don't use SQLite in Pharo, but I >>> do in VisualWorks and it works just fine. >>> Maybe if there is a bug we should fix it. Even with a no-op method. >>> >>> Regards! >>> >>> Esteban A. Maringolo >> >> It's hard. The problem is >> >> PharoDatabaseAccessor>> encoding >> ^self connection queryEncoding >> >> which overrides parent, which is atm: >> >> encoding >> "The connection is specific to the dialect; some dialects will need >> to override this method." >> >> ^connection encoding >> >> The former was added at GuillermoPolito.73 back in 2011 (and the latter was >> the same back then). It probably fixed something, but I don't see any >> implementors of queryEncoding atm (definitely not in Garage). From the diff >> it is clear lots of databases and drivers have gone. Now, why was it change >> for Pharo (and does it need to be changed in 2017)? >> >> Ccing Guillermo Polito. >> >> Herby >> >> P.S.: I wonder how it is that no one actually had problem with this? This >> predictably fails on `session login` on pharo, unless queryEncoding is >> somehow magically present without seeing it in source code for other >> platforms? >> >>> 2017-08-05 15:52 GMT-03:00 Herby VojÄÃk<herby(a)mailbox.sk >>> <mailto:herby@mailbox.sk>>: >>> >>> Alistair Grant wrote: >>> >>> Hi Herby, >>> >>> On 5 August 2017 at 18:09, Herby VojÄÃk<herby(a)mailbox.sk >>> <mailto:herby@mailbox.sk>> wrote: >>> >>> Hello! >>> >>> First of all, what is preferred way to (first time) login >>> into database? I >>> had the impression that `aDatabaseAccessor login` is sorta >>> low-level, and >>> one should do `session login` (after all, it is session you >>> get to work >>> with, not an accessor). >>> >>> But with Garage SQLite, `session login`, when accessor is >>> not logged, always >>> fails with "MessageNotUnderstood: >>> GASqlite3Driver>>queryEncoding". >>> >>> Should one not use `session login` at all, then (when >>> accessor is logged, it >>> just does nothing, if it isn't, it connects the accessor, >>> but tries to do >>> some additional work which always fails)? >>> >>> Herby >>> >>> >>> From memory this is caused by differences between VisualWorks >>> and Pharo. >>> >>> Anyway, it is discussed and resolved in: >>> >>> http://forum.world.st/Glorp-SQLite3-issue-td4899792.html >>> <http://forum.world.st/Glorp-SQLite3-issue-td4899792.html> >>> >>> >>> Doesn't look like solved to me. Anyway, at least I know it is known >>> for year and no-one seemed to see it as a bug. >>> >>> I think it is one (you cannot just send queryEncoding where no class >>> implements it and be fine, imo). >>> >>> So what is the state of `session login`? Is it meant to be used, or >>> everyone just took a step down to low-level and uses `accessor >>> login` instead? :-( >>> >>> >>> Cheers, >>> Alistair >>> >>> >>> Thanks, Herby >>> >>> >> >

Aug. 5, 2017

Re: [Pharo-users] Glorp: `session login` fails for Garage SQLite

by Guillermo Polito

AFAIR, PharoDatabaseAccessor was meant to work with SqueakDBX/DBXTalk driver. No other driver should use it. At the time Garage did not even exist. So I'd say that you should not use PharoDatabaseAccessor with another driver than the one it was originally mean to? I do not know exactly your setup, I was not following this thread. Really I cannot tell much more. This was really long time ago. On Sun, Aug 6, 2017 at 12:20 AM, Herby VojÄÃk <herby(a)mailbox.sk> wrote: > Esteban A. Maringolo wrote: > >> Herby, >> >> I regularly use `session login`, but I don't use SQLite in Pharo, but I >> do in VisualWorks and it works just fine. >> Maybe if there is a bug we should fix it. Even with a no-op method. >> >> Regards! >> >> Esteban A. Maringolo >> > > It's hard. The problem is > > PharoDatabaseAccessor >> encoding > ^self connection queryEncoding > > which overrides parent, which is atm: > > encoding > "The connection is specific to the dialect; some dialects will > need to override this method." > > ^connection encoding > > The former was added at GuillermoPolito.73 back in 2011 (and the latter > was the same back then). It probably fixed something, but I don't see any > implementors of queryEncoding atm (definitely not in Garage). From the diff > it is clear lots of databases and drivers have gone. Now, why was it change > for Pharo (and does it need to be changed in 2017)? > > Ccing Guillermo Polito. > > Herby > > P.S.: I wonder how it is that no one actually had problem with this? This > predictably fails on `session login` on pharo, unless queryEncoding is > somehow magically present without seeing it in source code for other > platforms? > > >> 2017-08-05 15:52 GMT-03:00 Herby VojÄÃk <herby(a)mailbox.sk >> <mailto:herby@mailbox.sk>>: >> >> Alistair Grant wrote: >> >> Hi Herby, >> >> On 5 August 2017 at 18:09, Herby VojÄÃk<herby(a)mailbox.sk >> <mailto:herby@mailbox.sk>> wrote: >> >> Hello! >> >> First of all, what is preferred way to (first time) login >> into database? I >> had the impression that `aDatabaseAccessor login` is sorta >> low-level, and >> one should do `session login` (after all, it is session you >> get to work >> with, not an accessor). >> >> But with Garage SQLite, `session login`, when accessor is >> not logged, always >> fails with "MessageNotUnderstood: >> GASqlite3Driver>>queryEncoding". >> >> Should one not use `session login` at all, then (when >> accessor is logged, it >> just does nothing, if it isn't, it connects the accessor, >> but tries to do >> some additional work which always fails)? >> >> Herby >> >> >> From memory this is caused by differences between VisualWorks >> and Pharo. >> >> Anyway, it is discussed and resolved in: >> >> http://forum.world.st/Glorp-SQLite3-issue-td4899792.html >> <http://forum.world.st/Glorp-SQLite3-issue-td4899792.html> >> >> >> Doesn't look like solved to me. Anyway, at least I know it is known >> for year and no-one seemed to see it as a bug. >> >> I think it is one (you cannot just send queryEncoding where no class >> implements it and be fine, imo). >> >> So what is the state of `session login`? Is it meant to be used, or >> everyone just took a step down to low-level and uses `accessor >> login` instead? :-( >> >> >> Cheers, >> Alistair >> >> >> Thanks, Herby >> >> >> > -- Guille Polito Research Engineer French National Center for Scientific Research - *http://www.cnrs.fr* <http://www.cnrs.fr> *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Aug. 5, 2017

Re: [Pharo-users] Glorp: `session login` fails for Garage SQLite

by Esteban A. Maringolo

Which version of Pharo, Glorp and SQLite are you using? Esteban A. Maringolo 2017-08-05 19:20 GMT-03:00 Herby VojÄÃk <herby(a)mailbox.sk>: > Esteban A. Maringolo wrote: >> >> Herby, >> >> I regularly use `session login`, but I don't use SQLite in Pharo, but I >> do in VisualWorks and it works just fine. >> Maybe if there is a bug we should fix it. Even with a no-op method. >> >> Regards! >> >> Esteban A. Maringolo > > > It's hard. The problem is > > PharoDatabaseAccessor >> encoding > ^self connection queryEncoding > > which overrides parent, which is atm: > > encoding > "The connection is specific to the dialect; some dialects will need > to override this method." > > ^connection encoding > > The former was added at GuillermoPolito.73 back in 2011 (and the latter was > the same back then). It probably fixed something, but I don't see any > implementors of queryEncoding atm (definitely not in Garage). From the diff > it is clear lots of databases and drivers have gone. Now, why was it change > for Pharo (and does it need to be changed in 2017)? > > Ccing Guillermo Polito. > > Herby > > P.S.: I wonder how it is that no one actually had problem with this? This > predictably fails on `session login` on pharo, unless queryEncoding is > somehow magically present without seeing it in source code for other > platforms? > >> >> 2017-08-05 15:52 GMT-03:00 Herby VojÄÃk <herby(a)mailbox.sk >> <mailto:herby@mailbox.sk>>: >> >> Alistair Grant wrote: >> >> Hi Herby, >> >> On 5 August 2017 at 18:09, Herby VojÄÃk<herby(a)mailbox.sk >> <mailto:herby@mailbox.sk>> wrote: >> >> Hello! >> >> First of all, what is preferred way to (first time) login >> into database? I >> had the impression that `aDatabaseAccessor login` is sorta >> low-level, and >> one should do `session login` (after all, it is session you >> get to work >> with, not an accessor). >> >> But with Garage SQLite, `session login`, when accessor is >> not logged, always >> fails with "MessageNotUnderstood: >> GASqlite3Driver>>queryEncoding". >> >> Should one not use `session login` at all, then (when >> accessor is logged, it >> just does nothing, if it isn't, it connects the accessor, >> but tries to do >> some additional work which always fails)? >> >> Herby >> >> >> From memory this is caused by differences between VisualWorks >> and Pharo. >> >> Anyway, it is discussed and resolved in: >> >> http://forum.world.st/Glorp-SQLite3-issue-td4899792.html >> <http://forum.world.st/Glorp-SQLite3-issue-td4899792.html> >> >> >> Doesn't look like solved to me. Anyway, at least I know it is known >> for year and no-one seemed to see it as a bug. >> >> I think it is one (you cannot just send queryEncoding where no class >> implements it and be fine, imo). >> >> So what is the state of `session login`? Is it meant to be used, or >> everyone just took a step down to low-level and uses `accessor >> login` instead? :-( >> >> >> Cheers, >> Alistair >> >> >> Thanks, Herby >> >> > >

Aug. 5, 2017

Re: [Pharo-users] Lazy-initialization patterns

by Esteban A. Maringolo

2017-08-05 19:21 GMT-03:00 Peter Uhnak <i.uhnak(a)gmail.com>: > If I want to initialize the value in a separate method (typically for testing or reuse), then I prefer to avoid state mutation there and instead I return the result. > > MyClass>>#property > ^ property ifNil: [ property := self createNewProperty ] > > MyClass>>createNewProperty > "I won't touch property instance variable here, just create a new value and return it" > ^ self bar collect: [ :e | e drink ] > > > > an initializationMethod returning the value instead of the receiver is a code smell to me. > > For this reason I tend to name such methods createNewX, initializeX says to me "only mutate state and return self" I like this approach very much, it makes the accessor code concise and separates the implementation of the property creation. Thank you! Esteban A. Maringolo

Aug. 5, 2017

Re: [Pharo-users] Lazy-initialization patterns

by Esteban A. Maringolo

I know the compiler is smart enough in most cases, and even if it isn't, an extra send or two won't hurt me in the kind of computation I do. But it's the style what "worried" me the most. Let's use the first then :) Esteban A. Maringolo 2017-08-05 19:18 GMT-03:00 Paul DeBruicker <pdebruic(a)gmail.com>: > Seems like either way would have unmeasurable performance impact for your > application vs the other and you should go for whats most > legible/comprehensible. > > > On that metric I prefer the first but #yolo > > > > > > > > Esteban A. Maringolo wrote > > Hi there, > > > > I have a question about lazy initialization accessor methods that always > > keep me thinking in terms of performance and style. > > > > For years I did something like: > > > > MyClass>>#property > > property isNil ifTrue: [ self initializeProperty ]. "It could be ifNil: > > as well" > > ^property > > > > MyClass>>#initializeProperty > > "Returns the receiver, not the property." > > property := self foo collect: [:e | ... ]. > > > > > > But this made me think that maybe I'm performing extra operations, so I > > started doing something like: > > > > MyClass>>#property > > ^property ifNil: [ self initializeProperty ] > > > > MyClass>>#initializeProperty > > ^property := self foo collect: [:e | ... ] > > > > The initialize method is often created by an "Extract Method" refactoring > > I > > do in the accesor, where I do the initial implementation. > > > > > > The messages makes me think that the second implementation is "faster", > > but > > an initializationMethod returning the value instead of the receiver is a > > code smell to me. > > > > I early initialize everything I know will be be used right away, but for > > cases it doesn't make sense. > > > > > > What do you think/prefer? Why? > > > > Maybe we could use the reified variables (slots) to implement the lazy > > initialization themselves :) > > > > > > Best regards! > > > > Esteban A. Maringolo > > > > > > -- > View this message in context: http://forum.world.st/Lazy- > initialization-patterns-tp4958897p4958901.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

Aug. 5, 2017

Re: [Pharo-users] Lazy-initialization patterns

by Peter Uhnak

Personally I prever to avoid long lazy initializations, so I have it nice and tidy in a single method. MyClass>>#property ^ property ifNil: [ property := self bar collect: #food ] If I want to initialize the value in a separate method (typically for testing or reuse), then I prefer to avoid state mutation there and instead I return the result. MyClass>>#property ^ property ifNil: [ property := self createNewProperty ] MyClass>>createNewProperty "I won't touch property instance variable here, just create a new value and return it" ^ self bar collect: [ :e | e drink ] > an initializationMethod returning the value instead of the receiver is a code smell to me. For this reason I tend to name such methods createNewX, initializeX says to me "only mutate state and return self" Peter

Aug. 5, 2017

Re: [Pharo-users] Glorp: `session login` fails for Garage SQLite

by Herby VojÄÃk

Esteban A. Maringolo wrote: > Herby, > > I regularly use `session login`, but I don't use SQLite in Pharo, but I > do in VisualWorks and it works just fine. > Maybe if there is a bug we should fix it. Even with a no-op method. > > Regards! > > Esteban A. Maringolo It's hard. The problem is PharoDatabaseAccessor >> encoding ^self connection queryEncoding which overrides parent, which is atm: encoding "The connection is specific to the dialect; some dialects will need to override this method." ^connection encoding The former was added at GuillermoPolito.73 back in 2011 (and the latter was the same back then). It probably fixed something, but I don't see any implementors of queryEncoding atm (definitely not in Garage). From the diff it is clear lots of databases and drivers have gone. Now, why was it change for Pharo (and does it need to be changed in 2017)? Ccing Guillermo Polito. Herby P.S.: I wonder how it is that no one actually had problem with this? This predictably fails on `session login` on pharo, unless queryEncoding is somehow magically present without seeing it in source code for other platforms? > > 2017-08-05 15:52 GMT-03:00 Herby VojÄÃk <herby(a)mailbox.sk > <mailto:herby@mailbox.sk>>: > > Alistair Grant wrote: > > Hi Herby, > > On 5 August 2017 at 18:09, Herby VojÄÃk<herby(a)mailbox.sk > <mailto:herby@mailbox.sk>> wrote: > > Hello! > > First of all, what is preferred way to (first time) login > into database? I > had the impression that `aDatabaseAccessor login` is sorta > low-level, and > one should do `session login` (after all, it is session you > get to work > with, not an accessor). > > But with Garage SQLite, `session login`, when accessor is > not logged, always > fails with "MessageNotUnderstood: > GASqlite3Driver>>queryEncoding". > > Should one not use `session login` at all, then (when > accessor is logged, it > just does nothing, if it isn't, it connects the accessor, > but tries to do > some additional work which always fails)? > > Herby > > > From memory this is caused by differences between VisualWorks > and Pharo. > > Anyway, it is discussed and resolved in: > > http://forum.world.st/Glorp-SQLite3-issue-td4899792.html > <http://forum.world.st/Glorp-SQLite3-issue-td4899792.html> > > > Doesn't look like solved to me. Anyway, at least I know it is known > for year and no-one seemed to see it as a bug. > > I think it is one (you cannot just send queryEncoding where no class > implements it and be fine, imo). > > So what is the state of `session login`? Is it meant to be used, or > everyone just took a step down to low-level and uses `accessor > login` instead? :-( > > > Cheers, > Alistair > > > Thanks, Herby > >

Aug. 5, 2017

Re: [Pharo-users] Lazy-initialization patterns

by Paul DeBruicker

Seems like either way would have unmeasurable performance impact for your application vs the other and you should go for whats most legible/comprehensible. On that metric I prefer the first but #yolo Esteban A. Maringolo wrote > Hi there, > > I have a question about lazy initialization accessor methods that always > keep me thinking in terms of performance and style. > > For years I did something like: > > MyClass>>#property > property isNil ifTrue: [ self initializeProperty ]. "It could be ifNil: > as well" > ^property > > MyClass>>#initializeProperty > "Returns the receiver, not the property." > property := self foo collect: [:e | ... ]. > > > But this made me think that maybe I'm performing extra operations, so I > started doing something like: > > MyClass>>#property > ^property ifNil: [ self initializeProperty ] > > MyClass>>#initializeProperty > ^property := self foo collect: [:e | ... ] > > The initialize method is often created by an "Extract Method" refactoring > I > do in the accesor, where I do the initial implementation. > > > The messages makes me think that the second implementation is "faster", > but > an initializationMethod returning the value instead of the receiver is a > code smell to me. > > I early initialize everything I know will be be used right away, but for > cases it doesn't make sense. > > > What do you think/prefer? Why? > > Maybe we could use the reified variables (slots) to implement the lazy > initialization themselves :) > > > Best regards! > > Esteban A. Maringolo -- View this message in context: http://forum.world.st/Lazy-initialization-patterns-tp4958897p4958901.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Aug. 5, 2017