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

Re: [Pharo-dev] eventual crashes pharo vm

by Stephane Ducasse

Thanks I will try it on my mac Sierra and report. Stef On Tue, Aug 15, 2017 at 2:59 AM, henry <henry(a)callistohouse.club> wrote: > Yes, here it is, in Pharo6.1, as mentioned previously. Just run the > eventual_test tests and it will exit on Ubuntu 32-bit. > > https://ufile.io/pa9ym > > Thank you, > - HH > > > -------- Original Message -------- > Subject: Re: [Pharo-dev] eventual crashes pharo vm > Local Time: August 14, 2017 7:45 PM > UTC Time: August 14, 2017 11:45 PM > From: eliot.miranda(a)gmail.com > To: henry <henry(a)callistohouse.club> > Pharo Development List <pharo-dev(a)lists.pharo.org> > > Hi Henry, > > On Mon, Aug 14, 2017 at 3:58 PM, henry <henry(a)callistohouse.club> wrote: >> >> If you need more info, please ask and I will try to get ths to you. > > > yes, if you can make the image & changes available somewhere that would be > nice. Thanks. > >> >> >> >> - HH >> >> >> -------- Original Message -------- >> Subject: Re: [Pharo-dev] eventual crashes pharo vm >> Local Time: August 14, 2017 6:54 PM >> UTC Time: August 14, 2017 10:54 PM >> From: henry(a)callistohouse.club >> To: Eliot Miranda <eliot.miranda(a)gmail.com> >> Pharo Development List <pharo-dev(a)lists.pharo.org> >> >> Yes, it is pharo 6.1 32-bit, standard image with Cryptography loaded, on >> ubuntu 32-bit. Here is the vm version info below. >> >> I loaded this package and ran the tests and it >> exited...http://www.squeaksource.com/TurquoiseTesting/eventual_test-hh.4.mcz >> >> Here is the pharo 6.1 version... >> 5.0-201707201942 Thu Jul 20 20:49:40 UTC 2017 gcc 4.6.3 [Production Spur >> VM] >> CoInterpreter VMMaker.oscog-eem.2254 uuid: >> 4f2c2cce-f4a2-469a-93f1-97ed941df0ad Jul 20 2017 >> StackToRegisterMappingCogit VMMaker.oscog-eem.2252 uuid: >> 2f3e9b0e-ecd3-4adf-b092-cce2e2587a5c Jul 20 2017 >> VM: 201707201942 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ >> Date: Thu Jul 20 12:42:21 2017 -0700 $ >> Plugins: 201707201942 >> https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ >> Linux testing-gce-a2a4bdab-02ca-439f-bf6e-83038885be71 3.13.0-115-generic >> #162~precise1-Ubuntu SMP Fri Mar 24 16:47:06 UTC 2017 i686 i686 i386 >> GNU/Linux >> plugin path: /usr/local/bin/../lib/pharo/5.0-201707201942 [default: >> /usr/local/lib/pharo/5.0-201707201942/] >> >> - HH >> >> >> -------- Original Message -------- >> Subject: Re: [Pharo-dev] eventual crashes pharo vm >> Local Time: August 14, 2017 6:47 PM >> UTC Time: August 14, 2017 10:47 PM >> From: eliot.miranda(a)gmail.com >> To: henry <henry(a)callistohouse.club>, Pharo Development List >> <pharo-dev(a)lists.pharo.org> >> >> Hi Henry, >> >> On Sun, Aug 13, 2017 at 5:08 AM, henry <henry(a)callistohouse.club> wrote: >>> >>> Hi all. I was testing with this eventual_test package and it blows up the >>> pharo 6.1 vm. I'd welcome pointers >>> >>> http://www.squeaksource.com/TurquoiseTesting.html >> >> >> Care to share how to reproduce the crash? Image version, VM version & >> word size, OS, Smalltalk expression, supporting files, if any. >> >> _,,,^..^,,,_ >> best, Eliot >> >> >> > > > > -- > _,,,^..^,,,_ > best, Eliot > >

Aug. 15, 2017

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

by Todd Blanchard

That did it. Thanks! > On Aug 14, 2017, at 7:10 AM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > Reminder: i should update the readme to explain solution 2 as commented at > https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/fb61b60bda7065a52d… <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 <mailto:nicolas.cellier.aka.nice@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… <https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/build.macos32x86…> > 2) install older SDK - for example via XcodeLegacy - https://github.com/devernay/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 <mailto:tblanchard@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. 15, 2017

