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

Re: [Pharo-dev] Path * '' vs. Path workingDirectory

by Alistair Grant

Hi Guille, Thanks for your reply. On Mon, Aug 14, 2017 at 01:44:41PM +0200, Guillermo Polito wrote: > > > On Sun, Aug 13, 2017 at 5:54 PM, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > Hi All, > > Is there any practical difference between (Path * '') and (Path > workingDirectory)? > > > Being strict, Path workingDirectory does not make any sense. A path is relative > or absolute. True, but Path is considered internal, so users shouldn't normally be calling Path>>workingDirectory. I'm asking because the patch I'm preparing to improve canonicalisation affects the creation of the path in some instances ('.' asFileReference used to have a path with an empty segment, now it has Path workingDirectory). Just for the record :-) Path workingDirectory isRelative " true" > And it is relative to some other path. Right, Pharo defines the image directory as the working directory (although https://github.com/pharo-project/pharo/pull/92 will change that to the more common shell interpretation of current working directory). > I'd expect that Path workingDirectory gives you an absolute path to the current > working directory,,, But the path doesn't have a file system to resolve against. Although even FileLocator workingDirectory gives a relative path. Thanks again, Alistair > Their internal representation is different: > > - (Path * '') has one empty segment > - Path workingDirectory has no segments > > But as far as I can tell they are otherwise the same: > > > | fs frEmpty frWD | > > fs := FileSystem disk. > frEmpty := FileReference fileSystem: fs path: (Path * ''). > frWD := FileReference fileSystem: fs path: Path workingDirectory. > String streamContents: [ :stream | > stream > << 'frEmpty: '; > << frEmpty printString; cr; > << 'frWD: '; > << frWD printString; cr; > << '= : '; > << (frEmpty absolutePath = frWD absolutePath) printString; cr. > ] > > 'frEmpty: "File @ " > frWD: "File @ ." > = : true > ' > > > Cheers, > Alistair > > > > > > -- > Guille Polito > [CNRS-filaire] > > Research Engineer > > French National Center for Scientific Research - http:// > www.cnrs.fr > > > > Web: http://guillep.github.io > > Phone: +33 06 52 70 66 13 >

Aug. 14, 2017

Re: [Pharo-dev] Trying to build Mac VM - ld: library not found for -lssl

by Nicolas Cellier

Reminder: i should update the readme to explain solution 2 as commented at https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/fb61b60bda7065a52d… But I need to understand first why/how the older SDK is used (no time yet...) Of course, volunteers and good will are welcome :) 2017-08-14 16:06 GMT+02:00 Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com>: > Hi, > This is a known problem on Sierra. > There are two possible workaround: > 1) locate the Xcode lib repository and copy /usr/lib/libssl.* there > The entire procedure is explained in a Readme > see https://github.com/OpenSmalltalk/opensmalltalk- > vm/blob/Cog/build.macos32x86/HowToBuild > 2) install older SDK - for example via XcodeLegacy - > https://github.com/devernay/xcodelegacy > The second worked for me, though I don't remember specifying usage of an > older SDK anywhere > > 2017-08-14 15:38 GMT+02:00 Todd Blanchard <tblanchard(a)mac.com>: > >> Git cloned, cd to build.macosxxx/pharo.cog.spur >> >> ./mvm -A >> >> Either 32 or 64 bit builds dies trying to build libSqueakSSL with library >> not found for -lssl. >> >> Homebrew doesn't seem to have an entry for libssl. Stumped. >> >> -Todd Blanchard >> > >

Aug. 14, 2017

Re: [Pharo-dev] Trying to build Mac VM - ld: library not found for -lssl

by Nicolas Cellier

Hi, This is a known problem on Sierra. There are two possible workaround: 1) locate the Xcode lib repository and copy /usr/lib/libssl.* there The entire procedure is explained in a Readme see https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/build.macos32x86… 2) install older SDK - for example via XcodeLegacy - https://github.com/devernay/xcodelegacy The second worked for me, though I don't remember specifying usage of an older SDK anywhere 2017-08-14 15:38 GMT+02:00 Todd Blanchard <tblanchard(a)mac.com>: > Git cloned, cd to build.macosxxx/pharo.cog.spur > > ./mvm -A > > Either 32 or 64 bit builds dies trying to build libSqueakSSL with library > not found for -lssl. > > Homebrew doesn't seem to have an entry for libssl. Stumped. > > -Todd Blanchard >

