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

[Ben Coman]

On Wed, Aug 2, 2017 at 2:07 AM, TedVanGaalen  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.
>
>

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

[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  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
> 

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

[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

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

[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  wrote:
>>
>>> On Fri, Aug 11, 2017 at 09:14:01PM +0200, Esteban Lorenzano wrote:
>>>
 On 11 Aug 2017, at 21:10, Esteban Lorenzano  wrote:

 hi, 

> On 11 Aug 2017, at 18:57, Cyril Ferlicot D.  > 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
>>
>
>

Re: [Pharo-users] FLSerializer in Pharo 6.1

[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  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 :
>> 
>> 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  
>>> 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
>> 
> 

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

[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  wrote:
> 
>> On Fri, Aug 11, 2017 at 09:14:01PM +0200, Esteban Lorenzano wrote:
>> 
>>> On 11 Aug 2017, at 21:10, Esteban Lorenzano  wrote:
>>> 
>>> hi, 
>>> 
 On 11 Aug 2017, at 18:57, Cyril Ferlicot D. > 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
> 

Re: [Pharo-users] Thread-safe initialization of class state (was Re: Threads safety in Pharo)

[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  wrote:
> 
> Suerly we can add a Critics Rule trying to detect the invalid pattern.
> 
>> On Fri, Aug 11, 2017 at 10:39 AM, monty  wrote:
>> > Sent: Friday, August 11, 2017 at 6:36 AM
>> > From: "Denis Kudriashov" 
>> > To: "Any question about pharo is welcome" 
>> > 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 
>> > :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" 
>> > > 
>> > > To: "Any question about pharo is welcome" 
>> > > 
>> > > 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 
>> > > 

Re: [Pharo-users] FLSerializer in Pharo 6.1

[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 :
> 
> 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  
> 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
> 

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

[Peter Uhnak]

On Fri, Aug 11, 2017 at 09:14:01PM +0200, Esteban Lorenzano wrote:
> 
> > On 11 Aug 2017, at 21:10, Esteban Lorenzano  wrote:
> > 
> > hi, 
> > 
> >> On 11 Aug 2017, at 18:57, Cyril Ferlicot D.  >> > 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

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

[Esteban Lorenzano]

> On 11 Aug 2017, at 21:10, Esteban Lorenzano  wrote:
> 
> hi, 
> 
>> On 11 Aug 2017, at 18:57, Cyril Ferlicot D. > > 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

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

[Esteban Lorenzano]

hi, 

> On 11 Aug 2017, at 18:57, Cyril Ferlicot D.  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

Re: [Pharo-users] Thread-safe initialization of class state (was Re: Threads safety in Pharo)

[Gabriel Cotelli]

Suerly we can add a Critics Rule trying to detect the invalid pattern.

On Fri, Aug 11, 2017 at 10:39 AM, monty  wrote:

> > Sent: Friday, August 11, 2017 at 6:36 AM
> > From: "Denis Kudriashov" 
> > To: "Any question about pharo is welcome" 
> > 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  mon...@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.s...@gmail.com]>
> > > To: "Any question about pharo is welcome"  [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  b...@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
> > > > 
> wrote:
> > > >>
> > > >>
> > > >>
> > > >> -- Forwarded message --
> > > >> From: Alidra Abdelghani  idran...@yahoo.fr]>
> > > >> To: pharo-users@lists.pharo.org[mailto:pharo-users@lists.pharo.org]
> > > >> Cc: "Stéphane Ducasse"  stephane.duca...@inria.fr]>, farid arfi
> > > >> 
> > > >> 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 

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

[Alexandre Bergel]

The idea is neat! Usually, I write my README.md through the interface of 
GitHub. But indeed, if Git and inline documentation are central to Pharo, then 
having a mini-pillar in the base image would make sense. 

Anyway, Pillar definitely needs to be improved. Everything that goes in that 
direction is welcome!

Cheers,
Alexandre
-- 
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.



> On Aug 11, 2017, at 12:52 PM, Peter Uhnak  wrote:
> 
> Hi,
> 
> I would like to propose including Pillar in the Pharo image by default.
> 
> My reasoning:
> 
> Since we are moving to git, and most people will use github, gitlab, and the 
> likes, it is expected to include a README.md file (or possibly more extensive 
> documentation) alongside the code.
> 
> Which means that people will (and are) writing the README mostly by hand, 
> which of course is problematic, as e.g. code snippets can get deprecated, 
> screenshots become outdated, etc.
> 
> As Pillar tries to address these problems, it would make sense to me to 
> include Pillar in the image by default, as anyone using git (which eventually 
> should be everyone) will most likely benefit from writing their documentation 
> in Pillar.
> Similarly using Pillar would open an avenue to provide the documentation 
> in-image, e.g. one exporter for html/markdown, and another one for Pharo's 
> Help system.
> 
> I could, of course, install Pillar every time, but considering thats extra 
> effort and in the extra time I can fix the issues by hand, I don't have such 
> an incentive to use Pillar for this.
> 
> Questions & Problems:
> 
> I don't know by how much would pillar increase the image size. Perhaps there 
> could be (a) "lightweight Pillar" (that would include just pillar & markdown 
> exporter), or (b) we would have different images for different uses.
> 
> By different images I mean something along the lines of
> a) developer image - meant to be directly used by developers to create their 
> software
> b) production image - as a foundation for running systems / users
> 
> Does this make sense?
> 
> Peter
> 

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

[TedVanGaalen]

The screen is a Samsung U28D590 3840 x 2160 @ 30Hz (max reso on intel 4000
graphics) via a Thunderbolt->DisplayPort cable. Initially not directly
supported, that is, the resolution was not recognized by the OS as-is, but
has been enabled with the SwitchResx app here http://www.madrau.com/  which
somehow tweaks the system telling it about this new resolution. Many use
this utility app. It runs OK from the start since summer 2015. Pharo 5.0
runs fast and stable without problems. 



--
View this message in context: 
http://forum.world.st/Pharo-6-0-and-6-1-64-bit-freeze-on-MacMini-tp4957969p4960221.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

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

[Peter Uhnak]

What I meant is that I have a readme, e.g. https://github.com/OpenPonk/xmi , 
which contains

* Pharo code examples
* images
* References to Pharo code (class names, etc.)

But if the code changes (renames, API changes, different UI), I have to 
manually update the README.
There is also no way for me to validate the examples, etc and see if anything 
is broken.

Peter

On Fri, Aug 11, 2017 at 06:58:50PM +0200, Stephane Ducasse wrote:
> Let us rephrase it:
> 
> - I would like to have a mini pillar with a simplified model and visitor
> to display class comments.
> 
> - then think about Pharo 70 as the core and birth of a new generation of 
> imageS
> 
> I will restart to revisit Pillar once I'm done with the Lecture at Prague.
> 
> Stef
> 
> On Fri, Aug 11, 2017 at 6:52 PM, Peter Uhnak  wrote:
> > Hi,
> >
> > I would like to propose including Pillar in the Pharo image by default.
> >
> > My reasoning:
> >
> > Since we are moving to git, and most people will use github, gitlab, and 
> > the likes, it is expected to include a README.md file (or possibly more 
> > extensive documentation) alongside the code.
> >
> > Which means that people will (and are) writing the README mostly by hand, 
> > which of course is problematic, as e.g. code snippets can get deprecated, 
> > screenshots become outdated, etc.
> >
> > As Pillar tries to address these problems, it would make sense to me to 
> > include Pillar in the image by default, as anyone using git (which 
> > eventually should be everyone) will most likely benefit from writing their 
> > documentation in Pillar.
> > Similarly using Pillar would open an avenue to provide the documentation 
> > in-image, e.g. one exporter for html/markdown, and another one for Pharo's 
> > Help system.
> >
> > I could, of course, install Pillar every time, but considering thats extra 
> > effort and in the extra time I can fix the issues by hand, I don't have 
> > such an incentive to use Pillar for this.
> >
> > Questions & Problems:
> >
> > I don't know by how much would pillar increase the image size. Perhaps 
> > there could be (a) "lightweight Pillar" (that would include just pillar & 
> > markdown exporter), or (b) we would have different images for different 
> > uses.
> >
> > By different images I mean something along the lines of
> > a) developer image - meant to be directly used by developers to create 
> > their software
> > b) production image - as a foundation for running systems / users
> >
> > Does this make sense?
> >
> > Peter
> >
> 

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

[Esteban Lorenzano]

But I'm quite convinced is more related to the screen than the macmini. 
At least, I will like to test in that direction.

> On 11 Aug 2017, at 19:23, Stephane Ducasse  wrote:
> 
> We do not have mac minis around to test if this is related to the hardware.
> 
> Stef
> 
>> On Fri, Aug 11, 2017 at 5:05 PM, TedVanGaalen  wrote:
>> .. hard to imagine I am the only one with this problem?
>> 
>> 
>> 
>> --
>> View this message in context: 
>> http://forum.world.st/Pharo-6-0-and-6-1-64-bit-freeze-on-MacMini-tp4957969p4960027.html
>> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>> 
> 

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

[TedVanGaalen]

Well, I am in Speyer, Germany,
 
probably too far away, 

Although not really good in low level debugging
nevertheless, if I can help in some way, 
please let me know!

Does it run OK then on other 4/5K screen macs? 

TedvG

www.speyer.de



--
View this message in context: 
http://forum.world.st/Pharo-6-0-and-6-1-64-bit-freeze-on-MacMini-tp4957969p4960190.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

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

[Stephane Ducasse]

We do not have mac minis around to test if this is related to the hardware.

Stef

On Fri, Aug 11, 2017 at 5:05 PM, TedVanGaalen  wrote:
> .. hard to imagine I am the only one with this problem?
>
>
>
> --
> View this message in context: 
> http://forum.world.st/Pharo-6-0-and-6-1-64-bit-freeze-on-MacMini-tp4957969p4960027.html
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>

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

[Cyril Ferlicot D.]

Le 11/08/2017 à 19:19, Stephane Ducasse a écrit :
> Cyril
> 
> the ** can be used to point to another class for example acting as a ref.
> 
> Stef
> 
> 

I though it would be kept for real links to web urls.

-- 
Cyril Ferlicot
https://ferlicot.fr

http://www.synectique.eu
2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France



signature.asc
Description: OpenPGP digital signature

Re: [Pharo-users] VM dev and compilation

[Stephane Ducasse]

Hi bruno

Welcome. Do not hesitate to ask questions.

Stef

On Fri, Aug 11, 2017 at 4:49 PM, Esteban Lorenzano  wrote:
>
> On 11 Aug 2017, at 12:08, Bruno Durin  wrote:
>
> Hi,
>
> I have been tinkering with Pharo and Squeak for a few weeks and I am very
> enthusiastic with these great pieces of software! I would like to ask
> questions to check my understanding. I am refering from time to time to
> Squeak as it runs on the same VM as Pharo but my questions are focused on
> Pharo.
>
> As an exercice to learn, I am trying to compile Pharo VMs and get the VM
> simulator run in a Pharo image (first a 32-bit image+VM and later a 64-bit
> image+VM).
> I am doing this both under Ubuntu 14.04 LTS and Mac OS X 10.12.6.
> What I succeeded in doing:
> - compiling the squeak and pharo VM using the state of their respective git
> repo as of about 20 July 2017: on Mac both 32 and 64 bits, on Linux only 64
> bits (mainly because I did not want to spend the time to fix the 32-bit
> libraries which do not coexist well with their 64-bit counterparts)
> - on Mac, generating the VM development image (SpurVMMaker) for Squeak on
> top a (32 bits) V5 image, launch it and run the VM simulator,
> - on Mac, generating the VM development image (generator.image) for Pharo on
> top of a (32 bits) V5 image, launch it and starting to run a CogVMSimulator
> (which currently fails, but I am debugging it and learning along the way.)
>
> So, my questions:
> 1) About the Pharo VM compilation (Below "the" Pharo VM means the official
> VMs that are published on the Pharo website but if VM developers use a
> different process between 2 releases I would be happy to know the
> differences.)
> a) is it correct that the Pharo VM is built using the github pharo-vm
> repository?
>
>
> yes and no.
> - the officially distributed pharo-vm is built on
> opensmalltalk/opensmalltalk-vm and published into our servers.
> - we keep pharo-vm (in which opensmalltalk-vm is a subtree) repo as a
> CI/testing platform (that produces the “nightly-built” VMs from
> files.pharo.org/vm/nigthtly-builds), but this is used just for testing
> results, etc. the VMs that people should use are produced in the main
> repository.
>
>
> b) in the pharo-vm tree, is it correct that "build" and "results"
> directories are remnant of the build process before Pharo reunited with
> Squeak on opensmalltalk vm and that the builder classes in the
> generator.image (PharoVMSpur32Builder and co) do not create the build.sh
> script in the "build" directory any more.
>
>
> yes.
>
> c) is it correct that the Pharo VM is now built with the pharo.cog.spur (for
> example) make process in the various build sub-directories of the
> "opensmalltalk-vm" directory?
>
>
> yes.
>
> 2) When running a Pharo VM compiled on Mac, the GUI was noticeably slower
> that the official VM downloaded from pharo.org. (I compared running the
> official image.) I did not see such slow down when compiling a Squeak VM. My
> educated guess is that it is related to libcairo and dependencies. Are there
> compiler optimisations that I should have manually added? Should I generate
> a XCode project with cmake and compile in XCode (I currently use ./mvm make
> script)? I have not had this problem under Linux.
>
>
> no. I have no idea why you have a slower UI but
> - it is not related to cairo since standard pharo does not use it (just
> athens does)
> - you should not need to do anything manually (besides executing ./mvm -f)
> - you do not need to generate an Xcode project either…
>
> 3) On Mac, is the difference between having the plugins as Mach-O bundle in
> Squeak and as dylib libraries in Pharo only a packaging choice or does it
> have deeper implications? (Does it change for example the way FFI is done?)
>
>
> it's just a packaging choice.
>
> 4) Do I understand well that currently the simplest way to convert a 32-bit
> image to a 64-bit one is to use Spur32to64BitBootstrap class in a VM
> development image? (As far as I understand, the other way is to use
> SystemTracer.)
>
>
> yes.
> I don’t even know if it is *possible* with system tracer right now :)
>
> A remark: when manually compiling a Pharo VM in the pharo-vm repo following
> Eliot's instructions, the updateSCCSVersions script does not work (because
> it is one level down with respect to the top of the git tree as compared to
> the opensmalltalk-vm repository). I eventually understood that the correct
> build procedure is in the travis scripts but as I do not know well the CI
> tools, it took a long time before I thought of looking into these scripts.
> If pharo-vm is used to build the Pharo VM (see question 1.a) I think it
> would be good to update the build process in README.md in pharo-vm tree (and
> I can do it).
>
>
> yes, that’s right :)
>
> cheers,
> Esteban
>
>
> Thanks,
> Bruno
>
>
>

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