Re: [Pharo-dev] FileSystem fix integration

by Stephane Ducasse

Tx for the information. I will focus on 20307 then On Tue, Aug 15, 2017 at 11:07 AM, Alistair Grant <akgrant0710(a)gmail.com> wrote: > Hi Stef, > > On Tue, Aug 15, 2017 at 10:04:31AM +0200, Stephane Ducasse wrote: >> tx a lot for the summary, this is super useful :) >> I will over them later (because I must work on my new lectures :). >> >> Stef > > I've just realised that: > > - https://pharo.fogbugz.com/f/cases/20165/Support-segment-path-printing > > has merge conflicts, and that #20307 adds more merge conflicts. > > The easiest thing to do is to defer this issue until after #20307 has > been merged. I'll then update the patch to remove the merge conflicts > and resubmit. > > Cheers, > Alistair > > > > >> On Tue, Aug 15, 2017 at 7:58 AM, Alistair Grant <akgrant0710(a)gmail.com> wrote: >> > Hi Stef, >> > >> > I've added the PR to fix automatic canonicalisation of path references >> > to the parent directory (".."): >> > >> > - https://pharo.fogbugz.com/f/cases/20307/File-names-should-not-be-canonicali… >> > - https://github.com/pharo-project/pharo/pull/206 >> > >> > Other open issues (to help keep track): >> > >> > - https://pharo.fogbugz.com/f/cases/20165/Support-segment-path-printing >> > - https://pharo.fogbugz.com/f/cases/18084/FileReference-EnsureCreateFile >> > https://github.com/pharo-project/pharo/pull/133 >> > - https://pharo.fogbugz.com/f/cases/19609/FileReference-base-should-be-before… >> > https://github.com/pharo-project/pharo/pull/137 >> > - https://pharo.fogbugz.com/f/cases/20294/Add-FileAttributesPlugin-to-the-lin… >> > This is the first step in fixing FileReference>>isSymlink and >> > extending support for all file attributes returned by stat() and >> > lstat(). >> > The parent issue is: >> > https://pharo.fogbugz.com/f/cases/18279/isSymlink-seems-to-be-broken-on-Lin… >> > >> > >> > Since #13217 has been accepted, #18042 and its associated PR should be >> > closed (won't fix): >> > >> > - https://pharo.fogbugz.com/f/cases/18042 >> > - https://github.com/pharo-project/pharo/pull/75 >> > >> > >> > Thanks! >> > Alistair >> > >> > >> > >> > On Thu, Aug 10, 2017 at 08:23:49PM +0000, Alistair Grant wrote: >> >> Hi Stef, >> >> >> >> On Wed, Aug 09, 2017 at 10:12:17PM +0200, Stephane Ducasse wrote: >> >> > Hi alistair >> >> > >> >> > I went on fogbugz to find the fix to be included and I'm not sure not >> >> > that find them. >> >> > I looked for FileSystem. >> >> > >> >> > I found >> >> > - https://pharo.fogbugz.com/f/cases/20165/Support-segment-path-printing >> >> > >> >> > - https://pharo.fogbugz.com/f/cases/18084/FileReference-EnsureCreateFile >> >> > https://github.com/pharo-project/pharo/pull/133 >> >> > >> >> > - https://pharo.fogbugz.com/f/cases/19609/FileReference-base-should-be-before… >> >> > https://github.com/pharo-project/pharo/pull/137 >> >> > >> >> > Did I miss some others? >> >> > >> >> > Stef >> >> >> >> - https://pharo.fogbugz.com/f/cases/20294/Add-FileAttributesPlugin-to-the-lin… >> >> This is the first step in fixing FileReference>>isSymlink and >> >> extending support for all file attributes returned by stat() and >> >> lstat(). >> >> The parent issue is: >> >> https://pharo.fogbugz.com/f/cases/18279/isSymlink-seems-to-be-broken-on-Lin… >> >> >> >> Just for completeness, the two issues relating to FileReference>>/: >> >> >> >> - https://pharo.fogbugz.com/f/cases/13217/FS-basename-with-compound-path-stri… >> >> - https://github.com/pharo-project/pharo/pull/192 >> >> - https://pharo.fogbugz.com/f/cases/18042 >> >> - https://github.com/pharo-project/pharo/pull/75 >> >> >> >> >> >> Cheers, >> >> Alistair >> > >> >