Aug. 14, 2017

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

by Esteban Lorenzano

again, I think this is a discussion for pharo-dev. Please keep it there (is good discussion, btw ;) ). What about my proposal of including a tiny PetitParser? (it would be âInfimeParserâ :P) Esteban > On 14 Aug 2017, at 11:10, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi Tim, > > The main benefit of relying on Pillar is that we control its syntax and can easily extend it for our purposes. Also, there was quite a bit of engineering invested in it, and even though we still need to improve it, there exists a pipeline that allows people to quickly publish books. > > The figure embedding problem is one example of the need to customize the syntax and behavior, but this extensibility will become even more important for supporting the idea of moving the documentation inside the image. For example, the ability to refer to a class, method or other artifacts will be quite relevant soon especially that the editor will be able to embed advanced elements inside the text. > > Cheers, > Doru > > >> On Aug 14, 2017, at 10:46 AM, Tim Mackinnon <tim(a)testit.works> wrote: >> >> Hi Stef - I think yourâs is a fair requirement (in fact I hit something similar when doing a static website using a JS markdown framework - and this is why I mentioned Kramdown which adds a few extras to regular markdown - but it feels like it goes a bit too far). >> >> My next item on my learning todo list was to try and replace that JS generator with something from Smalltalk - so I think we can possibly come up with something that ticks all the right boxes (Iâd like to try anyway). >> >> Iâll keep working away on it and compare notes with you. I think with Pillar, it was more that things like headers, bold and italics are similar concepts but just use different characters - so I keep typing the wrong thing and getting frustrated particularly when we embrace Git and readme.md is in markdown. >> >> >> Tim >> >>> On 13 Aug 2017, at 20:08, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >>> >>> Hi tim >>> >>> I personally do not care much about the syntax but I care about what I >>> can do with it >>> (ref, cite, ... ) >>> I cannot write books in markdown because reference to figures!!!!!! >>> were missing. >>> >>> And of course a parser because markdown is not really nice to parse >>> and I will not write a parser because I have something else to do. I >>> want to make pillar smaller, simpler, nicer. >>> >>> Now if someone come up with a parser that parse for REAL a markdown >>> that can be extended with decent behavior (figure reference, section >>> reference, cite) and can be extended because there are many things >>> that can be nice to have (for example I want to be able to write the >>> example below) and emit a PillarModel (AST) we can talk to have >>> another syntax for Pillar but not before. >>> >>> [[[test >>> 2+3 >>>>>> 5 >>> ]]] >>> >>> and being able to verify that the doc is in sync. >>> >>> >>> Stef >>> >>> >>> >>> On Sat, Aug 12, 2017 at 12:37 AM, Tim Mackinnon <tim(a)testit.works> wrote: >>>> Of course, I/we recognise and appreciate all the work that's gone into docs in pillar - but I think it should be reasonably straightforward to write a converter as it is pretty closely related from what I have seen. >>>> >>>> So I don't make the suggestion flippantly, and would want to help write a converter and get us to a common ground where we can differentiate on the aspects where we can excel. >>>> >>>> Tim >>>> >>>> Sent from my iPhone >>>> >>>>> On 11 Aug 2017, at 23:21, Peter Uhnak <i.uhnak(a)gmail.com> wrote: >>>>> >>>>> A long time issue with Markdown was that there was no standardization (and when I used Pillar's MD export ~2 years ago it didn't work well). >>>>> >>>>> However CommonMark ( http://spec.commonmark.org/0.28/ ) has become the de-facto standard, so it would make sense to support it bidirectionally with Pillar. >>>>> >>>>>> The readme.md that Peter is talking about is gfm markdown >>>>> >>>>> Well, technically it is just a CommonMark, as I am not using any github extensions. >>>>> (Github uses CommonMarks and adds just couple small extensions.) >>>>> >>>>> Peter >>>>> >>>> >>>> >>> >> >> > > -- > www.tudorgirba.com > www.feenk.com > > âLive like you mean it." > >

Aug. 14, 2017

Trying to build Mac VM - ld: library not found for -lssl

by Todd Blanchard

Git cloned, cd to build.macosxxx/pharo.cog.spur ./mvm -A Either 32 or 64 bit builds dies trying to build libSqueakSSL with library not found for -lssl. Homebrew doesn't seem to have an entry for libssl. Stumped. -Todd Blanchard

Aug. 14, 2017

Re: [Pharo-dev] PharoJS crashes at first try

by Norbert Hartl

> Am 13.08.2017 um 21:19 schrieb Frank-B <frank.berger.software(a)web.de>: > > Stephane, > > thank you for your open words. > > 1) No I am NOT Frank Lesser and I will communicate this even clearer in a > personal email to you. > > 2) I had tried to make very clear that I see the Pharo project very positive > and my critics as being (at least intended) constructive. > > 3) I never care about my reputation. I only care about truth, facts and a > sincere appearance. Few people appreciate this attitude and I do not value > the others all too high or seriously. Unfortunately, we all have to live in > these timees of universal lies, deception and fraud. You probably know the > good German word "LÃ¼genpresse" and my version is: "the current Zeitgeist > equals LÃ¼genpresse". > "LÃ¼genpresse" is not a good german word. It is a propaganda attempt by nationalists and used elsewhere by equally narrow minded people. Norbert > 4) I have some good, solid and unusual ideas how I could improve the Pharo > project considerably but for several reasons it is much to early to discuss > this. It will take another 2-3 years and I will definitely come back when > the time has come on my side. > > 5) As a contributor in the general Pharo sense I am currently neither > capable (working 85-100 hours a week on my projects) nor eligible and the > latter reason is not simple to explain, so I leave it at that for now. > > Frank > > > > > > -- > View this message in context: http://forum.world.st/PharoJS-crashes-at-first-try-tp4960686p4960770.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Aug. 14, 2017

