February 2018 - Pharo-users

Re: [Pharo-users] How to have an in-image map (morph/spec/brick) showing a gps location

by Sven Van Caekenberghe

> On 9 Feb 2018, at 06:40, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > Le 09/02/2018 Ã 00:46, Arturo Zambrano a Ã©crit : >> I used Roassal + OSM and worked perfectly (2 year ago at least). Although I think there is no support for something like a tiles cache. > > We did the OSM support with an in-image tiles cache, but limited to the current map section being viewed. > > It would be easy to add an on-disk cache to that code. > > Thierry > >> On Thu, Feb 8, 2018 at 7:46 AM, CÃ©drick BÃ©ler <cdrick65(a)gmail.com <mailto:cdrick65@gmail.com>> wrote: >> Hello, >> I would like to have a representation of a map in the image to show >> (my) GPS coordinates. >> I havenât really tried nor searched yet but Iâve seen Roassal >> examples that could do the job, especially the Open Street Map >> integration. >> So does people here have advices on how to to that (having a morph >> that shows a map and positions) ? >> Ideally I would like to have it work offline (meaning I download >> first tilesâ¦or a vectorized map would do the job too). >> TIA, >> CÃ©drick Thierry, Where are the load instructions ? Does it still work for Pharo 7 ? Sven

Feb. 9, 2018

Re: [Pharo-users] Websocket features

by Sven Van Caekenberghe

Ben, > On 9 Feb 2018, at 04:17, Ben Coman <btc(a)openinworld.com> wrote: > > @Sven, > > I'm new to websockets and don't properly grok all the features in columns here... > https://en.wikipedia.org/wiki/Comparison_of_WebSocket_implementations > > but could you comment on which are provided by Zinc Websockets? > > cheers -ben I would say all of them. ZnWebSockets is a complete/compliant RFC 6455 implementation. https://ci.inria.fr/pharo-contribution/job/EnterprisePharoBook/lastSuccessf… https://github.com/svenvc/docs/blob/master/zinc/zinc-websockets-paper.md [older] http://websocket.stfx.eu/ [live demo] It has been used successfully by many people before. Sven

Feb. 9, 2018

Re: [Pharo-users] How to have an in-image map (morph/spec/brick) showing a gps location

by Thierry Goubier

Le 09/02/2018 Ã 00:46, Arturo Zambrano a Ã©critÂ : > I used Roassal + OSM and worked perfectly (2 year ago at least). > Although I think there is no support for something like a tiles cache. We did the OSM support with an in-image tiles cache, but limited to the current map section being viewed. It would be easy to add an on-disk cache to that code. Thierry > On Thu, Feb 8, 2018 at 7:46 AM, CÃ©drick BÃ©ler <cdrick65(a)gmail.com > <mailto:cdrick65@gmail.com>> wrote: > > Hello, > > I would like to have a representation of a map in the image to show > (my) GPS coordinates. > > I havenât really tried nor searched yet but Iâve seen Roassal > examples that could do the job, especially the Open Street Map > integration. > > So does people here have advices on how to to that (having a morph > that shows a map and positions) ? > Ideally I would like to have it work offline (meaning I download > first tilesâ¦or a vectorized map would do the job too). > > TIA, > > CÃ©drick > > > >

Feb. 9, 2018

Websocket features

by Ben Coman

@Sven, I'm new to websockets and don't properly grok all the features in columns here... https://en.wikipedia.org/wiki/Comparison_of_WebSocket_implementations but could you comment on which are provided by Zinc Websockets? cheers -ben

Feb. 9, 2018

Re: [Pharo-users] How to have an in-image map (morph/spec/brick) showing a gps location

by Arturo Zambrano

I used Roassal + OSM and worked perfectly (2 year ago at least). Although I think there is no support for something like a tiles cache. On Thu, Feb 8, 2018 at 7:46 AM, CÃ©drick BÃ©ler <cdrick65(a)gmail.com> wrote: > Hello, > > I would like to have a representation of a map in the image to show (my) > GPS coordinates. > > I havenât really tried nor searched yet but Iâve seen Roassal examples > that could do the job, especially the Open Street Map integration. > > So does people here have advices on how to to that (having a morph that > shows a map and positions) ? > Ideally I would like to have it work offline (meaning I download first > tilesâ¦or a vectorized map would do the job too). > > TIA, > > CÃ©drick > > > >

Feb. 8, 2018

Re: [Pharo-users] PetitParser: Building composed (dependent) parsers and isolating productions code

by Arturo Zambrano

