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

Re: [Pharo-users] including Pillar in Pharo image by default

by Esteban Lorenzano

> On 12 Aug 2017, at 12:46, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > > I would very much like this path. What would constitute tiny? no idea, we need to think on it :) but I see no point in create a new (even small) parser/scanner each time we need one. At the end you have several small parsers that repeat always same process when PetitParser is good for most of our problems (and if you need to improve it. you can always load PP compiler, etc.). Esteban > > Cheers, > Doru > > >> On Aug 11, 2017, at 9:10 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> hi, >> >>> On 11 Aug 2017, at 18:57, Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com> wrote: >>> >>> Another step would be to get a minimal parser not relying on >>> PetitParser. >> >> Letâs think differently: why not to include a tiny PetitParser? >> Then we can think on: >> >> - pillar sintax (better than just a restricted version) >> - simplify other âsmall parsersâ that are already on the image. >> - we provide a tool to o cool stuff (instead relying as always in regexp, etc.) >> >> cheers, >> Esteban > > -- > www.tudorgirba.com > www.feenk.com > > "Beauty is where we see it." > > > > >

Aug. 12, 2017

Re: [Pharo-users] PetitParser: Parse X as long as it's not Y

by Tudor Girba

Hi, As Jan pointed out, you should use ânotâ instead of ânegate andâ. Cheers, Doru > On Aug 10, 2017, at 5:22 AM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Peter Kenny wrote >> You may need to post-process the parse to get what you >> want. > > Good point. I omitted several ` ==> #second` in several places for > readability on the list, but we should mention that for posterity. Also, duh > `gen negate and` should be `gen not`! > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/PetitParser-Parse-X-as-long-as-it-s-not-Y-tp4958895p4… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > -- www.tudorgirba.com www.feenk.com "Speaking louder won't make the point worthier."

Aug. 12, 2017

Re: [Pharo-users] Checking in on source/dependency management

by Ben Coman

On Thu, Aug 10, 2017 at 2:30 AM, sergio ruiz <sergio.rrd(a)gmail.com> wrote: > Hi, all.. > > I am just checking in on source and dependency management. > > I have been using Pharo 6 for a bit now, and i know that there has been a > lot of talk about going to bit for source code management. > > I am wondering how far along that is, and if there is a package we can > start using to work through that. > > I am also wondering if metacello is still the dependency management system > of choice. I > I believe it is. The GUI tool (btw, can you clarify which one) was just a layer over Metacello. Metacello has two sub-parts: Configurations for traditional HTTP repositories like Smalltalkhub; and Baselines for use with git. Baselines are a subset of Configurations because git picks up some of that functionality. cheers -ben

Aug. 12, 2017

Re: [Pharo-users] including Pillar in Pharo image by default

by Tudor Girba

Hi, I would very much like this path. What would constitute tiny? Cheers, Doru > On Aug 11, 2017, at 9:10 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > hi, > >> On 11 Aug 2017, at 18:57, Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com> wrote: >> >> Another step would be to get a minimal parser not relying on >> PetitParser. > > Letâs think differently: why not to include a tiny PetitParser? > Then we can think on: > > - pillar sintax (better than just a restricted version) > - simplify other âsmall parsersâ that are already on the image. > - we provide a tool to o cool stuff (instead relying as always in regexp, etc.) > > cheers, > Esteban -- www.tudorgirba.com www.feenk.com "Beauty is where we see it."

Aug. 12, 2017

Re: [Pharo-users] [ann] moldable brick editor - alpha

by Tudor Girba

Is this still an issue? Could you also try on another OS (just to make sure)? Cheers, Doru > On Aug 10, 2017, at 2:12 PM, stephan <stephan(a)stack.nl> wrote: > > On 10-08-17 13:09, stephan wrote: >> On 05-08-17 00:19, Tudor Girba wrote: >> >Iceberg enableMetacelloIntegration: true. >> That doesn't work. It hangs the image, keeping one CPU >> busy. > > With 60510 that is non-interruptable, b.t.w. > > Stephan > > > > -- www.tudorgirba.com www.feenk.com "Problem solving efficiency grows with the abstractness level of problem understanding."