[Stephane Ducasse]

Cyril

the ** can be used to point to another class for example acting as a ref.

Stef

On Fri, Aug 11, 2017 at 7:15 PM, Cyril Ferlicot D.
 wrote:
> Le 11/08/2017 à 19:12, Cyril Ferlicot D. a écrit :
>>
>> We might want to add some syntax only for class comment and not Pillar
>> itself. For example to be able to reference a class in Pharo and get a
>> link to the class during the rendering.
>>
>> I think that we might also want the formats (bold, etc) and the ordered
>> list.
>>
>
> I just saw that you said bold after sending…
>
> --
> Cyril Ferlicot
> https://ferlicot.fr
>
> http://www.synectique.eu
> 2 rue Jacques Prévert 01,
> 59650 Villeneuve d'ascq France
>

Re: [Pharo-users] FLSerializer in Pharo 6.1

[Stephane Ducasse]

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  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

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

[Cyril Ferlicot D.]

Le 11/08/2017 à 19:12, Cyril Ferlicot D. a écrit :
> 
> We might want to add some syntax only for class comment and not Pillar
> itself. For example to be able to reference a class in Pharo and get a
> link to the class during the rendering.
> 
> I think that we might also want the formats (bold, etc) and the ordered
> list.
> 

I just saw that you said bold after sending…