Aug. 15, 2017

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

by Ben Coman

On Tue, Aug 15, 2017 at 12:54 AM, Esteban A. Maringolo <emaringolo(a)gmail.com > wrote: > You hit several birds with one single mail. > > 2017-08-14 13:34 GMT-03:00 Tim Mackinnon <tim(a)testit.works>: > > Jimmie et al. nicely reasoned arguments - and Doru's point about > controlling > > the syntax is an interesting one that I hadnât thought about. > > > > Personally, I find having too many similar syntaxâs confusing - > contributing > > to things is hard enough - having to remember that its !! Instead of ## > and > > ââ instead of ** is just frustrating for me. > > +1 > Not only for docs, most platforms like Slack/Discord share the syntax, > so now I'm getting "muscle memory" when typing literals using the > backtick (`) character, quoting with > or pasting snippets using ``` > +1. So I've posted this before... https://www.joelonsoftware.com/2000/06/03/strategy-letter-iii-let-me-go-bac… describing that "The only strategy in getting people to switch to your product is to eliminate barriers" But more... the best reason for Pillar to support a Markdown-ish syntax, is that when we scratch-our-own-itch (nominally for Pillar) to build the best damn markup-editor ever (because we can!) - if this happened to support Markdown it can draw in Markdown-non-Pharo users (because its the best editor ever!). Those users later want to make modifications, and now have a *reason* to learn Pharo... ahHaA! now you see the cunning plan... So don't just promote to people "hey come and play with this cool toy of ours (Pharo)." Instead give them a toy they *already-want* (Markdown editor) and then when they want to change the batteries, they *need* to use our special screwdriver (Pharo). cheers -ben > > > Sure, maybe we were first with Pillar, but for me, lots of programming > is in > > other languages, and I use Smalltalk where I can, and a hybrid of > multiple > > languages and projects is often the reality - so a lowest common > denominator > > of Markdown is just easier. The fact that we are quite close to what our > > colleagues in other languages use (regardless of what Python has > chosen), is > > quite interesting. > > This helps building "bridges" with other communities. > > The language as a means of exchange is always the lowest common > denominator. > As long as it's "efficient enough" then I vote to use what other > communities use. > > > That said, if the community wants to stick to its gunâs thats fine - I > will > > probably still investigate how to use Commonmark for myself, and will > still > > contribute to Pillar docs where I can (and curse history) - but I think > we > > are long better off trying to join emerging standards where we can > > particularly if they arenât our core language thing. And it just makes it > > less frictionless for ourselves and newcomers. > > The "Not Invented Here" syndrome is strong among Smalltalkers, it's > important to be aware of this bias and think more than once whether > eating our own dogfood adds value to the core of what Pharo brings. > > I think we missed some good years fighting with our own SCM and in the > end git (or any other file based SCM) prevailed, even when it has > limitations. > > Pareto (80-20) for everything non-core business should be a guide. > > > Of course, if we were to move, we would need to translate a lot of > quality > > docs to a new format - but I would be up for contributing to that if that > > was a deciding factor. > > There are some Markdown exporters AFAIK, or it could be written. > > > Esteban A. Maringolo > >

Aug. 15, 2017

Re: [Pharo-dev] New line on command line

by Rajula Vineet

Hey Guille, I think I found the fix. But I would like to run by you first. I want to get a review before making a PR. In the method nextPut: in ZnCrProtableWriteStream, when a new line character is sent using 'OSPlatform current lineEnding', there isn`t any statement which satisfies in this nextPut:. So at the end where the character is checked if it`s a new line, when I added a ifFalse statement and added self newline. Full code is as follows nextPut: aCharacter (String crlf includes: aCharacter ) ifFalse: [ previous ifNotNil: [ self newLine ]. ^ stream nextPut: aCharacter ]. previous = Character cr ifTrue: [ self newLine ]. aCharacter ~= Character lf ifTrue: [ previous := aCharacter ] ifFalse:[ self newLine ]. The only change is the last line. Rajula -- View this message in context: http://forum.world.st/New-line-on-command-line-tp4960327p4961385.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Aug. 15, 2017

Re: [Pharo-dev] Issue 20309 - Startup should run always in a fresh process

by Ben Coman

In case any of the shutdown/startup scripts use a delay, now or in the future, I'd first try at highestPriority-1 to avoid influence on the DelayScheduler. but then Eliot's suggestion to valueUnpreemptively may avoid that anyway. btw, what happens if an error occurs inside valueUnpreemptively? Does the normal priority debugger still get to run? cheers -ben On Mon, Aug 14, 2017 at 6:42 PM, Guillermo Polito <guillermopolito(a)gmail.com > wrote: > 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%20and% > 20branch%20Pipeline/view/change-requests/job/PR-198/ > > 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 <+33%206%2052%2070%2066%2013> >

Aug. 15, 2017

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

by Ben Coman

On Mon, Aug 14, 2017 at 4:49 PM, Tim Mackinnon <tim(a)testit.works> wrote: > 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? > We don't (yet) have a massive-cyber-corp backer, so with limited resources there are only limited point releases - usually only one, half-way to two-thirds through the year. But we already got 6.1, so I'm not sure affects things. Now the first rule is that fixes must go into the current dev branch and then backported. So get it into Pharo 7 and queue it up for (maybe) 6.2. cheers -ben > > Tim > > > On 13 Aug 2017, at 20:12, Stephane Ducasse <stepharo.self(a)gmail.com> > wrote: > > > > Tx eliot. > > > > > > On Fri, Aug 11, 2017 at 12:55 AM, Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: > >> Hi Andrei, > >> > >> On Thu, Aug 10, 2017 at 3:02 AM, Andrei Chis < > chisvasileandrei(a)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. 15, 2017

Re: [Pharo-dev] FileSystem fix integration

by Alistair Grant

Hi Stef, On Tue, Aug 15, 2017 at 10:04:31AM +0200, Stephane Ducasse wrote: > tx a lot for the summary, this is super useful :) > I will over them later (because I must work on my new lectures :). > > Stef I've just realised that: - https://pharo.fogbugz.com/f/cases/20165/Support-segment-path-printing has merge conflicts, and that #20307 adds more merge conflicts. The easiest thing to do is to defer this issue until after #20307 has been merged. I'll then update the patch to remove the merge conflicts and resubmit. Cheers, Alistair > On Tue, Aug 15, 2017 at 7:58 AM, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > Hi Stef, > > > > I've added the PR to fix automatic canonicalisation of path references > > to the parent directory (".."): > > > > - https://pharo.fogbugz.com/f/cases/20307/File-names-should-not-be-canonicali… > > - https://github.com/pharo-project/pharo/pull/206 > > > > Other open issues (to help keep track): > > > > - https://pharo.fogbugz.com/f/cases/20165/Support-segment-path-printing > > - https://pharo.fogbugz.com/f/cases/18084/FileReference-EnsureCreateFile > > https://github.com/pharo-project/pharo/pull/133 > > - https://pharo.fogbugz.com/f/cases/19609/FileReference-base-should-be-before… > > https://github.com/pharo-project/pharo/pull/137 > > - https://pharo.fogbugz.com/f/cases/20294/Add-FileAttributesPlugin-to-the-lin… > > This is the first step in fixing FileReference>>isSymlink and > > extending support for all file attributes returned by stat() and > > lstat(). > > The parent issue is: > > https://pharo.fogbugz.com/f/cases/18279/isSymlink-seems-to-be-broken-on-Lin… > > > > > > Since #13217 has been accepted, #18042 and its associated PR should be > > closed (won't fix): > > > > - https://pharo.fogbugz.com/f/cases/18042 > > - https://github.com/pharo-project/pharo/pull/75 > > > > > > Thanks! > > Alistair > > > > > > > > On Thu, Aug 10, 2017 at 08:23:49PM +0000, Alistair Grant wrote: > >> Hi Stef, > >> > >> On Wed, Aug 09, 2017 at 10:12:17PM +0200, Stephane Ducasse wrote: > >> > Hi alistair > >> > > >> > I went on fogbugz to find the fix to be included and I'm not sure not > >> > that find them. > >> > I looked for FileSystem. > >> > > >> > I found > >> > - https://pharo.fogbugz.com/f/cases/20165/Support-segment-path-printing > >> > > >> > - https://pharo.fogbugz.com/f/cases/18084/FileReference-EnsureCreateFile > >> > https://github.com/pharo-project/pharo/pull/133 > >> > > >> > - https://pharo.fogbugz.com/f/cases/19609/FileReference-base-should-be-before… > >> > https://github.com/pharo-project/pharo/pull/137 > >> > > >> > Did I miss some others? > >> > > >> > Stef > >> > >> - https://pharo.fogbugz.com/f/cases/20294/Add-FileAttributesPlugin-to-the-lin… > >> This is the first step in fixing FileReference>>isSymlink and > >> extending support for all file attributes returned by stat() and > >> lstat(). > >> The parent issue is: > >> https://pharo.fogbugz.com/f/cases/18279/isSymlink-seems-to-be-broken-on-Lin… > >> > >> Just for completeness, the two issues relating to FileReference>>/: > >> > >> - https://pharo.fogbugz.com/f/cases/13217/FS-basename-with-compound-path-stri… > >> - https://github.com/pharo-project/pharo/pull/192 > >> - https://pharo.fogbugz.com/f/cases/18042 > >> - https://github.com/pharo-project/pharo/pull/75 > >> > >> > >> Cheers, > >> Alistair > > >