Aug. 12, 2017

Re: [Pharo-users] Pharo 6.0 and 6.1 64 bit freeze on MacMini

by Ben Coman

On Wed, Aug 2, 2017 at 2:07 AM, TedVanGaalen <tedvga(a)gmail.com> wrote: > Hi, > I have now tried to run Pharo 6.1 32 bit with > setting the screen resolution in > macOS System Preferences to the following > what they call "scaled resolutions" (read "non-native resolutions"), > which are less that the native screen resolution: > 3200 x 1800 and > 1920 x 1080. > In these resolutions the Pharo 6.1 32 bit works OK: > that is, when repeatedly switching > to and from full screen (using the green window button > in the upperleft corner) the Pharo window content is then > instantly correctly redrawn. Which is not the case with > native UHD resolution: > when maximizing the window is > not redrawn and leaves white bands at the top and left side. > Is it possible for you to post screenshots of these, so we have a concrete understanding of the behaviour? (note posts are limited to 1000kb) > if I e.g.moved an internal window like the system browser > downward repeated window parts remain where it was. > If I'm guessing was you are seeing on this second point, in the past four years I've seen similar behaviour a few times. I think this was on Windows. I lived with it and later cleared up on its own, "perhaps" when I changed hardware (but this Windows -> OSX -> Windows several months later). I had a very-vague intuition the problem may be related to AMD graphics chipset. Google found other applications were having similar problems. An exotic interaction with some specific hardware driver could account for why its not being widely observed. Which typically is a window redraw issue. > It then gets very sluggish and in the end freezes. > I then have to Force Quit the app. > Unfortunately Pharo dies then to fast to give some > post-mortem crash.dmp. > In the window movement shadowing I saw, I didn't experience any sluggish or freezing behaviour. cheers -ben > > I assume that other crashes, that is e.g. with dragging the Playground > also caused it to freeze, because of redraw issues, which occur > likewise in the 32 and 64 bit version of Pharo version > 6.0 > with this UHD resolution. > > So, my guess is that drawing on macOS with the > native resolution UHD 3840 * 2160 still has a bug. > I'd suggest that perhaps comparing the graphic driver logic > with that of what is used in Pharo 5.0, which functions correctly, > with UHD resolution might reveal the problem? > > Have you tested this on macOS with this UHD screens? > Will it/does it also crash also on 4k iMac and even 5k iMacs or only > on the Mac Mini? > > Thank you in advance for solving this problem, if possible. > > TedvG > > > > > > -- > View this message in context: http://forum.world.st/Pharo-6- > 0-and-6-1-64-bit-freeze-on-MacMini-tp4957969p4958189.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

Aug. 12, 2017

Re: [Pharo-users] including Pillar in Pharo image by default

by Tim Mackinnon

