- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Anybody using Orca Smalltalk to JavaScript?

by Craig Latta

Hi Frank-- > > > ...especially if their sources MUST be closely connected with > > > existing Smalltalk code, which does not run in the client like > > > all the data-driven model definitions etc that I already have > > > > There is no such requirement. > > Of course, there is, actually it's an absolute necessity in my case. Oh, I misunderstood you. I thought you were saying that such a coupling was a bad thing; I didn't realize it's a constraint you already have. Anyway, Caffeine is a distributed system. As long as your existing code can use WebSockets, you can use remote messaging between your code and the object memories running in web browsers. The Snowglobe remote UI examples, for example, have object memories running in the AWS cloud which can send messages to objects in a web browser, modifying that web browser's DOM objects. > > ...at the moment my UI is Mozilla's A-Frame 3D virtual reality > > framework, at 90 frames per second. > > Well, what I have seen from the demos, the responsiveness to the > cursor alone is so very far away from being acceptable... That must have been the first Smalltalk Morphic demo, in which Morphic had full unoptimized control of the cursor. Since then, I've made UIs that use the Zebkit UI framework, morphic.js from the Snap project, A-Frame, and pure HTML/CSS. As it turns out, I now always use the web browser's built-in cursor handling for the normal case, even with Smalltalk Morphic, so one gets the native OS cursor handling speed. > ...that I only believe, what you are writing, when I have seen a > real-world JavaScript UI based on your system. Sorry, over the years, > from bad experiences and one's own mistakes, I have become very > skeptical and even more careful. Sure, no worries; as older demos are replaced with newer ones this stuff will be obvious. > > > and it's impossible to port my >10.000 framwork and application > > > classes to Squeak. > > > Caffeine can use Pharo, Squeak, or Cuis. > > Well, my Smalltalk code is in neither of these and it would cost many > months of work and the loss of very essential tools to port this to > any of your supported systems. Oh, since you're not using Pharo, if were were to continue this conversation it should be off-list in private email. Anyway, you could use Caffeine's remote UI server component in your Smalltalk environment, and just use web browsers for the UI. I'm currently adapting the remote messaging parts to all the other Smalltalks. > However, *I see one advantage in your approach*, assuming that no > Smalltalk source code must be sent to the client (I have no info > about that) and this is in the fact that Smalltalk byte code is, of > course, a much better protection of IPR than any obfuscated > JavaScript could ever offer. But the price for this advantage would > be far to high, as far as I can currently tell. No, no Smalltalk code need be sent to the client, although you always have the option of sending remote messages. thanks, -C -- Craig Latta Black Page Digital Amsterdam :: San Francisco craig(a)blackpagedigital.com voice through 2017-09-12: + 1 510 833 5799 (SMS ok) +31 20 893 2796 (no SMS)

Aug. 15, 2017

Re: [Pharo-dev] @About posting here

by Guillermo Polito

Hi Frank, Le mar. 15 aoÃ»t 2017 Ã 22:11, Frank-B <frank.berger.software(a)web.de> a Ã©crit : > @about this forum at world.st I never use that website to interact with the mailing list. Most people I know use regular mail as me. In practice, we use that forum as conversation backup. It's also practical because Google indexes it (in contrast to our non Google groups mailing list). > <http://world.st> > > I have a lot of forum experience from studying "forum psychology and > sociology" in three different language and in various forums run by very > different software but I have never come about any system that is *nearly > as > crappy, sick and idiotic as this one here*: > > - various message don't show up here > - masses of emails that I am not interested in are polluting my email > client > (and I will stop this silly downloading tonight by directing them straight > into the delete folder) > - and one is never informed if there is any reply to one's posting, which > is > standard on almost all forums and comment part of blogs > - and there is no chance to directly reply to some post > - thus there is no branching of the subjects > - which makes following a sib-thread most difficult > > I am neither going to write answers in my email clent, not will I continue > to pollute my system with 99% unwanted messages. > > I just ask myself: Why are Smalltalk people with the "best" IDE of all > using > such a crappy system!? > > Mailing lists are something - in my view - soooo much outdated and just a > pain in the....! > Well, currently the communication of this community is split between the mailing list (not the online forum I assume you use) and a discord group. We tried slack before but we abandoned it because it loses conversation history unless you pay. Actually, discord has far more interactions. But mailing lists are for perenne conversations. Those who like both are subscribed to both. Guille > Now: Hunt me, shout at me, call me whatever you want! That's fine by me. It > would be the normal reaction of a crowd if a new sheep dares to criticise > what the crowd has been doing for long. I don't care! > > Regards > Frank > > > > > -- > View this message in context: > http://forum.world.st/Anybody-using-Orca-Smalltalk-to-JavaScript-tp4960519p… > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > > -- 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. 15, 2017

[Pharo 70 ] build 36 - PR 204 Improve-comment-of-SmallDictionary

by Stephane Ducasse

https://pharo.fogbugz.com/f/cases/20091/Improve-comment-of-SmallDictionary https://github.com/pharo-project/pharo/pull/204