-- 
Cyril Ferlicot
https://ferlicot.fr

http://www.synectique.eu
2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France



signature.asc
Description: OpenPGP digital signature

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

[Cyril Ferlicot D.]

Le 11/08/2017 à 19:09, Stephane Ducasse a écrit :
> Tx cyril
> 
> For class comment I image that we want
> 
> !
> 
> -
> -
> *url*
> and bold
> [[[
> 
> ]]]
> 
> Did I miss something.
> 
> Stef
> 
> 
> 


We might want to add some syntax only for class comment and not Pillar
itself. For example to be able to reference a class in Pharo and get a
link to the class during the rendering.

I think that we might also want the formats (bold, etc) and the ordered
list.

-- 
Cyril Ferlicot
https://ferlicot.fr

http://www.synectique.eu
2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France



signature.asc
Description: OpenPGP digital signature

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

[Stephane Ducasse]

Tx cyril

For class comment I image that we want

!

-
-
*url*
and bold
[[[

]]]

Did I miss something.

Stef


On Fri, Aug 11, 2017 at 6:57 PM, Cyril Ferlicot D.
 wrote:
> Le 11/08/2017 à 18:52, Peter Uhnak a écrit :
>> Hi,
>>
>> I would like to propose including Pillar in the Pharo image by default.
>>
>> My reasoning:
>>
>> Since we are moving to git, and most people will use github, gitlab, and the 
>> likes, it is expected to include a README.md file (or possibly more 
>> extensive documentation) alongside the code.
>>
>> Which means that people will (and are) writing the README mostly by hand, 
>> which of course is problematic, as e.g. code snippets can get deprecated, 
>> screenshots become outdated, etc.
>>
>> As Pillar tries to address these problems, it would make sense to me to 
>> include Pillar in the image by default, as anyone using git (which 
>> eventually should be everyone) will most likely benefit from writing their 
>> documentation in Pillar.
>> Similarly using Pillar would open an avenue to provide the documentation 
>> in-image, e.g. one exporter for html/markdown, and another one for Pharo's 
>> Help system.
>>
>> I could, of course, install Pillar every time, but considering thats extra 
>> effort and in the extra time I can fix the issues by hand, I don't have such 
>> an incentive to use Pillar for this.
>>
>> Questions & Problems:
>>
>> I don't know by how much would pillar increase the image size. Perhaps there 
>> could be (a) "lightweight Pillar" (that would include just pillar & markdown 
>> exporter), or (b) we would have different images for different uses.
>>
>> By different images I mean something along the lines of
>> a) developer image - meant to be directly used by developers to create their 
>> software
>> b) production image - as a foundation for running systems / users
>>
>> Does this make sense?
>>
>> Peter
>>
>
> Hi,
>
> I know that Stephane want to includes a light version of Pillar in the
> image.
>
> Currently he is working on a way to remove Magritte dependency from
> Pillar. Another step would be to get a minimal parser not relying on
> PetitParser. This parser would parse only a subset of the Pillar syntax
> that can be used for writing class comments. If this subset is defined
> (I we have the list of all Document Items we want to understand), I can
> give a try to make this light parse.
>
> --
> Cyril Ferlicot
> https://ferlicot.fr
>
> http://www.synectique.eu
> 2 rue Jacques Prévert 01,
> 59650 Villeneuve d'ascq France
>

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