Thanks Diego! I really appreciate your comments. Best regards. Arturo On Fri, Feb 2, 2018 at 6:27 AM, Diego Lont <diego.lont(a)delware.nl> wrote: > Hi, > > I have never used dependents (^ (self dependencyAt: StatementBParser) > ruleB), but here are my thoughts when reading this. > > When parsing it makes sense to make a separation between syntax and > semantics. Applying this functional distinction in your technical design > usually makes sense. In practical terms making a class for the syntax (i.e. > StatementASyntax) and one class for the semantics, subclassing the syntax > (i.e. StatementASyntax subclass: StatementAParse). > > So the question here is what class is responsible for the semantics and > what class is responsible for the syntax. Depending on the answer on this > question you should build your tree. Do you want your statement parsers to > know the semantics of the statements as well, then I would suggest separate > these in a syntax and a parser (and only having production rules in > PLParser for rules that combine things and no production rules when the > rule is merely forward them to your statement parser). > > Or do the statement parsers merely do the syntax, and does the PLParser > apply the semantics (maybe because the semantics is context sensitive), the > you should not create a duplicate structure in your statement parsers, but > have the production rules i the PLParser (or a subclass of PLParser). > > As to your maintenance nightmare: > - I would add a superclass for the syntax, and not a subclass for the > semantics. > - And maybe you should consider referring to the parser as a resource / > factory method, so you only have one reference to each of your statement > parsers. > > PLParser>> ruleB > ^ (self dependencyAt: self statementBParser) ruleB > > PLParser>> statementBParser > ^ StatementBParser > > Regards, > Diego > > > > On 01 Feb 2018, at 14:42, Arturo Zambrano <arturo.zambrano(a)gmail.com> > wrote: > > > > Hi All, > > Could you please share some advice on the following situation? > > I wrote my first Petit Parser. > > From the documentation I read that: > > 1) it is possible to depend on other parsers making the development more > modular. > > 2) The docs also suggest that, in order to separate grammars rules from > productions, we can make a parser with productions a subclass of a parser > which defines the grammar. > > > > I started applying 1) so my structure is something like > > > > AbstractParser " contains some common basic elements common to all > subclasses) > > StatementAParser > > StatementBParser > > PLParser "this guy uses the StatementX parsers" > > > > So there is a parser for different statements of the programming > language. > > The PLParser uses PetitParser dependency mechanism to rely on the > Statement*Parsers. For instance: > > PLParser>> ruleB > > ^ (self dependencyAt: StatementBParser) ruleB > > > > > > So far so good, the grammar is working, the parser works. > > > > Now, I would like to write the productions, separately from the grammar > part (remember 2) ), so I should make subclasses adding the productions in > the form > > >>ruleA > > ^super ruleA ===> [ my production code] > > > > The point is that PLParser explicitly depends on Statements*Parser, and > the name of the Statement*Parser appears here and there, so creating > subclasses would result in maintenance nightmare. The new layer of parsers > with productions will duplicate the dependencies and I foresee it will be a > mess. > > > > So now, I think that having just one big class with all the rules for > the grammar is better if you plan to separate productions code isolated > from the grammar. > > > > Am I right? Maybe I'm missing some point regarding writing composed > parsers and separating productions from grammar. > > > > Any pointer or comment is welcome. > > > > Arturo > > > > >

Feb. 8, 2018

Re: [Pharo-users] GT Documenter status

by Peter H. Meadows