Re: [Pharo-dev] Path * '' vs. Path workingDirectory

by Guillermo Polito

On Sun, Aug 13, 2017 at 5:54 PM, Alistair Grant <akgrant0710(a)gmail.com> wrote: > Hi All, > > Is there any practical difference between (Path * '') and (Path > workingDirectory)? > Being strict, Path workingDirectory does not make any sense. A path is relative or absolute. And it is relative to some other path. I'd expect that Path workingDirectory gives you an absolute path to the current working directory,,, > Their internal representation is different: > > - (Path * '') has one empty segment > - Path workingDirectory has no segments > > But as far as I can tell they are otherwise the same: > > > | fs frEmpty frWD | > > fs := FileSystem disk. > frEmpty := FileReference fileSystem: fs path: (Path * ''). > frWD := FileReference fileSystem: fs path: Path workingDirectory. > String streamContents: [ :stream | > stream > << 'frEmpty: '; > << frEmpty printString; cr; > << 'frWD: '; > << frWD printString; cr; > << '= : '; > << (frEmpty absolutePath = frWD absolutePath) printString; cr. > ] > > 'frEmpty: "File @ " > frWD: "File @ ." > = : true > ' > > > Cheers, > Alistair > > -- Guille Polito Research Engineer French National Center for Scientific Research - *http://www.cnrs.fr* <http://www.cnrs.fr> *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Aug. 14, 2017

Fwd: [squeak-dev] Anybody using Orca Smalltalk to JavaScript?

by H. Hirzel

---------- Forwarded message ---------- From: Robert Hirschfeld <robert.hirschfeld(a)gmx.net> Date: Mon, 14 Aug 2017 12:06:45 +0200 Subject: Re: [squeak-dev] [Pharo-dev] Anybody using Orca Smalltalk to JavaScript? To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> http://www.hpi.uni-potsdam.de/swa/publications/media/ThamsenGulenkoPerschei… > On 14 Aug 2017, at 11:02, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: > > On 8/14/17, Frank-B <frank.berger.software(a)web.de> wrote: > [snip] >> There are currently three "candidates": ST2JS, Orca and PharoJS. >> >> As you can read in the second thread (see link above) the PharoJS image >> failed at first attempt. Therefore my question, are you aware of a working >> image? >> >> Second, is there anywhere some detailed information available about what >> PharoJS does and, at least basically, how it's done? (Side-remark: This >> part >> is excellent for Orca, I recommend the Orca papers. Brilliant concepts!) >> > > Hello Frank > > A question: you wrote earlier about an 'excellent' Orca documentation? > Where did you find it? > > http://www.hpi.uni-potsdam.de/hirschfeld/projects/orca/index.html > has a demo video and installation instructions for server (Squeak) > and client (JavaScript) > > Or is it this paper [1] you are referring to? > > Regards > Hannes > > [1] > http://squeak.org/research/ > > Lauritz Thamsen, Anton Gulenko, Michael Perscheid, Robert Krahn, > Robert Hirschfeld, and David A. Thomas. âOrca: A Single-Language Web > Framework for Collaborative Development.â In Proceedings of the > Conference on Creating, Connecting and Collaborating through Computing > (C5) 2012, 45â52. IEEE, 2012. >