[Stephane Ducasse]

Let us rephrase it:

- I would like to have a mini pillar with a simplified model and visitor
to display class comments.

- then think about Pharo 70 as the core and birth of a new generation of imageS

I will restart to revisit Pillar once I'm done with the Lecture at Prague.

Stef

On Fri, Aug 11, 2017 at 6:52 PM, Peter Uhnak  wrote:
> Hi,
>
> I would like to propose including Pillar in the Pharo image by default.
>
> My reasoning:
>
> Since we are moving to git, and most people will use github, gitlab, and the 
> likes, it is expected to include a README.md file (or possibly more extensive 
> documentation) alongside the code.
>
> Which means that people will (and are) writing the README mostly by hand, 
> which of course is problematic, as e.g. code snippets can get deprecated, 
> screenshots become outdated, etc.
>
> As Pillar tries to address these problems, it would make sense to me to 
> include Pillar in the image by default, as anyone using git (which eventually 
> should be everyone) will most likely benefit from writing their documentation 
> in Pillar.
> Similarly using Pillar would open an avenue to provide the documentation 
> in-image, e.g. one exporter for html/markdown, and another one for Pharo's 
> Help system.
>
> I could, of course, install Pillar every time, but considering thats extra 
> effort and in the extra time I can fix the issues by hand, I don't have such 
> an incentive to use Pillar for this.
>
> Questions & Problems:
>
> I don't know by how much would pillar increase the image size. Perhaps there 
> could be (a) "lightweight Pillar" (that would include just pillar & markdown 
> exporter), or (b) we would have different images for different uses.
>
> By different images I mean something along the lines of
> a) developer image - meant to be directly used by developers to create their 
> software
> b) production image - as a foundation for running systems / users
>
> Does this make sense?
>
> Peter
>

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

[Cyril Ferlicot D.]

Le 11/08/2017 à 18:52, Peter Uhnak a écrit :
> Hi,
> 
> I would like to propose including Pillar in the Pharo image by default.
> 
> My reasoning:
> 
> Since we are moving to git, and most people will use github, gitlab, and the 
> likes, it is expected to include a README.md file (or possibly more extensive 
> documentation) alongside the code.
> 
> Which means that people will (and are) writing the README mostly by hand, 
> which of course is problematic, as e.g. code snippets can get deprecated, 
> screenshots become outdated, etc.
> 
> As Pillar tries to address these problems, it would make sense to me to 
> include Pillar in the image by default, as anyone using git (which eventually 
> should be everyone) will most likely benefit from writing their documentation 
> in Pillar.
> Similarly using Pillar would open an avenue to provide the documentation 
> in-image, e.g. one exporter for html/markdown, and another one for Pharo's 
> Help system.
> 
> I could, of course, install Pillar every time, but considering thats extra 
> effort and in the extra time I can fix the issues by hand, I don't have such 
> an incentive to use Pillar for this.
> 
> Questions & Problems:
> 
> I don't know by how much would pillar increase the image size. Perhaps there 
> could be (a) "lightweight Pillar" (that would include just pillar & markdown 
> exporter), or (b) we would have different images for different uses.
> 
> By different images I mean something along the lines of
> a) developer image - meant to be directly used by developers to create their 
> software
> b) production image - as a foundation for running systems / users
> 
> Does this make sense?
> 
> Peter
> 

Hi,

I know that Stephane want to includes a light version of Pillar in the
image.

Currently he is working on a way to remove Magritte dependency from
Pillar. Another step would be to get a minimal parser not relying on
PetitParser. This parser would parse only a subset of the Pillar syntax
that can be used for writing class comments. If this subset is defined
(I we have the list of all Document Items we want to understand), I can
give a try to make this light parse.

-- 
Cyril Ferlicot
https://ferlicot.fr

http://www.synectique.eu
2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France



signature.asc
Description: OpenPGP digital signature

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

[Peter Uhnak]

Hi,

I would like to propose including Pillar in the Pharo image by default.

My reasoning:

Since we are moving to git, and most people will use github, gitlab, and the 
likes, it is expected to include a README.md file (or possibly more extensive 
documentation) alongside the code.

Which means that people will (and are) writing the README mostly by hand, which 
of course is problematic, as e.g. code snippets can get deprecated, screenshots 
become outdated, etc.

As Pillar tries to address these problems, it would make sense to me to include 
Pillar in the image by default, as anyone using git (which eventually should be 
everyone) will most likely benefit from writing their documentation in Pillar.
Similarly using Pillar would open an avenue to provide the documentation 
in-image, e.g. one exporter for html/markdown, and another one for Pharo's Help 
system.