Of course, I/we recognise and appreciate all the work that's gone into docs in pillar - but I think it should be reasonably straightforward to write a converter as it is pretty closely related from what I have seen. So I don't make the suggestion flippantly, and would want to help write a converter and get us to a common ground where we can differentiate on the aspects where we can excel. Tim Sent from my iPhone > On 11 Aug 2017, at 23:21, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > > A long time issue with Markdown was that there was no standardization (and when I used Pillar's MD export ~2 years ago it didn't work well). > > However CommonMark ( http://spec.commonmark.org/0.28/ ) has become the de-facto standard, so it would make sense to support it bidirectionally with Pillar. > >> The readme.md that Peter is talking about is gfm markdown > > Well, technically it is just a CommonMark, as I am not using any github extensions. > (Github uses CommonMarks and adds just couple small extensions.) > > Peter >

Aug. 11, 2017

Re: [Pharo-users] including Pillar in Pharo image by default

by Peter Uhnak

A long time issue with Markdown was that there was no standardization (and when I used Pillar's MD export ~2 years ago it didn't work well). However CommonMark ( http://spec.commonmark.org/0.28/ ) has become the de-facto standard, so it would make sense to support it bidirectionally with Pillar. > The readme.md that Peter is talking about is gfm markdown Well, technically it is just a CommonMark, as I am not using any github extensions. (Github uses CommonMarks and adds just couple small extensions.) Peter

Aug. 11, 2017

Re: [Pharo-users] including Pillar in Pharo image by default

by Offray Vladimir Luna CÃ¡rdenas

Hi, I would go both suggestions of including both support for PetitParser (Esteban's ) and Markdown (Tim's) . Having our own syntax for documentation would make us more insular. In the same way that support for Git is strategical in wider acceptance and visibility (even if we use other DVCS like Fossil with Iceberg) in the coding front, support for Markdown is similar in the documentation front. Pandoc's Markdown has all features for professional book/thesis/article like documents already and Markdown is widely used (like Git) in the code documentation Cheers, Offray On 11/08/17 15:14, Tim Mackinnon wrote: > If we are considering this, might we take the hard decision to actually support proper markdown (or even kramdown if we need more control). > > Pillar is a weird variant that isn't like everyone else - so i always have to think about how to do formatting. > > I know it's not nice, and lots of things are done in pillar - but could we convert them to be like everyone else? The readme.md that Peter is talking about is gfm markdown.' > > Tim > > Sent from my iPhone > >> On 11 Aug 2017, at 20:24, Peter Uhnak <i.uhnak(a)gmail.com> wrote: >> >>> On Fri, Aug 11, 2017 at 09:14:01PM +0200, Esteban Lorenzano wrote: >>> >>>> On 11 Aug 2017, at 21:10, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>>> >>>> hi, >>>> >>>>> On 11 Aug 2017, at 18:57, Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com <mailto:cyril.ferlicot@gmail.com>> wrote: >>>>> >>>>> Another step would be to get a minimal parser not relying on >>>>> PetitParser. >>>> Letâs think differently: why not to include a tiny PetitParser? >>>> Then we can think on: >>>> >>>> - pillar sintax (better than just a restricted version) >>> *syntax*â¦ sorry for spanish intromission ;) >>> >>> btwâ¦ not just outside the image (as readme). >> Yes, one of the points I want is to have the readme available in Pharo's Help Browser with rich content. >> >> Peter >> > >

Aug. 11, 2017

Re: [Pharo-users] FLSerializer in Pharo 6.1

by Tim Mackinnon

I'm using flserialiser in Pharo Lambda on 64 bit, and it's working writing a context to an s3 bucket which is pretty hardcore, so I'd say it is working. So there must be some difference you have found Tim Sent from my iPhone > On 11 Aug 2017, at 20:56, Johannes Brauer <brauer(a)nordakademie.de> wrote: > > Hi Stephane, > > I take a fresh Pharo 6.1 image, put it on my desktop (macOs 10.12.6), and then I take the example from the FLSerializer class comment: > > | sourceArray loadedArray | > sourceArray := Array > with: 'a string' > with: Transcript > with: [ Transcript show: 'a string' ]. > ^ FLSerializer serialize: sourceArray toFileNamed: âexample.FL' > > Evaluating this results in the Exception. > > Johannes >> Am 11.08.2017 um 19:18 schrieb Stephane Ducasse <stepharo.self(a)gmail.com>: >> >> Hi johannes >> >> do you have an example so that we can try here? >> >> Tx >> >>> On Fri, Aug 11, 2017 at 4:06 PM, Johannes Brauer <brauer(a)nordakademie.de> wrote: >>> Hi everyone, >>> >>> the FLSerializer in Pharo 6.1 doesnât work. I tried the example from the class comment and I always get >>> >>> FileException: cannot open file: example.FL. >>> >>> Is that a known problem? >>> >>> Johannes >> >

Aug. 11, 2017