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

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

by 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 <stepharo.self(a)gmail.com> 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 <tedvga(a)gmail.com> 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-tp4957969p… >> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >> >

Aug. 11, 2017

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

by 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-tp4957969p… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Aug. 11, 2017

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

by 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 <tedvga(a)gmail.com> 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-tp4957969p… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >

Aug. 11, 2017

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

by 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

Aug. 11, 2017

Re: [Pharo-users] VM dev and compilation

by Stephane Ducasse

Hi bruno Welcome. Do not hesitate to ask questions. Stef On Fri, Aug 11, 2017 at 4:49 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > On 11 Aug 2017, at 12:08, Bruno Durin <bruno.durin(a)gmail.com> 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 > > >

Aug. 11, 2017

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

by 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. <cyril.ferlicot(a)gmail.com> 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 >

Aug. 11, 2017

Re: [Pharo-users] FLSerializer in Pharo 6.1

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

Aug. 11, 2017

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

by 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

Aug. 11, 2017

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

by 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. <cyril.ferlicot(a)gmail.com> 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 >

Aug. 11, 2017