I could, of course, install Pillar every time, but considering thats extra 
effort and in the extra time I can fix the issues by hand, I don't have such an 
incentive to use Pillar for this.

Questions & Problems:

I don't know by how much would pillar increase the image size. Perhaps there 
could be (a) "lightweight Pillar" (that would include just pillar & markdown 
exporter), or (b) we would have different images for different uses.

By different images I mean something along the lines of
a) developer image - meant to be directly used by developers to create their 
software
b) production image - as a foundation for running systems / users

Does this make sense?

Peter

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

[TedVanGaalen]

.. hard to imagine I am the only one with this problem? 



--
View this message in context: 
http://forum.world.st/Pharo-6-0-and-6-1-64-bit-freeze-on-MacMini-tp4957969p4960027.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

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

[TedVanGaalen]

thanks for you reply, Esteban

well, I can still use Pharo 5 in the mean time, no problem.
how/where should I forward this to vm-dev?

Regards, have a nice holiday!
Ted 



--
View this message in context: 
http://forum.world.st/Pharo-6-0-and-6-1-64-bit-freeze-on-MacMini-tp4957969p4960023.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

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

[Esteban Lorenzano]

> On 11 Aug 2017, at 13:48, TedVanGaalen  wrote:
> 
> since 1.8.2017 there was no response, did already anyone thought/worked to
> solve this problem?
> Thank you,
> Ted

not yet.
I’m on holidays so I cannot test anything. 

in a couple of weeks, maybe… but I’m guessing this is a VM problem… maybe 
someone on vm-dev can help here?

Esteban

> 
> TedVanGaalen wrote
>> Very very wild guess: it could have to do with GPU<-> Open GL? <-> Pharo
>> call time out issues because the Intel HD 4000 GPU is working at its
>> (officially allowed) upper performance limits with 3840 x 2160 at 30 Hz
>> refresh rate (maximum).
>> OTOH however:  
>>  1.  I am not a GPU Guru.. 
>>  2.  It works flawlessly with Pharo 5.0 and before.
>>  3.  All other macOS applications also work OK. 
>> 
>> If it is a VM issue, Squeak would have the same problem
>> but I don't want to spend time to try this as well.
>> 
>> TedvG
> 
> 
> 
> 
> 
> --
> View this message in context: 
> http://forum.world.st/Pharo-6-0-and-6-1-64-bit-freeze-on-MacMini-tp4957969p4959933.html
>  
> 
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com 
> .

Re: [Pharo-users] VM dev and compilation

[Esteban Lorenzano]

> On 11 Aug 2017, at 12:08, Bruno Durin  wrote:
> 
> Hi,
> 
> I have been tinkering with Pharo and Squeak for a few weeks and I am very 
> enthusiastic with these great pieces of software! I would like to ask 
> questions to check my understanding. I am refering from time to time to 
> Squeak as it runs on the same VM as Pharo but my questions are focused on 
> Pharo.
> 
> As an exercice to learn, I am trying to compile Pharo VMs and get the VM 
> simulator run in a Pharo image (first a 32-bit image+VM and later a 64-bit 
> image+VM).
> I am doing this both under Ubuntu 14.04 LTS and Mac OS X 10.12.6.
> What I succeeded in doing:
> - compiling the squeak and pharo VM using the state of their respective git 
> repo as of about 20 July 2017: on Mac both 32 and 64 bits, on Linux only 64 
> bits (mainly because I did not want to spend the time to fix the 32-bit 
> libraries which do not coexist well with their 64-bit counterparts)
> - on Mac, generating the VM development image (SpurVMMaker) for Squeak on top 
> a (32 bits) V5 image, launch it and run the VM simulator,
> - on Mac, generating the VM development image (generator.image) for Pharo on 
> top of a (32 bits) V5 image, launch it and starting to run a CogVMSimulator 
> (which currently fails, but I am debugging it and learning along the way.)
> 
> So, my questions:
> 1) About the Pharo VM compilation (Below "the" Pharo VM means the official 
> VMs that are published on the Pharo website but if VM developers use a 
> different process between 2 releases I would be happy to know the 
> differences.)
> a) is it correct that the Pharo VM is built using the github pharo-vm 
> repository?

yes and no.
- the officially distributed pharo-vm is built on 
opensmalltalk/opensmalltalk-vm and published into our servers. 
- we keep pharo-vm (in which opensmalltalk-vm is a subtree) repo as a 
CI/testing platform (that produces the “nightly-built” VMs from 
files.pharo.org/vm/nigthtly-builds 
), but this is used just for testing 
results, etc. the VMs that people should use are produced in the main 
repository.
 
> b) in the pharo-vm tree, is it correct that "build" and "results" directories 
> are remnant of the build process before Pharo reunited with Squeak on 
> opensmalltalk vm and that the builder classes in the generator.image 
> (PharoVMSpur32Builder and co) do not create the build.sh script in the 
> "build" directory any more.

yes.

> c) is it correct that the Pharo VM is now built with the pharo.cog.spur (for 
> example) make process in the various build sub-directories of the 
> "opensmalltalk-vm" directory?

yes.

> 2) When running a Pharo VM compiled on Mac, the GUI was noticeably slower 
> that the official VM downloaded from pharo.org . (I 
> compared running the official image.) I did not see such slow down when 
> compiling a Squeak VM. My educated guess is that it is related to libcairo 
> and dependencies. Are there compiler optimisations that I should have 
> manually added? Should I generate a XCode project with cmake and compile in 
> XCode (I currently use ./mvm make script)? I have not had this problem under 
> Linux.

no. I have no idea why you have a slower UI but
- it is not related to cairo since standard pharo does not use it (just athens 
does)
- you should not need to do anything manually (besides executing ./mvm -f)
- you do not need to generate an Xcode project either…

> 3) On Mac, is the difference between having the plugins as Mach-O bundle in 
> Squeak and as dylib libraries in Pharo only a packaging choice or does it 
> have deeper implications? (Does it change for example the way FFI is done?)

it's just a packaging choice.