Aug. 14, 2017

Issue 20309 - Startup should run always in a fresh process

by Guillermo Polito

Hi all, I'm proposing a kind-of critical change that I believe is very good for the health of the system: I want that the startup of the system runs in maximum priority and becomes non-interruptable. Right now, when you save your image, the shutdown and startup are run in the same priority than the process that triggered the save (usually the ui or the command line, priority 40). This can cause lots of problems and race conditions: processes with higher priorities can interrupt the shutdown/startup and try to do something while the system is unstable. As a side effect also, when you use extensively the command line, you start stacking startup contexts from old sessions: ... session 3 ctxt 4 <- This guy makes a save and a new session starts session 3 ctxt 3 session 3 ctxt 2 session 3 ctxt 1 session 2 ctxt 4 <- This guy makes a save and a new session starts session 2 ctxt 3 session 2 ctxt 2 session 2 ctxt 1 session 1 ctxt 4 <- This guy makes a save and a new session starts session 1 ctxt 3 session 1 ctxt 2 session 1 ctxt 1 Old contexts are never collected, and the objects they referenced neither. To fix these two problems I propose to do every image save/session start in a new process in maximum priority. That way, other process should not be able to interrupt the startup process. Moreover, every session shutdown/startup should happen in a new clean process, to avoid the session stacking. For normal users, this should have no side effect at all. This change will have a good impact on people working on the debugger and the stack such as fueling-out the stack because they will have a cleaner stack. There is however a side-effect/design point to consider: startup actions should be quick to run. If a startup action requires to run a long-running action such as starting a server or managing a command line action, that should run in a separate process with lower priority (usually userPriority). In other words, the startup action should create a new process managing its action. If you want to review (and I'd be glad) Pull request: https://github.com/pharo-project/pharo/pull/198 Fogbugz issue: https://pharo.fogbugz.com/f/cases/20309 Current validation going on: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2… Guille -- Guille Polito Research Engineer French National Center for Scientific Research - *http://www.cnrs.fr* <http://www.cnrs.fr> *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Aug. 14, 2017

Re: [Pharo-dev] [Vm-dev] vm crash when using rairedTo: with fractions

by Tim Mackinnon