On 8 February 2018 at 12:27, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > Thanks for the report. Unfortunately, I do not see the screenshot. Can you resend it? https://imgur.com/Q76xrR7 > > If you installed the code using your script, you should gotten Moz2D as well. > > Doru > > >> On Feb 8, 2018, at 7:59 PM, Peter H. Meadows via Pharo-users <pharo-users(a)lists.pharo.org> wrote: >> >> >> From: "Peter H. Meadows" <peter.h.meadows(a)googlemail.com> >> Subject: GT Documenter status >> Date: February 8, 2018 at 7:59:26 PM GMT+1 >> To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> >> >> >> Hi. I'm looking at GT Documenter in Pharo 6.1 on Ubuntu. >> It doesn't display any spaces, and some of the text looks strange. >> (see attachment for screenshot). >> Why? >> (screenshot is from Moose6.1 beta image, but it's the same in Pharo6.1) >> >> The screenshot from https://github.com/feenkcom/gtoolkit looks normal. >> >> It's using Cairo? Is the plan still to switch to Moz2D? >> >> I installed by: >> Metacello new >> baseline: 'GToolkit'; >> repository: 'github://feenkcom/gtoolkit/src'; >> load. >> >> Image >> ----- >> /home/phm/Pharo/images/Moose Suite 6.1 (beta)/Moose Suite 6.1 (beta).image >> Pharo6.0 >> Latest update: #60529 >> Unnamed >> >> Virtual Machine >> --------------- >> /home/phm/Pharo/vms/61-x86/lib/pharo/5.0-201707201942/pharo >> CoInterpreter VMMaker.oscog-eem.2254 uuid: >> 4f2c2cce-f4a2-469a-93f1-97ed941df0ad Jul 20 2017 >> StackToRegisterMappingCogit VMMaker.oscog-eem.2252 uuid: >> 2f3e9b0e-ecd3-4adf-b092-cce2e2587a5c Jul 20 2017 >> VM: 201707201942 https://github.com/OpenSmalltalk/opensmalltalk-vm.git >> $ Date: Thu Jul 20 12:42:21 2017 -0700 $ Plugins: 201707201942 >> https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ >> >> Unix built on Jul 20 2017 20:49:20 Compiler: 4.6.3 >> VMMaker versionString VM: 201707201942 >> https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Thu Jul >> 20 12:42:21 2017 -0700 $ Plugins: 201707201942 >> https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ >> CoInterpreter VMMaker.oscog-eem.2254 uuid: >> 4f2c2cce-f4a2-469a-93f1-97ed941df0ad Jul 20 2017 >> StackToRegisterMappingCogit VMMaker.oscog-eem.2252 uuid: >> 2f3e9b0e-ecd3-4adf-b092-cce2e2587a5c Jul 20 2017 >> >> Operating System/Hardware >> ------------------------- >> unix linux-gnu i686 >> >> Thanks in advance. >> <Screenshot from 2018-02-08 11-54-09.png> >> > > -- > www.tudorgirba.com > www.feenk.com > > "Sometimes the best solution is not the best solution." >

Feb. 8, 2018

Re: [Pharo-users] GT Documenter status

by Peter H. Meadows

On 8 February 2018 at 12:27, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > Thanks for the report. Unfortunately, I do not see the screenshot. Can you resend it? https://imgur.com/gallery/29Z9C > > If you installed the code using your script, you should gotten Moz2D as well. > Which script? When I look at settings I don't see an option to switch to Moz2D. > Doru > > >> On Feb 8, 2018, at 7:59 PM, Peter H. Meadows via Pharo-users <pharo-users(a)lists.pharo.org> wrote: >> >> >> From: "Peter H. Meadows" <peter.h.meadows(a)googlemail.com> >> Subject: GT Documenter status >> Date: February 8, 2018 at 7:59:26 PM GMT+1 >> To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> >> >> >> Hi. I'm looking at GT Documenter in Pharo 6.1 on Ubuntu. >> It doesn't display any spaces, and some of the text looks strange. >> (see attachment for screenshot). >> Why? >> (screenshot is from Moose6.1 beta image, but it's the same in Pharo6.1) >> >> The screenshot from https://github.com/feenkcom/gtoolkit looks normal. >> >> It's using Cairo? Is the plan still to switch to Moz2D? >> >> I installed by: >> Metacello new >> baseline: 'GToolkit'; >> repository: 'github://feenkcom/gtoolkit/src'; >> load. >> >> Image >> ----- >> /home/phm/Pharo/images/Moose Suite 6.1 (beta)/Moose Suite 6.1 (beta).image >> Pharo6.0 >> Latest update: #60529 >> Unnamed >> >> Virtual Machine >> --------------- >> /home/phm/Pharo/vms/61-x86/lib/pharo/5.0-201707201942/pharo >> CoInterpreter VMMaker.oscog-eem.2254 uuid: >> 4f2c2cce-f4a2-469a-93f1-97ed941df0ad Jul 20 2017 >> StackToRegisterMappingCogit VMMaker.oscog-eem.2252 uuid: >> 2f3e9b0e-ecd3-4adf-b092-cce2e2587a5c Jul 20 2017 >> VM: 201707201942 https://github.com/OpenSmalltalk/opensmalltalk-vm.git >> $ Date: Thu Jul 20 12:42:21 2017 -0700 $ Plugins: 201707201942 >> https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ >> >> Unix built on Jul 20 2017 20:49:20 Compiler: 4.6.3 >> VMMaker versionString VM: 201707201942 >> https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Thu Jul >> 20 12:42:21 2017 -0700 $ Plugins: 201707201942 >> https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ >> CoInterpreter VMMaker.oscog-eem.2254 uuid: >> 4f2c2cce-f4a2-469a-93f1-97ed941df0ad Jul 20 2017 >> StackToRegisterMappingCogit VMMaker.oscog-eem.2252 uuid: >> 2f3e9b0e-ecd3-4adf-b092-cce2e2587a5c Jul 20 2017 >> >> Operating System/Hardware >> ------------------------- >> unix linux-gnu i686 >> >> Thanks in advance. >> <Screenshot from 2018-02-08 11-54-09.png> >> > > -- > www.tudorgirba.com > www.feenk.com > > "Sometimes the best solution is not the best solution." >