> 4) Do I understand well that currently the simplest way to convert a 32-bit 
> image to a 64-bit one is to use Spur32to64BitBootstrap class in a VM 
> development image? (As far as I understand, the other way is to use 
> SystemTracer.)

yes.
I don’t even know if it is *possible* with system tracer right now :)

> A remark: when manually compiling a Pharo VM in the pharo-vm repo following 
> Eliot's instructions, the updateSCCSVersions script does not work (because it 
> is one level down with respect to the top of the git tree as compared to the 
> opensmalltalk-vm repository). I eventually understood that the correct build 
> procedure is in the travis scripts but as I do not know well the CI tools, it 
> took a long time before I thought of looking into these scripts. If pharo-vm 
> is used to build the Pharo VM (see question 1.a) I think it would be good to 
> update the build process in README.md in pharo-vm tree (and I can do it).

yes, that’s right :)

cheers,
Esteban

> 
> Thanks,
> Bruno
> 
> 

Re: [Pharo-users] FLSerializer in Pharo 6.1

[jb]

No, that cannot be the problem. 
The following works without problems:

| working stream |
working := FileSystem disk workingDirectory. 
stream := (working / 'foo.txt') writeStream. 
stream nextPutAll: 'Hello World'.
stream close.




--
View this message in context: 
http://forum.world.st/FLSerializer-in-Pharo-6-1-tp4959960p4959973.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] FLSerializer in Pharo 6.1

[webwarrior]

jb 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

Probably that's because you don't have write permission in working
directory.



--
View this message in context: 
http://forum.world.st/FLSerializer-in-Pharo-6-1-tp4959960p4959964.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

[Pharo-users] FLSerializer in Pharo 6.1

[Johannes Brauer]

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

Re: [Pharo-users] Thread-safe initialization of class state (was Re: Threads safety in Pharo)

[monty]

> Sent: Friday, August 11, 2017 at 6:36 AM
> From: "Denis Kudriashov" 
> To: "Any question about pharo is welcome" 
> 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 
> :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" 
> > 
> > To: "Any question about pharo is welcome" 
> > 
> > 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 
> >  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
> > >  wrote:
> > >>
> > >>
> > >>
> > >> -- Forwarded message --
> > >> From: Alidra Abdelghani 
> > >> To: pharo-users@lists.pharo.org[mailto:pharo-users@lists.pharo.org]
> > >> Cc: "Stéphane Ducasse" 
> > >> , farid arfi
> > >> 
> > >> 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,
> > >> 

Re: [Pharo-users] Thread-safe initialization of class state (was Re: Threads safety in Pharo)

[monty]

> Sent: Friday, August 11, 2017 at 5:51 AM
> From: "Tim Mackinnon" 
> To: "Any question about pharo is welcome" 
> Subject: Re: [Pharo-users] Thread-safe initialization of class state (was Re: 
> Threads safety in Pharo)
> 
> Interesting, your example was subtle enough that I had to read it a few times 
> to understand the issue. (I was caught up on the ifNil and not the contents).

That's the problem. They're close enough that someone could mistakenly refactor 
the correct code into the incorrect code--and that code would be perfectly fine 
for lazy initialization of instance state in a non-concurrent class. That's why 
I always insert a small comment before explaining why it was written that way.
 
> Actually, thinking about it - isn't the real issue the #ifNil - you want an 
> atomic version.
>  
> It strikes me you could wrap the whole concept into something like an 
> AtomicLazyVariable? E.g.
>  
> initialise
>fileTypes := AtomicLazyVariable using: [
> 
>Dictionary new
>at: 'txt' put: 'Text File';
>at: 'html' put: 'Web Page';
>yourself ].
>  
> Then have something
>  
> fileTypes 
>  ^fileTypes value
>  
> Where you have a critical section in #value?
>  
> Tim
>  
> Sent from my iPhone
> On 11 Aug 2017, at 07:53, monty 
>  wrote:
>  
> 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 AMFrom: "Stephane Ducasse" 
> To: "Any question 
> about pharo is welcome" 
> 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 definedknowing the underlying logic of scheduler and this 
> is not good.As I said to abdel privately in french it would be great to start 
> frommy french squeak book (Yes I wrote one long time ago) chapter 
> onconcurrent programming and turn it into a pharo chapter. Stef On Tue, Aug 
> 1, 2017 at 1:31 PM, Ben Coman 
>  wrote:Not sure I'll have 
> what you're looking for, but to start, do you meanPharo's green threads or vm 
> native threads?cheers -ben On Mon, Jul 31, 2017 at 7:38 AM, Alidra Abdelghani 
> via 
> Pharo-users 
> wrote:   -- Forwarded message --From: Alidra Abdelghani 
> To: 
> pharo-users@lists.pharo.org[mailto:pharo-users@lists.pharo.org]Cc: "Stéphane 
> Ducasse" , farid 
> arfiBcc:Date: Mon, 31 Jul 2017 
> 01:38:58 +0200Subject: 

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

[TedVanGaalen]

since 1.8.2017 there was no response, did already anyone thought/worked to
solve this problem?
Thank you,
Ted

TedVanGaalen wrote
> Very very wild guess: it could have to do with GPU<-> Open GL? <-> Pharo
> call time out issues because the Intel HD 4000 GPU is working at its
> (officially allowed) upper performance limits with 3840 x 2160 at 30 Hz
> refresh rate (maximum).
> OTOH however:  
>   1.  I am not a GPU Guru.. 
>   2.  It works flawlessly with Pharo 5.0 and before.
>   3.  All other macOS applications also work OK. 
> 
> If it is a VM issue, Squeak would have the same problem
> but I don't want to spend time to try this as well.
> 
> TedvG





--
View this message in context: 
http://forum.world.st/Pharo-6-0-and-6-1-64-bit-freeze-on-MacMini-tp4957969p4959933.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] Thread-safe initialization of class state (was Re: Threads safety in Pharo)

[Denis Kudriashov]

What package you explore? I not find fileTypes method in Pharo 7.

2017-08-11 8:53 GMT+02:00 monty :