Itâs a fair point - I guess if enough things crop up, then a 6.2 release gets contemplated. Tim > On 14 Aug 2017, at 10:29, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > Hi Tim, > I'd say: is this a showstopper? > How often do you raise a Fraction to the power of another Fraction with large denominator (> 10000)? > Or is it used indirectly by some kind of Framework? > > If yes then open a pharo bug entry and mark for 6.x, else just wait 7.x... > > Nicolas > > 2017-08-14 10:49 GMT+02:00 Tim Mackinnon <tim(a)testit.works <mailto:tim@testit.works>>: > Is there a way for this to get back into 6.1 - so we can shoot for a stable 6.x version that will last us for a year while 7.x is under development? > > Iâm not familiar with how point release are handled in Pharo, and I get the impression that this is going to be a slightly rockier year as there have been some pretty revolutionary changes made to get us here. > > As its a vm change does this mean we get 6.2 queued up somehow? > > Tim > > > On 13 Aug 2017, at 20:12, Stephane Ducasse <stepharo.self(a)gmail.com <mailto:stepharo.self@gmail.com>> wrote: > > > > Tx eliot. > > > > > > On Fri, Aug 11, 2017 at 12:55 AM, Eliot Miranda <eliot.miranda(a)gmail.com <mailto:eliot.miranda@gmail.com>> wrote: > >> Hi Andrei, > >> > >> On Thu, Aug 10, 2017 at 3:02 AM, Andrei Chis <chisvasileandrei(a)gmail.com <mailto:chisvasileandrei@gmail.com>> > >> wrote: > >>> > >>> > >>> Hi, > >>> > >>> I was executing this code '(2009/2000) ** (3958333/100000)' with the > >>> Pharo6.1 distribution and the vm crashed with she stack attached below. > >>> Tried it on both mac and windows 10. > >>> Seems that #raisedTo: has a special case for fractions that ends up > >>> calling #nthRoot: like '2009 nthRoot: 100000' leading to the crash. > >> > >> > >> The plugin is now fixed; see VMMaker.oscog-eem.2262. I'll generate code > >> soon (am debugging something you're familiar with that takes several hours > >> to run and don't want to generate sources while it's running). But I'm glad > >> you've found a better way! This case creates 600k byte large integers and > >> takes forever to run :-) > >> > >>> > >>> Cheers, > >>> Andrei > >>> > >>> > >>> 0xaddeac M LargePositiveInteger(Integer)>quo: 0x314093e8: a(n) > >>> LargePositiveInteger > >>> 0xaddec8 M LargePositiveInteger(LargeInteger)>quo: 0x314093e8: a(n) > >>> LargePositiveInteger > >>> 0xaddee8 M LargePositiveInteger(Integer)>// 0x314093e8: a(n) > >>> LargePositiveInteger > >>> 0xaddf04 M LargePositiveInteger(LargeInteger)>// 0x314093e8: a(n) > >>> LargePositiveInteger > >>> 0xaddf34 I LargePositiveInteger(Integer)>nthRootTruncated: 0x30cc8350: > >>> a(n) LargePositiveInteger > >>> 0xaddf5c I LargePositiveInteger(Integer)>nthRootRounded: 0x30cc8350: a(n) > >>> LargePositiveInteger > >>> 0xaddf88 I SmallInteger(Integer)>nthRoot: 0xfb3=2009 > >>> 0xaddfb4 I Fraction>nthRoot: 0x4f9a940: a(n) Fraction > >>> 0xaddfd8 I Fraction(Number)>raisedTo: 0x4f9a940: a(n) Fraction > >>> 0xaddffc I Fraction(Number)>** 0x4f9a940: a(n) Fraction > >>> 0xade018 M UndefinedObject>DoIt 0x5fe5d00: a(n) UndefinedObject > >>> 0xade048 I OpalCompiler>evaluate 0x4f9a998: a(n) OpalCompiler > >>> 0xade074 I RubSmalltalkEditor>evaluate:andDo: 0x305e5878: a(n) > >>> RubSmalltalkEditor > >>> 0xade09c I RubSmalltalkEditor>highlightEvaluateAndDo: 0x305e5878: a(n) > >>> RubSmalltalkEditor > >>> 0xade0b8 M > >>> GLMMorphicPharoScriptRenderer(GLMMorphicPharoCodeRenderer)>popupPrint > >>> 0x3062fdc8: a(n) GLMMorphicPharoScri > >>> enderer > >>> 0xade0d8 I MorphicAlarm(MessageSend)>value 0x4f9ab20: a(n) MorphicAlarm > >>> 0xade0f4 M MorphicAlarm>value: 0x4f9ab20: a(n) MorphicAlarm > >>> 0xade114 M WorldState>triggerAlarmsBefore: 0x71bb5e0: a(n) WorldState > >>> 0xade140 M WorldState>runLocalStepMethodsIn: 0x71bb5e0: a(n) WorldState > >>> 0xade164 M WorldState>runStepMethodsIn: 0x71bb5e0: a(n) WorldState > >>> 0xade180 M WorldMorph>runStepMethods 0x6ab7778: a(n) WorldMorph > >>> 0xade198 M WorldState>doOneCycleNowFor: 0x71bb5e0: a(n) WorldState > >>> 0xade1b4 M WorldState>doOneCycleFor: 0x71bb5e0: a(n) WorldState > >>> 0xade1d0 M WorldMorph>doOneCycle 0x6ab7778: a(n) WorldMorph > >>> 0xade1e8 M WorldMorph class>doOneCycle 0x6a9f960: a(n) WorldMorph class > >>> 0xade200 M [] in MorphicUIManager>spawnNewProcess 0x2cc88718: a(n) > >>> MorphicUIManager > >>> 0xade220 I [] in BlockClosure>newProcess 0x2f178150: a(n) BlockClosure > >>> > >> > >> > >> > >> -- > >> _,,,^..^,,,_ > >> best, Eliot > > > > >

Aug. 14, 2017