Aug. 15, 2017

Re: [Pharo-dev] @Craig Latta

by Frank-B

Hello Craig, your answer to my posting to you does not show up here and I only accidentally detected it in the flood of unwanted messages that came is. See my frustration posting above. I accidentally saw just your reply come in. This is why I am answering here to the most important points. I hope you receive this answer. I wrote: > ...especially if their sources MUST be closely connected with existing > Smalltalk code, which does not run in the client like all the > data-driven model definitions etc that I already have You answered: > There is no such requirement. Of course, there is, actually it's an absolute necessity in my case. Almost all UI components relate to some definition data, which exist in my main Smalltalk environment. From this data the DDL is generated, the models created, this data handles at run-time the instance variables, avoid getters and setters, and a huge lot more. It's ALL ONLY in ONE central place, of course. No dedundancies! This also handles versions and different configs. The UI is just a slightly enhanced extension to the data-definded models in the MVC concept. And all my models are defined ONLY by data. It would be insane to douplicate this data into the UI parts! I wrote: > the responsivness of such a solution in the browser must always be far > slower than any "normal" browser UI You answered: > That's not true. For example, at the moment my UI is Mozilla's > A-Frame 3D virtual reality framework, at 90 frames per second. Well, what I have seen from the demos, the responsiveness to the cursor alone is so very far away from being acceptable that I only belive, what you are writing, when I have seen a real-word JavaScript UI based on your system. Sorry, over the years, from bad experiences and one's own mistakes, I have become very sceptical and even more careful. I wrote: > and it's impossible to port my >10.000 framwork and application > classes to Squeak. You answered: > Caffeine can use Pharo, Squeak, or Cuis. Well, my Smalltalk code is in neither of these and it would cost many months of work and the loss of very essential tools to port this to any of your supported systems. That is out of any discussion. Such an investment would never pay back and AFAIK a lot of features are missing in Pharo to substitute my current environment (I couldn' be drunk enough to ever consider Squeak alone because of its outregeous UI). However, *I see one advantage in your approach*, assuming that no Smalltalk source code must be sent to the client (I have no info about that) and this is in the fact that Smalltalk byte code is, of course, a much better protection of IPR than any obfuscated JavaScript could ever offer. But the price for this advantage would be far to high, as far as I can currently tell. So, thank you for responding. I tink we can close the case at least for the foreseable future (and I can't wait, I need some working solution during winter 2017/18). Good luck with your development! Best regards Frank -- View this message in context: http://forum.world.st/Anybody-using-Orca-Smalltalk-to-JavaScript-tp4960519p… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Aug. 15, 2017

Re: [Pharo-dev] @About posting here

by Frank-B

@about this forum at world.st I have a lot of forum experience from studying "forum psychology and sociology" in three different language and in various forums run by very different software but I have never come about any system that is *nearly as crappy, sick and idiotic as this one here*: - various message don't show up here - masses of emails that I am not interested in are polluting my email client (and I will stop this silly downloading tonight by directing them straight into the delete folder) - and one is never informed if there is any reply to one's posting, which is standard on almost all forums and comment part of blogs - and there is no chance to directly reply to some post - thus there is no branching of the subjects - which makes following a sib-thread most difficult I am neither going to write answers in my email clent, not will I continue to pollute my system with 99% unwanted messages. I just ask myself: Why are Smalltalk people with the "best" IDE of all using such a crappy system!? Mailing lists are something - in my view - soooo much outdated and just a pain in the....! Now: Hunt me, shout at me, call me whatever you want! That's fine by me. It would be the normal reaction of a crowd if a new sheep dares to criticise what the crowd has been doing for long. I don't care! Regards Frank -- View this message in context: http://forum.world.st/Anybody-using-Orca-Smalltalk-to-JavaScript-tp4960519p… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Aug. 15, 2017

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

by Eliot Miranda

> On Aug 15, 2017, at 7:25 AM, Ben Coman <btc(a)openinworld.com> wrote: > > > >> 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). +1! > > 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] Issue 20309 - Startup should run always in a fresh process

by Eliot Miranda

Hi Ben, > On Aug 15, 2017, at 6:25 AM, Ben Coman <btc(a)openinworld.com> wrote: > > 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. +1. In fact I'd raise it to no more than lowIOPriority - 1. > but then Eliot's suggestion to valueUnpreemptively may avoid that anyway. It does not. > > btw, what happens if an error occurs inside valueUnpreemptively? > Does the normal priority debugger still get to run? Once the notifier is opened the process is suspended. So startup will not complete, just as is the case now. But the exception is logged, so it's no longer invisible. BTW, on a related note, on snapshot, the primitive should not do a GC. Instead, the system should go a GC and allow any resulting finalization complete before the snapshot and well before the quit. Consider a buffered file that is flushed on finalization. This must happen before the snapshot. The GC in the snapshot is fine for ensuring the snapshot file is compact but very wrong for adding things to the finalization queue. > 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%2… >> >> Guille >> >> -- >> >> Guille Polito >> >> 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. 15, 2017

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