July 2018 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Pharo 6 Freetype plugin stopped working after Windows update

by Ben Coman

Seems similar... http://forum.world.st/Win10-Launcher-Pharo7-1122-ZdcPluginMissing-SSL-TLS-p… cheers -ben On 13 July 2018 at 03:09, webwarrior <reg(a)webwarrior.ws> wrote: > LoadLibrary(FT2Plugin.dll) (998: Invalid access to memory location. > > ) > > Windows 10. > > Win32 built on May 31 2017 03:09:04 GMT Compiler: 5.4.0 > VMMaker versionString VM: 201705310241 > > Tried latest stable VM - same error. > > Pharo 7 works normally. > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >

July 12, 2018

Re: [Pharo-users] XML support for pharo

by oswall arguedas

Solved To access the values of the nodes is as follows: yearmem: = (tree xpath: '// year') first contentString asNumber. I also edit the other methods of the XMLNode class. Thanks Oswall ________________________________ De: Pharo-users <pharo-users-bounces(a)lists.pharo.org> en nombre de PBKResearch <peter(a)pbkresearch.co.uk> Enviado: jueves, 12 de julio de 2018 12:09:20 Para: 'Any question about pharo is welcome' Asunto: Re: [Pharo-users] XML support for pharo Hi Oswall Well, you have located the correct node, which is some kind of XMLNode, so all you need is to access its content. If you browse the class and look at its âaccessingâ protocol, you see the method XMLNode>>#contentString, which will give you, in your test case, â2014â as a string. If you want to enter it in the database as a number, asNumber will do thatâ HTH Peter Kenny From: Pharo-users <pharo-users-bounces(a)lists.pharo.org> On Behalf Of oswall arguedas Sent: 12 July 2018 18:35 To: 'Any question about pharo is welcome' <pharo-users(a)lists.pharo.org> Subject: Re: [Pharo-users] XML support for pharo Hello Peter, Thanks for your help. The value I get is: <year> 2014 </ year> What I need is to extract the atomic value of the node, which is: 2014 To assign it to variables and create objects. I can not find how to obtain that punctual value 2014. The main purpose is to read many xml files and create smalltak objects with that data, then save them in DB and process the data. ________________________________ De: Pharo-users <pharo-users-bounces(a)lists.pharo.org<mailto:pharo-users-bounces@lists.pharo.org>> en nombre de PBKResearch <peter(a)pbkresearch.co.uk<mailto:peter@pbkresearch.co.uk>> Enviado: jueves, 12 de julio de 2018 11:17:41 Para: 'Any question about pharo is welcome' Asunto: Re: [Pharo-users] XML support for pharo Hi Oswall What sort of failure did you get? It helps with this sort of thing to execute the code in a playground and inspect the result. One thing you need to know is that the result of xpath is almost always some sort of XMLCollection, even when there is only one element. I would expect the result you want if you write yearmem := (tree xpath: âcardset/card/yearâ) first. Note that you should not need a slash at the start; xpath starts searching in the children of the top node. Also you do not need to give every step of the hierarchy; you can always skip levels provided the result specifies a unique route to the node you want. So in this case you can write: yearmem := (tree xpath: â//yearâ) first. Hope this helps Peter Kenny From: Pharo-users <pharo-users-bounces(a)lists.pharo.org<mailto:pharo-users-bounces@lists.pharo.org>> On Behalf Of oswall arguedas Sent: 12 July 2018 17:09 To: pharo-users(a)lists.pharo.org<mailto:pharo-users@lists.pharo.org> Subject: Re: [Pharo-users] XML support for pharo Regards, I practice with the example of the book. I can not read the atomic values of the nodes. For example, with this piece of the example: <cardset> <card> <cardname lang = "en"> Arcane Lighthouse </ cardname> <types> Land </ types> <year> 2014 </ year> To get the atomic value of the node year and assign it to the variable yearmem, I do it like this: yearmem: = tree xpath: '/ cardset / card / year'. But it fails. How do I get the 2014 value? Thank you Oswall ________________________________ De: Pharo-users <pharo-users-bounces(a)lists.pharo.org<mailto:pharo-users-bounces@lists.pharo.org>> en nombre de oswall arguedas <oswallcr(a)hotmail.com<mailto:oswallcr@hotmail.com>> Enviado: miÃ©rcoles, 11 de julio de 2018 20:17:55 Para: pharo-users(a)lists.pharo.org<mailto:pharo-users@lists.pharo.org> Asunto: Re: [Pharo-users] XML support for pharo Thanks Franz and Monty. I'm working on it, everything is going very well. The feedback when I master it. Oswall ________________________________ De: Pharo-users <pharo-users-bounces(a)lists.pharo.org<mailto:pharo-users-bounces@lists.pharo.org>> en nombre de monty <monty2(a)programmer.net<mailto:monty2@programmer.net>> Enviado: miÃ©rcoles, 11 de julio de 2018 03:32 Para: pharo-users(a)lists.pharo.org<mailto:pharo-users@lists.pharo.org> Asunto: Re: [Pharo-users] XML support for pharo This is the latest version of the XML/XPath Scraping Booklet: <https://files.pharo.org/books-pdfs/booklet-Scraping/2018-01-07-scrapingbook…> Scraping HTML with XPath - files.pharo.org<https://files.pharo.org/books-pdfs/booklet-Scraping/2018-01-07-scrapingbook…> files.pharo.org 1.6 Alargeexample â¢ Siblings.Siblingsarechildnodesthathavethesameparent.Thecard-name,types,year,rarity,expansionandcardtextelementsareallsib- ___ montyos.wordpress.com