> 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" 
> > To: "Any question about pharo is welcome" 
> > 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  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
> > >  wrote:
> > >>
> > >>
> > >>
> > >> -- Forwarded message --
> > >> From: Alidra Abdelghani 
> > >> To: pharo-users@lists.pharo.org
> > >> Cc: "Stéphane Ducasse" , farid arfi
> > >> 
> > >> 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
> > >>
> > >>
> > >>
> > >
> >
>
>

[Pharo-users] VM dev and compilation

[Bruno Durin]

Hi,

I have been tinkering with Pharo and Squeak for a few weeks and I am very
enthusiastic with these great pieces of software! I would like to ask
questions to check my understanding. I am refering from time to time to
Squeak as it runs on the same VM as Pharo but my questions are focused on
Pharo.

As an exercice to learn, I am trying to compile Pharo VMs and get the VM
simulator run in a Pharo image (first a 32-bit image+VM and later a 64-bit
image+VM).
I am doing this both under Ubuntu 14.04 LTS and Mac OS X 10.12.6.
What I succeeded in doing:
- compiling the squeak and pharo VM using the state of their respective git
repo as of about 20 July 2017: on Mac both 32 and 64 bits, on Linux only 64
bits (mainly because I did not want to spend the time to fix the 32-bit
libraries which do not coexist well with their 64-bit counterparts),
- on Mac, generating the VM development image (SpurVMMaker) for Squeak on
top a (32 bits) V5 image, launch it and run the VM simulator,
- on Mac, generating the VM development image (generator.image) for Pharo
on top of a (32 bits) V5 image, launch it and starting to run a
CogVMSimulator (which currently fails, but I am debugging it and learning
along the way.)

So, my questions:
1) About the Pharo VM compilation (Below "the" Pharo VM means the official
VMs that are published on the Pharo website but if VM developers use a
different process between 2 releases I would be happy to know the
differences.)
a) is it correct that the Pharo VM is built using the github pharo-vm
repository?
b) in the pharo-vm tree, is it correct that "build" and "results"
directories are remnant of the build process before Pharo reunited with
Squeak on opensmalltalk vm and that the builder classes in the
generator.image (PharoVMSpur32Builder and co) do not create the build.sh
script in the "build" directory any more.
c) is it correct that the Pharo VM is now built with the pharo.cog.spur
(for example) make process in the various build sub-directories of the
"opensmalltalk-vm" directory?
2) When running a Pharo VM compiled on Mac, the GUI was noticeably slower
that the official VM downloaded from pharo.org. (I compared running the
official image.) I did not see such slow down when compiling a Squeak VM.
My educated guess is that it is related to libcairo and dependencies. Are
there compiler optimisations that I should have manually added? Should I
generate a XCode project with cmake and compile in XCode (I currently use
./mvm make script)? I have not had this problem under Linux.
3) On Mac, is the difference between having the plugins as Mach-O bundle in
Squeak and as dylib libraries in Pharo only a packaging choice or does it
have deeper implications? (Does it change for example the way FFI is done?)
4) Do I understand well that currently the simplest way to convert a 32-bit
image to a 64-bit one is to use Spur32to64BitBootstrap class in a VM
development image? (As far as I understand, the other way is to use
SystemTracer.)

A remark: when manually compiling a Pharo VM in the pharo-vm repo following
Eliot's instructions, the updateSCCSVersions script does not work (because
it is one level down with respect to the top of the git tree as compared to
the opensmalltalk-vm repository). I eventually understood that the correct
build procedure is in the travis scripts but as I do not know well the CI
tools, it took a long time before I thought of looking into these scripts.
If pharo-vm is used to build the Pharo VM (see question 1.a) I think it
would be good to update the build process in README.md in pharo-vm tree
(and I can do it).

Thanks,
Bruno

Re: [Pharo-users] Thread-safe initialization of class state (was Re: Threads safety in Pharo)

[Tim Mackinnon]

Interesting, your example was subtle enough that I had to read it a few times 
to understand the issue. (I was caught up on the ifNil and not the contents).

Actually, thinking about it - isn't the real issue the #ifNil - you want an 
atomic version.

It strikes me you could wrap the whole concept into something like an 
AtomicLazyVariable? E.g.

initialise
   fileTypes := AtomicLazyVariable using: [
   Dictionary new
   at: 'txt' put: 'Text File';
   at: 'html' put: 'Web Page';
   yourself ].

Then have something

fileTypes 
 ^fileTypes value

Where you have a critical section in #value?

Tim

Sent from my iPhone

> On 11 Aug 2017, at 07:53, monty  wrote:
> 
> 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" 
>> To: "Any question about pharo is welcome" 
>> 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  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
>>>  wrote:
 
 
 
 -- Forwarded message --
 From: Alidra Abdelghani 
 To: pharo-users@lists.pharo.org
 Cc: "Stéphane Ducasse" , farid arfi
 
 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
 
 
 
>>> 
>> 
> 

Re: [Pharo-users] [ANN] PharoLambda 1.5 - Pharo running on AWS Lambda now with saved Debug sessions via S3

[Denis Kudriashov]

This is cool Tim.

So what image size you deployed at the end?

2017-08-10 15:47 GMT+02:00 Tim Mackinnon :

> I just wanted to thank everyone for their help in getting my pet project
> further along, so that now I can announce that PharoLambda is now working
> with the V7 minimal image and also supports post mortem debugging by saving
> a zipped fuel context onto S3.
>
> This latter item is particularly satisfying as at a recent serverless
> conference (JeffConf) there was a panel where poor development tools on
> serverless platforms was highlighted as a real problem.
>
> In our community we’ve had these kinds of tools at our fingertips for ages
> - but I don’t think the wider development community has really noticed.
> Debugging something short lived like a Lambda execution is quite startling,
> as the current answer is “add more logging”, and we all know that sucks. To
> this end, I’ve created a little screencast showing this in action - and it
> was pretty cool because it was a real example I encountered when I got
> everything working and was trying my test application out.
>
> I’ve also put a bit of work into tuning the excellent GitLab CI tools, so
> that I can cache many of the artefacts used between different build runs
> (this might also be of interest to others using CI systems).
>
> The Gitlab project is on: https://gitlab.com/macta/PharoLambda
> And the screencast: https://www.youtube.com/watch?v=bNNCT1hLA3E
>
> Tim
>
>
> On 15 Jul 2017, at 00:39, Tim Mackinnon  wrote:
>
> Hi - I’ve been playing around with getting Pharo to run well on AWS
> Lambda. It’s early days, but I though it might be interesting to share what
> I’ve learned so far.
>
> Usage examples and code at https://gitlab.com/macta/PharoLambda
>
> With help from many of the folks here, I’ve been able to get a simple
> example to run in 500ms-1200ms with a minimal Pharo 6 image. You can easily
> try it out yourself. This seems slightly better than what the GoLang folks
> have been able to do.
>
> Tim
>
>
>

