- Pharo-users - lists.pharo.org

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

Re: [Pharo-users] [Newb Question] Single Nautilus window?

by Stephane Ducasse

With calypso I think that we will be able to invent new flow. But we have more urgent topics but it means that people can experiment. Stef On Thu, Feb 8, 2018 at 11:46 AM, Animosity <bogdan.radacina+pharo(a)gmail.com> wrote: > I'm imagining something along the lines of: > - looking at the list of senders or implementors that I'm interested in, > I'll click on a bunch of them ( or click + a modifier key) - this would > enqueue them in the Browser history > - switch to my Browser window and use the History to navigate back and forth > between items > > Taking this further, if I could Bookmark a class/package that I'm currently > writing so with a click of the mouse I can have the Browser window go back > to where I left off, to continue my work...ahhh...dreaming is dangerous! > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >

Feb. 8, 2018