Aug. 15, 2017

Re: [Pharo-dev] New line on command line

by Rajula Vineet

Oh ok sure. I will try my best. :) Rajula -- View this message in context: http://forum.world.st/New-line-on-command-line-tp4960327p4961307.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Aug. 15, 2017

Re: [Pharo-dev] FileSystem fix integration

by Stephane Ducasse

tx a lot for the summary, this is super useful :) I will over them later (because I must work on my new lectures :). Stef On Tue, Aug 15, 2017 at 7:58 AM, Alistair Grant <akgrant0710(a)gmail.com> wrote: > Hi Stef, > > I've added the PR to fix automatic canonicalisation of path references > to the parent directory (".."): > > - https://pharo.fogbugz.com/f/cases/20307/File-names-should-not-be-canonicali… > - https://github.com/pharo-project/pharo/pull/206 > > Other open issues (to help keep track): > > - https://pharo.fogbugz.com/f/cases/20165/Support-segment-path-printing > - https://pharo.fogbugz.com/f/cases/18084/FileReference-EnsureCreateFile > https://github.com/pharo-project/pharo/pull/133 > - https://pharo.fogbugz.com/f/cases/19609/FileReference-base-should-be-before… > https://github.com/pharo-project/pharo/pull/137 > - https://pharo.fogbugz.com/f/cases/20294/Add-FileAttributesPlugin-to-the-lin… > This is the first step in fixing FileReference>>isSymlink and > extending support for all file attributes returned by stat() and > lstat(). > The parent issue is: > https://pharo.fogbugz.com/f/cases/18279/isSymlink-seems-to-be-broken-on-Lin… > > > Since #13217 has been accepted, #18042 and its associated PR should be > closed (won't fix): > > - https://pharo.fogbugz.com/f/cases/18042 > - https://github.com/pharo-project/pharo/pull/75 > > > Thanks! > Alistair > > > > On Thu, Aug 10, 2017 at 08:23:49PM +0000, Alistair Grant wrote: >> Hi Stef, >> >> On Wed, Aug 09, 2017 at 10:12:17PM +0200, Stephane Ducasse wrote: >> > Hi alistair >> > >> > I went on fogbugz to find the fix to be included and I'm not sure not >> > that find them. >> > I looked for FileSystem. >> > >> > I found >> > - https://pharo.fogbugz.com/f/cases/20165/Support-segment-path-printing >> > >> > - https://pharo.fogbugz.com/f/cases/18084/FileReference-EnsureCreateFile >> > https://github.com/pharo-project/pharo/pull/133 >> > >> > - https://pharo.fogbugz.com/f/cases/19609/FileReference-base-should-be-before… >> > https://github.com/pharo-project/pharo/pull/137 >> > >> > Did I miss some others? >> > >> > Stef >> >> - https://pharo.fogbugz.com/f/cases/20294/Add-FileAttributesPlugin-to-the-lin… >> This is the first step in fixing FileReference>>isSymlink and >> extending support for all file attributes returned by stat() and >> lstat(). >> The parent issue is: >> https://pharo.fogbugz.com/f/cases/18279/isSymlink-seems-to-be-broken-on-Lin… >> >> Just for completeness, the two issues relating to FileReference>>/: >> >> - https://pharo.fogbugz.com/f/cases/13217/FS-basename-with-compound-path-stri… >> - https://github.com/pharo-project/pharo/pull/192 >> - https://pharo.fogbugz.com/f/cases/18042 >> - https://github.com/pharo-project/pharo/pull/75 >> >> >> Cheers, >> Alistair >

Aug. 15, 2017