Re: [Pharo-users] [ANN] PharoLambda 1.5 - Pharo running on AWS Lambda now with saved Debug sessions via S3

[Tudor Girba]

+1

Doru


> On Aug 10, 2017, at 11:34 PM, Stephane Ducasse  
> wrote:
> 
> Tim
> 
> I definitively think that we could turn it into a Pharo success story
> or something that we can keep on the web site
> because it is really nice.
> 
> Stef
> 
> On Thu, Aug 10, 2017 at 3:47 PM, Tim Mackinnon  wrote:
>> I just wanted to thank everyone for their help in getting my pet project
>> further along, so that now I can announce that PharoLambda is now working
>> with the V7 minimal image and also supports post mortem debugging by saving
>> a zipped fuel context onto S3.
>> 
>> This latter item is particularly satisfying as at a recent serverless
>> conference (JeffConf) there was a panel where poor development tools on
>> serverless platforms was highlighted as a real problem.
>> 
>> In our community we’ve had these kinds of tools at our fingertips for ages -
>> but I don’t think the wider development community has really noticed.
>> Debugging something short lived like a Lambda execution is quite startling,
>> as the current answer is “add more logging”, and we all know that sucks. To
>> this end, I’ve created a little screencast showing this in action - and it
>> was pretty cool because it was a real example I encountered when I got
>> everything working and was trying my test application out.
>> 
>> I’ve also put a bit of work into tuning the excellent GitLab CI tools, so
>> that I can cache many of the artefacts used between different build runs
>> (this might also be of interest to others using CI systems).
>> 
>> The Gitlab project is on: https://gitlab.com/macta/PharoLambda
>> And the screencast: https://www.youtube.com/watch?v=bNNCT1hLA3E
>> 
>> Tim
>> 
>> 
>> On 15 Jul 2017, at 00:39, Tim Mackinnon  wrote:
>> 
>> Hi - I’ve been playing around with getting Pharo to run well on AWS Lambda.
>> It’s early days, but I though it might be interesting to share what I’ve
>> learned so far.
>> 
>> Usage examples and code at https://gitlab.com/macta/PharoLambda
>> 
>> With help from many of the folks here, I’ve been able to get a simple
>> example to run in 500ms-1200ms with a minimal Pharo 6 image. You can easily
>> try it out yourself. This seems slightly better than what the GoLang folks
>> have been able to do.
>> 
>> Tim
>> 
>> 
> 

--
www.tudorgirba.com
www.feenk.com

"Reasonable is what we are accustomed with."

Re: [Pharo-users] [ANN] PharoLambda 1.5 - Pharo running on AWS Lambda now with saved Debug sessions via S3

[Tudor Girba]

Very nice work, Tim!

It is quite impressive what you could do within a short amount of time 
(essentially since PharoDays). Please do keep this up.

Cheers,
Doru


> On Aug 10, 2017, at 3:47 PM, Tim Mackinnon  wrote:
> 
> I just wanted to thank everyone for their help in getting my pet project 
> further along, so that now I can announce that PharoLambda is now working 
> with the V7 minimal image and also supports post mortem debugging by saving a 
> zipped fuel context onto S3.
> 
> This latter item is particularly satisfying as at a recent serverless 
> conference (JeffConf) there was a panel where poor development tools on 
> serverless platforms was highlighted as a real problem.
> 
> In our community we’ve had these kinds of tools at our fingertips for ages - 
> but I don’t think the wider development community has really noticed. 
> Debugging something short lived like a Lambda execution is quite startling, 
> as the current answer is “add more logging”, and we all know that sucks. To 
> this end, I’ve created a little screencast showing this in action - and it 
> was pretty cool because it was a real example I encountered when I got 
> everything working and was trying my test application out.
> 
> I’ve also put a bit of work into tuning the excellent GitLab CI tools, so 
> that I can cache many of the artefacts used between different build runs 
> (this might also be of interest to others using CI systems).
> 
> The Gitlab project is on: https://gitlab.com/macta/PharoLambda
> And the screencast: https://www.youtube.com/watch?v=bNNCT1hLA3E
> 
> Tim
> 
> 
>> On 15 Jul 2017, at 00:39, Tim Mackinnon  wrote:
>> 
>> Hi - I’ve been playing around with getting Pharo to run well on AWS Lambda. 
>> It’s early days, but I though it might be interesting to share what I’ve 
>> learned so far.
>> 
>> Usage examples and code at https://gitlab.com/macta/PharoLambda
>> 
>> With help from many of the folks here, I’ve been able to get a simple 
>> example to run in 500ms-1200ms with a minimal Pharo 6 image. You can easily 
>> try it out yourself. This seems slightly better than what the GoLang folks 
>> have been able to do.
>> 
>> Tim
> 

--
www.tudorgirba.com
www.feenk.com

"Quality cannot be an afterthought."

[Pharo-users] Thread-safe initialization of class state (was Re: Threads safety in Pharo)

[monty]

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" 
> To: "Any question about pharo is welcome" 
> 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  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
> >  wrote:
> >>
> >>
> >>
> >> -- Forwarded message --
> >> From: Alidra Abdelghani 
> >> To: pharo-users@lists.pharo.org
> >> Cc: "Stéphane Ducasse" , farid arfi
> >> 
> >> 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
> >>
> >>
> >>
> >
>