- Pharo-users - lists.pharo.org

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

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

by Tim Mackinnon

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] Thread-safe initialization of class state (was Re: Threads safety in Pharo)

by Tim Mackinnon

I think that thread safety comes with a penalty - so the overarching question is are we trying to create thread safe browsers (or does a thread safe penalty even impact browsing as maybe it's negligible?) Monty - maybe you could measure the impact if you are interested in this? If it's not much and we just need to encapsulate it with some mechanism (potentially having thread safety critics we can enable) then it's possibly something Calypso can embrace. This said, multi user editing is not something that has really taken off. Jason at VW did lots with Wolfpack, and it wasn't an idea that gained lots of traction a few years ago (sadly). It's tricky as we have to spend our engineering resources wisely. Tim Sent from my iPhone > On 11 Aug 2017, at 19:41, Gabriel Cotelli <g.cotelli(a)gmail.com> wrote: > > Suerly we can add a Critics Rule trying to detect the invalid pattern. > >> On Fri, Aug 11, 2017 at 10:39 AM, monty <monty2(a)programmer.net> wrote: >> > Sent: Friday, August 11, 2017 at 6:36 AM >> > From: "Denis Kudriashov" <dionisiydk(a)gmail.com> >> > To: "Any question about pharo is welcome" <pharo-users(a)lists.pharo.org> >> > Subject: Re: [Pharo-users] Thread-safe initialization of class state (was Re: Threads safety in Pharo) >> > >> > What package you explore? I not find fileTypes method in Pharo 7. >> >> Like I said, it's a hypothetical example. But I'm sure you could find similar examples of unsafe class state initialization in the image and in popular libraries. >> >> > 2017-08-11 8:53 GMT+02:00 monty <monty2@programmer.net[mailto:monty2@programmer.net]>:Here's a hypothetical broken class method that does lazy initialization of a class inst var: >> > >> > fileTypes >> > fileTypes ifNil: [ >> > fileTypes := Dictionary new. >> > fileTypes >> > at: 'txt' put: 'Text File'; >> > at: 'html' put: 'Web Page'; >> > at: 'pdf' put: 'Portable Document Format File'; >> > at: 'doc' put: 'Microsoft Word Document']. >> > ^ fileTypes. >> > >> > Because the assignment is done first and the initialization is done after with a cascade of interruptable sends of #at:put:, there's a window after the assignment where 'fileTypes' is not nil but also not fully initialized--a race condition. >> > >> > The fix is simple. Do the initialization before the atomic assignment takes place, so the var is only ever bound to nil or a fully initialized object: >> > >> > fileTypes >> > fileTypes ifNil: [ >> > fileTypes := >> > Dictionary new >> > at: 'txt' put: 'Text File'; >> > at: 'html' put: 'Web Page'; >> > at: 'pdf' put: 'Portable Document Format File'; >> > at: 'doc' put: 'Microsoft Word Document'; >> > yourself]. >> > ^ fileTypes. >> > >> > The fixed code is still vulnerable to duplicate initialization, because the initialization sequence is interruptable and 'fileTypes' is nil during it, but as long as the initialization is cheap enough, has no side effects that restrict how often it can be done, and it's enough that the initialized objects are equal (but not identical), that's OK. >> > >> > If it's too complex for a single statement, you can use a temp vars or put it in a separate factory method: >> > >> > fileTypes >> > fileTypes ifNil: [ >> > fileTypes := self newFileTypes]. >> > ^ fileTypes. >> > >> > Similar precautions (given how easy) might as well be taken with explicit initialization of class state too. Of course if the object is mutated later (in other methods), then Mutexes or other constructs are needed to guard access. But for immutable class state, ensuring initialization is done before assignment should be enough. >> > >> > > Sent: Tuesday, August 01, 2017 at 7:36 AM >> > > From: "Stephane Ducasse" <stepharo.self@gmail.com[mailto:stepharo.self@gmail.com]> >> > > To: "Any question about pharo is welcome" <pharo-users@lists.pharo.org[mailto:pharo-users@lists.pharo.org]> >> > > Subject: Re: [Pharo-users] Threads safety in Pharo >> > > >> > > I would love to have an analysis of assumptions made in some code. >> > > Because my impression is that the concurrent code is sometimes defined >> > > knowing the underlying logic of scheduler and this is not good. >> > > As I said to abdel privately in french it would be great to start from >> > > my french squeak book (Yes I wrote one long time ago) chapter on >> > > concurrent programming and turn it into a pharo chapter. >> > > >> > > Stef >> > > >> > > On Tue, Aug 1, 2017 at 1:31 PM, Ben Coman <btc@openinworld.com[mailto:btc@openinworld.com]> wrote: >> > > > Not sure I'll have what you're looking for, but to start, do you mean >> > > > Pharo's green threads or vm native threads? >> > > > cheers -ben >> > > > >> > > > On Mon, Jul 31, 2017 at 7:38 AM, Alidra Abdelghani via Pharo-users >> > > > <pharo-users@lists.pharo.org[mailto:pharo-users@lists.pharo.org]> wrote: >> > > >> >> > > >> >> > > >> >> > > >> ---------- Forwarded message ---------- >> > > >> From: Alidra Abdelghani <alidrandco@yahoo.fr[mailto:alidrandco@yahoo.fr]> >> > > >> To: pharo-users@lists.pharo.org[mailto:pharo-users@lists.pharo.org] >> > > >> Cc: "StÃ©phane Ducasse" <stephane.ducasse@inria.fr[mailto:stephane.ducasse@inria.fr]>, farid arfi >> > > >> <arfi_f@hotmail.com[mailto:arfi_f@hotmail.com]> >> > > >> Bcc: >> > > >> Date: Mon, 31 Jul 2017 01:38:58 +0200 >> > > >> Subject: Threads safety in Pharo >> > > >> Hi, >> > > >> >> > > >> Somebody once evoked the problem of threads safety in Pharo. With a friend >> > > >> of mine who is expert in formal methods and process scheduling, we would >> > > >> like to have a look on it. >> > > >> Does anyone knows a good document describing the problem of Pharo with >> > > >> threads safety or at least any document that we can start with? >> > > >> >> > > >> Thanks in advance, >> > > >> Abdelghani >> > > >> >> > > >> >> > > >> >> > > > >> > > >> > >> >

Aug. 11, 2017

Re: [Pharo-users] FLSerializer in Pharo 6.1

by Johannes Brauer

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

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

by Peter Uhnak

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] including Pillar in Pharo image by default

by Esteban Lorenzano

> 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). There was a prototype about rich text (using pillar, of course) for class comments. Esteban > - 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

Aug. 11, 2017