Feb. 8, 2018

Re: [Pharo-users] GT Documenter status

by Tudor Girba

Hi, Thanks for the report. Unfortunately, I do not see the screenshot. Can you resend it? If you installed the code using your script, you should gotten Moz2D as well. Doru > On Feb 8, 2018, at 7:59 PM, Peter H. Meadows via Pharo-users <pharo-users(a)lists.pharo.org> wrote: > > > From: "Peter H. Meadows" <peter.h.meadows(a)googlemail.com> > Subject: GT Documenter status > Date: February 8, 2018 at 7:59:26 PM GMT+1 > To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> > > > Hi. I'm looking at GT Documenter in Pharo 6.1 on Ubuntu. > It doesn't display any spaces, and some of the text looks strange. > (see attachment for screenshot). > Why? > (screenshot is from Moose6.1 beta image, but it's the same in Pharo6.1) > > The screenshot from https://github.com/feenkcom/gtoolkit looks normal. > > It's using Cairo? Is the plan still to switch to Moz2D? > > I installed by: > Metacello new > baseline: 'GToolkit'; > repository: 'github://feenkcom/gtoolkit/src'; > load. > > Image > ----- > /home/phm/Pharo/images/Moose Suite 6.1 (beta)/Moose Suite 6.1 (beta).image > Pharo6.0 > Latest update: #60529 > Unnamed > > Virtual Machine > --------------- > /home/phm/Pharo/vms/61-x86/lib/pharo/5.0-201707201942/pharo > CoInterpreter VMMaker.oscog-eem.2254 uuid: > 4f2c2cce-f4a2-469a-93f1-97ed941df0ad Jul 20 2017 > StackToRegisterMappingCogit VMMaker.oscog-eem.2252 uuid: > 2f3e9b0e-ecd3-4adf-b092-cce2e2587a5c Jul 20 2017 > VM: 201707201942 https://github.com/OpenSmalltalk/opensmalltalk-vm.git > $ Date: Thu Jul 20 12:42:21 2017 -0700 $ Plugins: 201707201942 > https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ > > Unix built on Jul 20 2017 20:49:20 Compiler: 4.6.3 > VMMaker versionString VM: 201707201942 > https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Thu Jul > 20 12:42:21 2017 -0700 $ Plugins: 201707201942 > https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ > CoInterpreter VMMaker.oscog-eem.2254 uuid: > 4f2c2cce-f4a2-469a-93f1-97ed941df0ad Jul 20 2017 > StackToRegisterMappingCogit VMMaker.oscog-eem.2252 uuid: > 2f3e9b0e-ecd3-4adf-b092-cce2e2587a5c Jul 20 2017 > > Operating System/Hardware > ------------------------- > unix linux-gnu i686 > > Thanks in advance. > <Screenshot from 2018-02-08 11-54-09.png> > -- www.tudorgirba.com www.feenk.com "Sometimes the best solution is not the best solution."

Feb. 8, 2018

Re: [Pharo-users] Code formatting in CustomHelp

by Peter UhnÃ¡k

Hi, there are couple examples in WelcomeHelp. But more importantly, the HelpTopic content can be a Text, which means you can apply your own formatting. To the text. For example, I have also subsubheading: subsubheading: aString "Return Text object with subsubheading formating attributes." | text font color | font := LogicalFont familyName: 'Source Sans Pro' pointSize: 14. color := Color fromHexString: '3196D3'. text := aString asText. ^ text addAttribute: (TextFontReference toFont: font) from: 1 to: text size; addAttribute: TextEmphasis bold from: 1 to: text size; addAttribute: (TextColor new color: color) from: 1 to: text size; yourself And you can add your code (I've changed the familiny name) code: aString | text font color | font := LogicalFont familyName: 'Source Code Pro' pointSize: 14. text := aString asText. ^ text addAttribute: (TextFontReference toFont: font) from: 1 to: text size; yourself It would be cool to have a Pillar exporter to Pharo help. Peter On Thu, Feb 8, 2018 at 3:20 PM, CÃ©drick BÃ©ler <cdrick65(a)gmail.com> wrote: > Hi, > > Iâm doing some tutorials with the help system. > > In ProfStef, there is code formatting but not thrgouh the HelpBrowser. > In CustomHelp sublclasses, itâs possible to have some formatting > (heading:, bold:, â¦). > > Do you know if itâs possible to have a #code: method so as to use shout > specifically ? It doesnât seem obvious to me. > > TIA > > CÃ©drick >

Feb. 8, 2018