July 12, 2018

Pharo 6 Freetype plugin stopped working after Windows update

by webwarrior

LoadLibrary(FT2Plugin.dll) (998: Invalid access to memory location. ) Windows 10. Win32 built on May 31 2017 03:09:04 GMT Compiler: 5.4.0 VMMaker versionString VM: 201705310241 Tried latest stable VM - same error. Pharo 7 works normally. -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

July 12, 2018

Re: [Pharo-users] Request for Windows test

by HernÃ¡n Morales Durand

Running Windows 8.1 here. Success, no problem at all. Impressive work BTW! Cheers, HernÃ¡n 2018-07-11 7:19 GMT-03:00 Hilaire <hilaire(a)drgeo.eu>: > Hi, > > A Windows user reported to me difficulty to start Dr. Geo. > > Although I had success to run it in a Windows system, I will be glad if > some of you would mind testing it on their windows system, and report to > me success or failure along the used Windows system. > > -> http://www.drgeo.eu/download > > Thanks a lot > > Hilaire > > -- > Dr. Geo > http://drgeo.eu > > >

July 12, 2018

Re: [Pharo-users] XML support for pharo

by PBKResearch

Hi Oswall Well, you have located the correct node, which is some kind of XMLNode, so all you need is to access its content. If you browse the class and look at its ÂaccessingÂ protocol, you see the method XMLNode>>#contentString, which will give you, in your test case, Â2014Â as a string. If you want to enter it in the database as a number, asNumber will do thatÂ HTH Peter Kenny From: Pharo-users <pharo-users-bounces(a)lists.pharo.org> On Behalf Of oswall arguedas Sent: 12 July 2018 18:35 To: 'Any question about pharo is welcome' <pharo-users(a)lists.pharo.org> Subject: Re: [Pharo-users] XML support for pharo Hello Peter, Thanks for your help. The value I get is: <year> 2014 </ year> What I need is to extract the atomic value of the node, which is: 2014 To assign it to variables and create objects. I can not find how to obtain that punctual value 2014. The main purpose is to read many xml files and create smalltak objects with that data, then save them in DB and process the data. _____ De: Pharo-users <pharo-users-bounces(a)lists.pharo.org <mailto:pharo-users-bounces@lists.pharo.org> > en nombre de PBKResearch <peter(a)pbkresearch.co.uk <mailto:peter@pbkresearch.co.uk> > Enviado: jueves, 12 de julio de 2018 11:17:41 Para: 'Any question about pharo is welcome' Asunto: Re: [Pharo-users] XML support for pharo Hi Oswall What sort of failure did you get? It helps with this sort of thing to execute the code in a playground and inspect the result. One thing you need to know is that the result of xpath is almost always some sort of XMLCollection, even when there is only one element. I would expect the result you want if you write yearmem := (tree xpath: Âcardset/card/yearÂ) first. Note that you should not need a slash at the start; xpath starts searching in the children of the top node. Also you do not need to give every step of the hierarchy; you can always skip levels provided the result specifies a unique route to the node you want. So in this case you can write: yearmem := (tree xpath: Â//yearÂ) first. Hope this helps Peter Kenny From: Pharo-users <pharo-users-bounces(a)lists.pharo.org <mailto:pharo-users-bounces@lists.pharo.org> > On Behalf Of oswall arguedas Sent: 12 July 2018 17:09 To: pharo-users(a)lists.pharo.org <mailto:pharo-users@lists.pharo.org> Subject: Re: [Pharo-users] XML support for pharo Regards, I practice with the example of the book. I can not read the atomic values of the nodes. For example, with this piece of the example: <cardset> <card> <cardname lang = "en"> Arcane Lighthouse </ cardname> <types> Land </ types> <year> 2014 </ year> To get the atomic value of the node year and assign it to the variable yearmem, I do it like this: yearmem: = tree xpath: '/ cardset / card / year'. But it fails. How do I get the 2014 value? Thank you Oswall _____ De: Pharo-users <pharo-users-bounces(a)lists.pharo.org <mailto:pharo-users-bounces@lists.pharo.org> > en nombre de oswall arguedas <oswallcr(a)hotmail.com <mailto:oswallcr@hotmail.com> > Enviado: miÃ©rcoles, 11 de julio de 2018 20:17:55 Para: pharo-users(a)lists.pharo.org <mailto:pharo-users@lists.pharo.org> Asunto: Re: [Pharo-users] XML support for pharo Thanks Franz and Monty. I'm working on it, everything is going very well. The feedback when I master it. Oswall _____ De: Pharo-users <pharo-users-bounces(a)lists.pharo.org <mailto:pharo-users-bounces@lists.pharo.org> > en nombre de monty <monty2(a)programmer.net <mailto:monty2@programmer.net> > Enviado: miÃ©rcoles, 11 de julio de 2018 03:32 Para: pharo-users(a)lists.pharo.org <mailto:pharo-users@lists.pharo.org> Asunto: Re: [Pharo-users] XML support for pharo This is the latest version of the XML/XPath Scraping Booklet: <https://files.pharo.org/books-pdfs/booklet-Scraping/2018-01-07-scrapingbook .pdf> <https://files.pharo.org/books-pdfs/booklet-Scraping/2018-01-07-scrapingbook .pdf> Scraping HTML with XPath - files.pharo.org files.pharo.org 1.6 Alargeexample Â Siblings.Siblingsarechildnodesthathavethesameparent.Thecard-name,types,year, rarity,expansionandcardtextelementsareallsib- ___ montyos.wordpress.com

July 12, 2018

Re: [Pharo-users] XML support for pharo

by oswall arguedas

Hello Peter, Thanks for your help. The value I get is: <year> 2014 </ year> What I need is to extract the atomic value of the node, which is: 2014 To assign it to variables and create objects. I can not find how to obtain that punctual value 2014. The main purpose is to read many xml files and create smalltak objects with that data, then save them in DB and process the data. ________________________________ De: Pharo-users <pharo-users-bounces(a)lists.pharo.org> en nombre de PBKResearch <peter(a)pbkresearch.co.uk> Enviado: jueves, 12 de julio de 2018 11:17:41 Para: 'Any question about pharo is welcome' Asunto: Re: [Pharo-users] XML support for pharo Hi Oswall What sort of failure did you get? It helps with this sort of thing to execute the code in a playground and inspect the result. One thing you need to know is that the result of xpath is almost always some sort of XMLCollection, even when there is only one element. I would expect the result you want if you write yearmem := (tree xpath: âcardset/card/yearâ) first. Note that you should not need a slash at the start; xpath starts searching in the children of the top node. Also you do not need to give every step of the hierarchy; you can always skip levels provided the result specifies a unique route to the node you want. So in this case you can write: yearmem := (tree xpath: â//yearâ) first. Hope this helps Peter Kenny From: Pharo-users <pharo-users-bounces(a)lists.pharo.org> On Behalf Of oswall arguedas Sent: 12 July 2018 17:09 To: pharo-users(a)lists.pharo.org Subject: Re: [Pharo-users] XML support for pharo Regards, I practice with the example of the book. I can not read the atomic values of the nodes. For example, with this piece of the example: <cardset> <card> <cardname lang = "en"> Arcane Lighthouse </ cardname> <types> Land </ types> <year> 2014 </ year> To get the atomic value of the node year and assign it to the variable yearmem, I do it like this: yearmem: = tree xpath: '/ cardset / card / year'. But it fails. How do I get the 2014 value? Thank you Oswall ________________________________ De: Pharo-users <pharo-users-bounces(a)lists.pharo.org<mailto:pharo-users-bounces@lists.pharo.org>> en nombre de oswall arguedas <oswallcr(a)hotmail.com<mailto:oswallcr@hotmail.com>> Enviado: miÃ©rcoles, 11 de julio de 2018 20:17:55 Para: pharo-users(a)lists.pharo.org<mailto:pharo-users@lists.pharo.org> Asunto: Re: [Pharo-users] XML support for pharo Thanks Franz and Monty. I'm working on it, everything is going very well. The feedback when I master it. Oswall ________________________________ De: Pharo-users <pharo-users-bounces(a)lists.pharo.org<mailto:pharo-users-bounces@lists.pharo.org>> en nombre de monty <monty2(a)programmer.net<mailto:monty2@programmer.net>> Enviado: miÃ©rcoles, 11 de julio de 2018 03:32 Para: pharo-users(a)lists.pharo.org<mailto:pharo-users@lists.pharo.org> Asunto: Re: [Pharo-users] XML support for pharo This is the latest version of the XML/XPath Scraping Booklet: <https://files.pharo.org/books-pdfs/booklet-Scraping/2018-01-07-scrapingbook…> Scraping HTML with XPath - files.pharo.org<https://files.pharo.org/books-pdfs/booklet-Scraping/2018-01-07-scrapingbook…> files.pharo.org 1.6 Alargeexample â¢ Siblings.Siblingsarechildnodesthathavethesameparent.Thecard-name,types,year,rarity,expansionandcardtextelementsareallsib- ___ montyos.wordpress.com

July 12, 2018

Re: [Pharo-users] XML support for pharo

by PBKResearch

Hi Oswall What sort of failure did you get? It helps with this sort of thing to execute the code in a playground and inspect the result. One thing you need to know is that the result of xpath is almost always some sort of XMLCollection, even when there is only one element. I would expect the result you want if you write yearmem := (tree xpath: Âcardset/card/yearÂ) first. Note that you should not need a slash at the start; xpath starts searching in the children of the top node. Also you do not need to give every step of the hierarchy; you can always skip levels provided the result specifies a unique route to the node you want. So in this case you can write: yearmem := (tree xpath: Â//yearÂ) first. Hope this helps Peter Kenny From: Pharo-users <pharo-users-bounces(a)lists.pharo.org> On Behalf Of oswall arguedas Sent: 12 July 2018 17:09 To: pharo-users(a)lists.pharo.org Subject: Re: [Pharo-users] XML support for pharo Regards, I practice with the example of the book. I can not read the atomic values of the nodes. For example, with this piece of the example: <cardset> <card> <cardname lang = "en"> Arcane Lighthouse </ cardname> <types> Land </ types> <year> 2014 </ year> To get the atomic value of the node year and assign it to the variable yearmem, I do it like this: yearmem: = tree xpath: '/ cardset / card / year'. But it fails. How do I get the 2014 value? Thank you Oswall _____ De: Pharo-users <pharo-users-bounces(a)lists.pharo.org <mailto:pharo-users-bounces@lists.pharo.org> > en nombre de oswall arguedas <oswallcr(a)hotmail.com <mailto:oswallcr@hotmail.com> > Enviado: miÃ©rcoles, 11 de julio de 2018 20:17:55 Para: pharo-users(a)lists.pharo.org <mailto:pharo-users@lists.pharo.org> Asunto: Re: [Pharo-users] XML support for pharo Thanks Franz and Monty. I'm working on it, everything is going very well. The feedback when I master it. Oswall _____ De: Pharo-users <pharo-users-bounces(a)lists.pharo.org <mailto:pharo-users-bounces@lists.pharo.org> > en nombre de monty <monty2(a)programmer.net <mailto:monty2@programmer.net> > Enviado: miÃ©rcoles, 11 de julio de 2018 03:32 Para: pharo-users(a)lists.pharo.org <mailto:pharo-users@lists.pharo.org> Asunto: Re: [Pharo-users] XML support for pharo This is the latest version of the XML/XPath Scraping Booklet: <https://files.pharo.org/books-pdfs/booklet-Scraping/2018-01-07-scrapingbook .pdf> <https://files.pharo.org/books-pdfs/booklet-Scraping/2018-01-07-scrapingbook .pdf> Scraping HTML with XPath - files.pharo.org files.pharo.org 1.6 Alargeexample Â Siblings.Siblingsarechildnodesthathavethesameparent.Thecard-name,types,year, rarity,expansionandcardtextelementsareallsib- ___ montyos.wordpress.com

July 12, 2018

Re: [Pharo-users] XML support for pharo

by oswall arguedas

Regards, I practice with the example of the book. I can not read the atomic values of the nodes. For example, with this piece of the example: <cardset> <card> <cardname lang = "en"> Arcane Lighthouse </ cardname> <types> Land </ types> <year> 2014 </ year> To get the atomic value of the node year and assign it to the variable yearmem, I do it like this: yearmem: = tree xpath: '/ cardset / card / year'. But it fails. How do I get the 2014 value? Thank you Oswall ________________________________ De: Pharo-users <pharo-users-bounces(a)lists.pharo.org> en nombre de oswall arguedas <oswallcr(a)hotmail.com> Enviado: miÃ©rcoles, 11 de julio de 2018 20:17:55 Para: pharo-users(a)lists.pharo.org Asunto: Re: [Pharo-users] XML support for pharo Thanks Franz and Monty. I'm working on it, everything is going very well. The feedback when I master it. Oswall ________________________________ De: Pharo-users <pharo-users-bounces(a)lists.pharo.org> en nombre de monty <monty2(a)programmer.net> Enviado: miÃ©rcoles, 11 de julio de 2018 03:32 Para: pharo-users(a)lists.pharo.org Asunto: Re: [Pharo-users] XML support for pharo This is the latest version of the XML/XPath Scraping Booklet: <https://files.pharo.org/books-pdfs/booklet-Scraping/2018-01-07-scrapingbook…> Scraping HTML with XPath - files.pharo.org<https://files.pharo.org/books-pdfs/booklet-Scraping/2018-01-07-scrapingbook…> files.pharo.org 1.6 Alargeexample â¢ Siblings.Siblingsarechildnodesthathavethesameparent.Thecard-name,types,year,rarity,expansionandcardtextelementsareallsib- ___ montyos.wordpress.com

July 12, 2018

Pharo TechTalk at 5pm (UTC+2)

by Serge Stinckwich

I will start my techtalk at 5pm (UTC+2) about Pharo&Tensorflow: https://association.pharo.org/event-2973748 on Youtube live: https://www.youtube.com/channel/UCtelfhEzvzvsNjXrGesm2fA Questions on Discord, channel #techtalk: http://discord.gg/Sj2rhxn Thank you. -- Serge Stinckwich UMI UMMISCO 209 (SU/IRD/UY1) "Programs must be written for people to read, and only incidentally for machines to execute."http://www.doesnotunderstand.org/

July 12, 2018

Re: [Pharo-users] Naming parameters - conventions?

by Esteban A. Maringolo

On 11/07/2018 21:21, Sean P. DeNigris wrote: > Paul DeBruicker wrote >> It also seems like a "how much milk do you like in your coffee?" choice >> where the tradeoffs between one vs the other isn't high and the code in >> action will let you know whether you've got it right. > > +1. I also use both. My heuristic is for shorter methods, and methods with > one argument, I tend to lean toward fullNameString and when I need to > differentiate multiple arguments or reference the arg way down in a method > (probably a good sign to refactor) I lean the other way. But I think Paul > said it best that it's probably more a personal style/aesthetic choice than > anything worth spending a lot of energy on. +1 to both. Although a in method like: #setFirstName:lastName: I usually use firstNameString and lastNameString respectively, mostly to not clash with instance variables firstName and lastName. Another criteria is to never name a parameter as aSomething if Something isn't a class (and of course the class of the passed argument). The same applies to #asSomething. And _never_ use anObject as name, unless it really can hold any class of object. -- Esteban A. Maringolo

July 12, 2018

Re: [Pharo-users] Naming parameters - conventions?

by Tim Mackinnon

Having refreshed my memory by rereading that section of the style book - I see the source of my discomfort... I donât find the guidelines on parameters very strong - and I think (like others) I side more with guideline 25 most of the time where itâs sensible (not just for multiple similar parameters). Thus my preference seems to be for semantic typed naming eg: fullNameString, sourceCollection, ageNumber (this one feels weird though), indexingInteger Iâm still a little unsure by using a/an as a prefix when doing semantic typed naming - I think the style book is suggesting that prefix is for typed names (exclusively?). I think the risk of collision with inst var names is low (and guideline 9 and itâs introduction seem to favour semantic naming for inst vars anyway) but I do recall once seeing someone use a prefix âmyâ on all inst vars. That was kind of cute, and seemed to read ok - and sort of encouraged you to add the setter/getter (without my) when needed. But maybe safer to avoid that convention Iâm guessing? Tim Sent from my iPhone > On 12 Jul 2018, at 12:27, Tim Mackinnon <tim(a)testit.works> wrote: > > Sounds like what Iâve been doing is what others do too - I just wasnât sure if my memory had served me well. It was great to be reminded about some of the subtleties though - hadnât thought about a/an stopping inst var collisions. > > I actually have an original copy of that style book, I was working at OTI at the time and knew Suzanne and Dave and we were all given a copy (probably worth a quick skim again) > > Thanks everyone > > Tim > > Sent from my iPhone > >> On 12 Jul 2018, at 11:09, Erik Stel <erik.stel(a)gmail.com> wrote: >> >> In the day, I learned from Smalltalk with Style: >> http://sdmeta.gforge.inria.fr/FreeBooks/WithStyle/SmalltalkWithStyle.pdf >> >> On PDF-page 13 naming starts. On PDF-page 29 parameter names are explained >> (but refers back to typed names for example). Naming ends at PDF-page 35. So >> quite elaborate explanation of naming ;-). >> >> In practice I also mix typed names (aCollection), semantic names (addresses) >> and a combination (anAddressCollection). I prefer the combination except for >> trivial situations or when the (class and) method name provide(s) enough >> context (name: aString). This later might in itself be less trivial if the >> context get broader than class and method (name). >> >> @Tim, the book might be useful for more than just naming since it covers >> quite some ground. >> >> >> >> >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > >

July 12, 2018

Re: [Pharo-users] Naming parameters - conventions?

by Tim Mackinnon

Sounds like what Iâve been doing is what others do too - I just wasnât sure if my memory had served me well. It was great to be reminded about some of the subtleties though - hadnât thought about a/an stopping inst var collisions. I actually have an original copy of that style book, I was working at OTI at the time and knew Suzanne and Dave and we were all given a copy (probably worth a quick skim again) Thanks everyone Tim Sent from my iPhone > On 12 Jul 2018, at 11:09, Erik Stel <erik.stel(a)gmail.com> wrote: > > In the day, I learned from Smalltalk with Style: > http://sdmeta.gforge.inria.fr/FreeBooks/WithStyle/SmalltalkWithStyle.pdf > > On PDF-page 13 naming starts. On PDF-page 29 parameter names are explained > (but refers back to typed names for example). Naming ends at PDF-page 35. So > quite elaborate explanation of naming ;-). > > In practice I also mix typed names (aCollection), semantic names (addresses) > and a combination (anAddressCollection). I prefer the combination except for > trivial situations or when the (class and) method name provide(s) enough > context (name: aString). This later might in itself be less trivial if the > context get broader than class and method (name). > > @Tim, the book might be useful for more than just naming since it covers > quite some ground. > > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >

July 12, 2018

Re: [Pharo-users] Naming parameters - conventions?

by Erik Stel

In the day, I learned from Smalltalk with Style: http://sdmeta.gforge.inria.fr/FreeBooks/WithStyle/SmalltalkWithStyle.pdf On PDF-page 13 naming starts. On PDF-page 29 parameter names are explained (but refers back to typed names for example). Naming ends at PDF-page 35. So quite elaborate explanation of naming ;-). In practice I also mix typed names (aCollection), semantic names (addresses) and a combination (anAddressCollection). I prefer the combination except for trivial situations or when the (class and) method name provide(s) enough context (name: aString). This later might in itself be less trivial if the context get broader than class and method (name). @Tim, the book might be useful for more than just naming since it covers quite some ground. -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

July 12, 2018

Re: [Pharo-users] Request for Windows test

by Jan BlizniÄenko

Hi Windows 10 1803 64bit: Running via DrGeo.bat, Pharo itself starts (I have SmartScreen disabled), but when opened I receive multiple errors in (gray) info messages and I do not see a way to use you app (if there should be any opened GUI or world menu items). 2018-07-12.png <http://forum.world.st/file/t369698/2018-07-12.png> Jan -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

July 12, 2018

Re: [Pharo-users] Request for Windows test

by Christophe Demarey

I also had the problem with PharoLauncher. OS X and now Windows expect to have signed applications else they do not trust it. If Dr Geo is signed with a proper certificate, it should solve the issue. > Le 11 juil. 2018 Ã 17:05, Ben Coman <btc(a)openinworld.com> a Ã©crit : > > On 11 July 2018 at 18:19, Hilaire <hilaire(a)drgeo.eu> wrote: >> Hi, >> >> A Windows user reported to me difficulty to start Dr. Geo. >> >> Although I had success to run it in a Windows system, I will be glad if >> some of you would mind testing it on their windows system, and report to >> me success or failure along the used Windows system. > > On Windows 10... > when I doubleclick "DrGeo.bat" I get a message... > Windows protected your PC. Windows Defender SmartScreen prevented an > unrecognised app from starting. Running this app might put your PC at risk. > > and after clicking "More Info" > Application: DrGeo.bat > Publisher: Unknown publisher > > and I could click "Run anyway" > after which DrGeo opened fine, and I could "Open a sketch" > "Examples", etc... > > cheers -ben >

July 12, 2018

Re: [Pharo-users] Naming parameters - conventions?

by monty

The primary trade-off is between Type Suggesting vs. Role Suggesting parameter names. For example, aString and aSymbol tell us only what type of object the parameter expects, while aName and aTitle tell us the *role* (or purpose) of the parameter, with the expected type hopefully obvious. You can combine the two, like aNameString, or aTitleSymbol, and this should be done where necessary to prevent confusion. For example, in XMLParser I have a URI class, XMLURI, and to avoid confusion over parameters that accept both XMLURIs and URI strings, I use anXMLURIOrURIString. Using "a" and "an" prefixes is always a good idea, because it prevents collisions with instance variables, allows you to tell at a glance that an identifier is a parameter and not an inst var, and it produces more natural, readable message signatures, like "copyFrom: anOldPath to: aNewPath". > Sent: Wednesday, July 11, 2018 at 6:24 PM > From: "Tim Mackinnon" <tim(a)testit.works> > To: "Pharo Users Newsgroup" <pharo-users(a)lists.pharo.org> > Subject: [Pharo-users] Naming parameters - conventions? > > Hi everyone, something Iâve meant to ask over the years, as Iâve seen lots of variation and was taught something else in the day... > > What is the suggested way of naming parameters? > > I was taught {âaâ/âanâ}DataType, so it would be: > > #name: aString > > Which works ok (although falls apart if you refactor as the tools donât interpret it - although I guess could be improved to do so) > > However often I find myself wanting to communicate a bit better as in: > > #name: fullNameString > > Which isnât strictly a datatype (and I tend to leave out the a/an when I do this). But it feels a bit off piste and it does make me consider whether my selector is named badly and should be: > > #fullName: aString > > Which takes me back to the convention I learned long ago. > > This said however, we often need to match similar #on:do, #in: generic selector names and then itâs not always obvious the intent of parameter. > > Any thoughts to share? > > I ask because for exercism, we should try and set a good example. > > Tim > > Sent from my iPhone > > ___ montyos.wordpress.com

July 12, 2018

Re: [Pharo-users] Naming parameters - conventions?

by john pfersich

+100 /ââââââââââââââââââââ/ Encrypted email at jgpfersich(a)protonmail.com Web: www.objectnets.net and www.objectnets.org > On Jul 11, 2018, at 18:20, Richard Sargent <richard.sargent(a)gemtalksystems.com> wrote: > > Tim Mackinnon wrote >> Hi everyone, something Iâve meant to ask over the years, as Iâve seen lots >> of variation and was taught something else in the day... >> >> What is the suggested way of naming parameters? >> >> I was taught {âaâ/âanâ}DataType, so it would be: >> >> #name: aString >> >> Which works ok (although falls apart if you refactor as the tools donât >> interpret it - although I guess could be improved to do so) >> >> However often I find myself wanting to communicate a bit better as in: >> >> #name: fullNameString >> >> Which isnât strictly a datatype (and I tend to leave out the a/an when I >> do this). But it feels a bit off piste and it does make me consider >> whether my selector is named badly and should be: >> >> #fullName: aString >> >> Which takes me back to the convention I learned long ago. >> >> This said however, we often need to match similar #on:do, #in: generic >> selector names and then itâs not always obvious the intent of parameter. >> >> Any thoughts to share? > > In my opinion, worth what you pay for it, the goal is to communicate and set > the reader's expectations. You want the reader to know what kind of > behaviours the argument should provide. > > So, when creating a setter method, it is sufficient to name the argument > "aString". The method selector is telling you the purpose of the string. The > argument is telling you that it is no more and no less than a string. It > isn't trying to convey that there is a structure to that string. Just that > the name is a string. > > Likewise, when naming a parameter for a more complex method you may need to > say more, depending on what the selector itself says. > e.g. #blahBlahBlahWithName: can easily work with "aString". > > Conversely, a method that takes multiple string arguments needs to > effectively distinguish them from each other. > e.g. #blahBlahBlahWithName:address:telephone: needs to do better than Dr. > Seuss (aString1, aString2, etc.) In this example, I tend to use e.g. > "nameString", "addressString", and "telephoneString". This conveys the > purpose of each argument and identifies the behaviours one should expect. > > I am *not* a fan of argument names like "aNameString", since that can > mislead readers into expecting name-specific behaviours from the argument. > > > >> I ask because for exercism, we should try and set a good example. >> >> Tim >> >> Sent from my iPhone > > > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >

July 12, 2018

Re: [Pharo-users] Naming parameters - conventions?

by Tim Mackinnon

This payer/payee example is exactly what I was thinking about, and Iâve tended to do as Dennis suggests and use a type suffix on the name - and wondered if that was what most people do. Iâll certainly check what Andreas says on the topic. Tim Sent from my iPhone On 12 Jul 2018, at 06:31, Dennis Schetinin <chaetal(a)gmail.com> wrote: >> It depends on the current level of abstraction. If you are operating at a much higher level, say transfering >> money between two accounts, you would do: >> >> #transferMoney from: aPayer to: aPayee >> >> where both aPayer and aPayee could be anAccountHolder > Why not > > #transferMoney from: payerAccountHolder to: payeeAccountHolder > > ? > > And how does the naming depend on level of abstraction? > > Practically, when a (potential) user of the method is going to invoke it, one of the first questions will be 'what kind of object I can/should pass there?'. With the classic Smalltalk convention it is quite obvious (though, the convention is not perfect itself and sometimes/often is not enough). With the aPayer and aPayee the user will have to read the method code to learn that. > > > > -- > > Best regards, > > > > Dennis Schetinin > > > > ÑÑ, 12 Ð¸ÑÐ». 2018 Ð³. Ð² 6:29, K K Subbu <kksubbu.ml(a)gmail.com>: >> On Thursday 12 July 2018 03:54 AM, Tim Mackinnon wrote: >> > I was taught {âaâ/âanâ}DataType, so it would be: >> > >> > #name: aString >> >> It depends on the current level of abstraction. At the lowest levels, it >> is okay to use basic types like aString since classes (types) define >> behavior. If you are operating at a much higher level, say transfering >> money between two accounts, you would do: >> >> #transferMoney from: aPayer to: aPayee >> >> where both aPayer and aPayee could be anAccountHolder >> >> Essentially, the idea to keep the message part as close to normal >> statements as possible. >> >> The book "A Mentoring Course Smalltalk" by Andres Valloud covers this >> aspect in great detail. >> >> Regards .. Subbu >> >>

July 12, 2018

Re: [Pharo-users] Naming parameters - conventions?

by Dennis Schetinin

> > It depends on the current level of abstraction. If you are operating at a > much higher level, say transfering > money between two accounts, you would do: > #transferMoney from: aPayer to: aPayee > where both aPayer and aPayee could be anAccountHolder Why not #transferMoney from: payerAccountHolder to: payeeAccountHolder ? And how does the naming depend on level of abstraction? Practically, when a (potential) user of the method is going to invoke it, one of the first questions will be 'what kind of object I can/should pass there?'. With the classic Smalltalk convention it is quite obvious (though, the convention is not perfect itself and sometimes/often is not enough). With the aPayer and aPayee the user will have to read the method code to learn that. -- Best regards, Dennis Schetinin ÑÑ, 12 Ð¸ÑÐ». 2018 Ð³. Ð² 6:29, K K Subbu <kksubbu.ml(a)gmail.com>: > On Thursday 12 July 2018 03:54 AM, Tim Mackinnon wrote: > > I was taught {âaâ/âanâ}DataType, so it would be: > > > > #name: aString > > It depends on the current level of abstraction. At the lowest levels, it > is okay to use basic types like aString since classes (types) define > behavior. If you are operating at a much higher level, say transfering > money between two accounts, you would do: > > #transferMoney from: aPayer to: aPayee > > where both aPayer and aPayee could be anAccountHolder > > Essentially, the idea to keep the message part as close to normal > statements as possible. > > The book "A Mentoring Course Smalltalk" by Andres Valloud covers this > aspect in great detail. > > Regards .. Subbu > > >

July 12, 2018

Re: [Pharo-users] Naming parameters - conventions?

by K K Subbu

On Thursday 12 July 2018 03:54 AM, Tim Mackinnon wrote: > I was taught {âaâ/âanâ}DataType, so it would be: > > #name: aString It depends on the current level of abstraction. At the lowest levels, it is okay to use basic types like aString since classes (types) define behavior. If you are operating at a much higher level, say transfering money between two accounts, you would do: #transferMoney from: aPayer to: aPayee where both aPayer and aPayee could be anAccountHolder Essentially, the idea to keep the message part as close to normal statements as possible. The book "A Mentoring Course Smalltalk" by Andres Valloud covers this aspect in great detail. Regards .. Subbu

July 12, 2018

Re: [Pharo-users] Email Google API for pharo

by oswall arguedas

Thank you very much for your answers. I will work on it. I give them feedback. Thanks Oswall ________________________________ De: Pharo-users <pharo-users-bounces(a)lists.pharo.org> en nombre de Sean P. DeNigris <sean(a)clipperadams.com> Enviado: miÃ©rcoles, 11 de julio de 2018 15:39:53 Para: pharo-users(a)lists.pharo.org Asunto: Re: [Pharo-users] Email Google API for pharo Peter UhnÃ¡k wrote > I've used it last year or so and it was very nice to use. Anything public we can use for inspiration? ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

July 12, 2018

Re: [Pharo-users] XML support for pharo

by oswall arguedas

Thanks Franz and Monty. I'm working on it, everything is going very well. The feedback when I master it. Oswall ________________________________ De: Pharo-users <pharo-users-bounces(a)lists.pharo.org> en nombre de monty <monty2(a)programmer.net> Enviado: miÃ©rcoles, 11 de julio de 2018 03:32 Para: pharo-users(a)lists.pharo.org Asunto: Re: [Pharo-users] XML support for pharo This is the latest version of the XML/XPath Scraping Booklet: <https://files.pharo.org/books-pdfs/booklet-Scraping/2018-01-07-scrapingbook…> Scraping HTML with XPath - files.pharo.org<https://files.pharo.org/books-pdfs/booklet-Scraping/2018-01-07-scrapingbook…> files.pharo.org 1.6 Alargeexample â¢ Siblings.Siblingsarechildnodesthathavethesameparent.Thecard-name,types,year,rarity,expansionandcardtextelementsareallsib- ___ montyos.wordpress.com

July 12, 2018

Re: [Pharo-users] XML support for pharo

by oswall arguedas

Thanks Franz and Monty. I'm working on it, everything is going very well. The feedback when I master it. Oswall ________________________________ De: Pharo-users <pharo-users-bounces(a)lists.pharo.org> en nombre de monty <monty2(a)programmer.net> Enviado: miÃ©rcoles, 11 de julio de 2018 03:32:35 Para: pharo-users(a)lists.pharo.org Asunto: Re: [Pharo-users] XML support for pharo This is the latest version of the XML/XPath Scraping Booklet: <https://files.pharo.org/books-pdfs/booklet-Scraping/2018-01-07-scrapingbook…> ___ montyos.wordpress.com

July 12, 2018

Re: [Pharo-users] Naming parameters - conventions?

by Richard Sargent

Tim Mackinnon wrote > Hi everyone, something Iâve meant to ask over the years, as Iâve seen lots > of variation and was taught something else in the day... > > What is the suggested way of naming parameters? > > I was taught {âaâ/âanâ}DataType, so it would be: > > #name: aString > > Which works ok (although falls apart if you refactor as the tools donât > interpret it - although I guess could be improved to do so) > > However often I find myself wanting to communicate a bit better as in: > > #name: fullNameString > > Which isnât strictly a datatype (and I tend to leave out the a/an when I > do this). But it feels a bit off piste and it does make me consider > whether my selector is named badly and should be: > > #fullName: aString > > Which takes me back to the convention I learned long ago. > > This said however, we often need to match similar #on:do, #in: generic > selector names and then itâs not always obvious the intent of parameter. > > Any thoughts to share? In my opinion, worth what you pay for it, the goal is to communicate and set the reader's expectations. You want the reader to know what kind of behaviours the argument should provide. So, when creating a setter method, it is sufficient to name the argument "aString". The method selector is telling you the purpose of the string. The argument is telling you that it is no more and no less than a string. It isn't trying to convey that there is a structure to that string. Just that the name is a string. Likewise, when naming a parameter for a more complex method you may need to say more, depending on what the selector itself says. e.g. #blahBlahBlahWithName: can easily work with "aString". Conversely, a method that takes multiple string arguments needs to effectively distinguish them from each other. e.g. #blahBlahBlahWithName:address:telephone: needs to do better than Dr. Seuss (aString1, aString2, etc.) In this example, I tend to use e.g. "nameString", "addressString", and "telephoneString". This conveys the purpose of each argument and identifies the behaviours one should expect. I am *not* a fan of argument names like "aNameString", since that can mislead readers into expecting name-specific behaviours from the argument. > I ask because for exercism, we should try and set a good example. > > Tim > > Sent from my iPhone -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

July 12, 2018

Re: [Pharo-users] Thoughts on mini Smalltalk exercises

by Ben Coman

On 11 July 2018 at 22:43, Tim Mackinnon <tim(a)testit.works> wrote: > Hi - Iâm trying to help Sam kickstart Pharo working Ian the exercism platform. For those less familiar, exercism is a platform with a series of exercises that users/students âcheckoutâ and then run a test to guide them through completing the code to then progress to the next challenge. There is also the ability to comment on each otherâs progress and see examples of otherâs solutions. Most languages are more traditional file based examples, so it would be nice to have Smalltalk as something a bit different. Although we think Tonel 2 will be an excellent vehicle for participating alongside other languages as it helps us fit in a little easier (nice how all our initiatives are coming together to make this easy). > > As you can imagine, exercises start out very simple and then increase in complexity. My question however, is about the early exercise like HelloWorld, LeapYear etc. > > These tend to be single method problems of just a few lines, requiring no instance variables (this all comes later). > > Iâm wondering about peopleâs thoughts on whether we should introduce early Smalltalk examples as just class methods and later introduce instance methods and âclass constructor methods â? Or is this more confusing for students? Essentially we are battling with the familiarity of the C âmainâ method - and looking at python and ruby solutions, they initially start with no objects and just main style methods. > > E.g. hello world can be simply: HelloWorld sayHello. vs HelloWorld new sayHello. > > I can see proâs/conâs either way - but wondering what others think. I've installed Sam's PR and my main thought is that the System Browser defaults to the instance side, so its easier for fresh students to misplace code when it ends up on the class side, when they close a browser and open a new one. The unit test the students run takes care the of needing to send #new to get an object, so I think its simpler to keep implementations on the instance-side. One downside is that the Quality Assistant indicates that utility methods (having no reference to instance variables) should belong on the class side. It might be good that this warning is disabled globally when the Exercism tool is installed. I think using a Manifest to do this would look complicated to newcomers. Later on some specific Factory Pattern exercises might be useful to introduce students to using class-side methods. cheers -ben

July 12, 2018